Merge pull request #1770 from daniubi/patch-8

为什么不全部使用AOT呢？

Author: Snailclimb

docs/java/basis/java-basic-questions-01.md

@@ -54,7 +54,11 @@ JRE 是 Java 运行时环境。它是运行已编译 Java 程序所需的所有
 
 我们需要格外注意的是 `.class->机器码` 这一步。在这一步 JVM 类加载器首先加载字节码文件，然后通过解释器逐行解释执行，这种方式的执行速度会相对比较慢。而且，有些方法和代码块是经常需要被调用的(也就是所谓的热点代码)，所以后面引进了 JIT（just-in-time compilation） 编译器，而 JIT 属于运行时编译。当 JIT 编译器完成第一次编译后，其会将字节码对应的机器码保存下来，下次可以直接使用。而我们知道，机器码的运行效率肯定是高于 Java 解释器的。这也解释了我们为什么经常会说 **Java 是编译与解释共存的语言** 。
 
-> HotSpot 采用了惰性评估(Lazy Evaluation)的做法，根据二八定律，消耗大部分系统资源的只有那一小部分的代码（热点代码），而这也就是 JIT 所需要编译的部分。JVM 会根据代码每次被执行的情况收集信息并相应地做出一些优化，因此执行的次数越多，它的速度就越快。JDK 9 引入了一种新的编译模式 AOT(Ahead of Time Compilation)，它是直接将字节码编译成机器码，这样就避免了 JIT 预热等各方面的开销。JDK 支持分层编译和 AOT 协作使用。但是 ，AOT 编译器的编译质量是肯定比不上 JIT 编译器的。
+> HotSpot 采用了惰性评估(Lazy Evaluation)的做法，根据二八定律，消耗大部分系统资源的只有那一小部分的代码（热点代码），而这也就是 JIT 所需要编译的部分。JVM 会根据代码每次被执行的情况收集信息并相应地做出一些优化，因此执行的次数越多，它的速度就越快。JDK 9 引入了一种新的编译模式 AOT(Ahead of Time Compilation)，它是直接将字节码编译成机器码，这样就避免了 JIT 预热等各方面的开销。JDK 支持分层编译和 AOT 协作使用。
+
+### 为什么不全部使用AOT呢？
+
+爱思考的铁子们一定在想，AOT可以提前编译节省启动时间那为什么不全部使用这种编译方式呢？长话短说，这就和java语言的动态特性有千丝万缕的联系了。举个例子，比如CGLib动态代理使用的是ASM技术，而这种技术大致原理是运行时直接在内存中生成并加载修改后的字节码文件也就是.class文件，如果全部使用AOT提前编译，也就不能使用ASM技术了。为了支持类似的动态特性，所以选择使用JIT即时编译器。
 
 ### 为什么说 Java 语言“编译与解释并存”？