Update JVM 相关口水话.md

blogs/Java/口水话/JVM 相关口水话.md

@@ -186,3 +186,24 @@ JVM 也提供了内联缓存来加快动态绑定，它能够缓存虚方法调
 
 我对反射的好奇是来源于，经常会听说反射影响性能，那么性能开销在哪以及如何优化？
 
+在此之前，我先讲讲 JVM 是如何实现反射的。
+
+我们可以直接 new Exception 来查看方法调用的栈轨迹，在调用 Method.invoke() 时，是去调用 DelegatingMethodAccessorImpl 的 invoke，它的实际调用的是 NativeMethodAccessorImpl 的 invoke 方法。前者称为委派实现，后者称为本地实现。既然委派实现的具体实现是一个本地实现，那么为啥还需要委派实现这个中间层呢？其实，Java 反射调用机制还设立了另一种动态生成字节码的实现，成为动态实现，直接使用 invoke 指令来调用目标方法。之所以采用委派实现，是在本地实现和动态实现直接做切换。依据注释信息，动态实现比本地实现相比，其运行效率要快上 20 倍。这是因为动态实现无需经过 Java 到 C++ 再到 Java 的切换，但由于生产字节码比较耗时，仅调用一次的话，反而是本地实现要快上三四倍。考虑到很多反射调用仅会执行一次，JVM 设置了阈值 15，在 15 之下使用本地实现，高于 15 时便开始动态生成字节码采用动态实现。这也被称为 Inflation 机制。
+
+在反手说一下反射的性能开销在哪呢？平时我们会调用 Class.forName、Class.getMethod、以及 Method.invoke 这三个操作。其中，Class.forName 会调用本地方法，Class.getMethod 则会遍历该类的公有方法，如果匹配到，它还将遍历父类的公有方法，可想而知，这两个操作都非常耗时。下面就是 Method.invoke 调用本身的开销了，首先是 invoke 方法的参数是一个可变长参数，也就是构建一个 Object 数组存参数，这也同时带来了基本数据类型的装箱操作，在 invoke 内部会进行运行时权限检查，这也是一个损耗点。普通方法调用可能有一系列优化手段，比如方法内联、逃逸分析，而这又是反射调用所不能做的，性能差距再一次被放大。
+
+优化反射调用，可以尽量避免反射调用虚方法、关闭运行时权限检查、可能需要增大基本数据类型对应的包装类缓存、如果调用次数可知可以关闭 Inflation 机制，以及增加内联缓存记录的类型数目。
+
+#### JVM 是如何实现泛型的？
+
+#### JVM 是如何实现异常的？
+
+在 Java 中，所有的异常都是 Throwable 类或其子类，它有两大子类 Error 和 Exception。 当程序触发 Error 时，它的执行状态已经无法恢复，需要终止线程或者终止虚拟机，常见的比如内存溢出、对栈溢出等；Exception 又分为两类，一类是受检异常，比如 IOException，一类是运行时异常 RuntimeException，比如空指针、数组越界等。
+
+接下来我会从三个方面阐述这个问题。
+
+首先是，异常实例的构造十分昂贵。这是由于在构造异常实例时，JVM 需要生成该异常的栈轨迹，该操逐一访问当前线程的 Java 栈桢，并且记录下各种调试信息，包括栈桢所指向方法的名字、方法所在的类名以及方法在原代码中的位置等信息。
+
+其次是，JVM 捕获异常需要异常表。每个方法都有一个异常表，异常表中的每一个条目都代表一个异常处理器，并且由 from、to、target 指针及其异常类型所构成。form-to 其实就是 try 块，而 target 就是 catch 的起始位置。当程序触发异常时，JVM 会坚持触发异常的字节码的索引值落到哪个异常表的 from-to 范围内，然后再判断异常类型是否匹配，匹配就开始执行 target 处字节码处理该异常。
+
+最后是 finally代码块的编译。我们知道 finally 代码块一定会运行的（除非虚拟机退出了）。那么它是如何实现的呢？其实是一个比较笨的办法，当前 JVM 的做法是，复制 finally 代码块的内容，分别放在所有可能的执行路径的出口中。