看了许多资料后，已经大致知道JAVA跨平台的原理，那就是JVM对JAVA源代码做了不同操作系统的适配，在不同系统上进行解释执行，有JVM讲JAVA的字节码在运行时转换为机器码执行，后来慢慢了解到为了提升JAVA的运行效率，JVM还提供了JIT(Just-In-Time)编译器，即能够在运行时将热点代码编译成机器码，这种情况下热点代码就属于编译执行，而不是解释执行。
问题任然没有得到解决，不都是编译成机器码吗，有何区别?
这个问题困扰了我很久，在Oracle的资深工程师杨晓峰的博客中,我依然只看到了比较官方套路的解释，就是和我上面的概括差不多的内容。而在阿里的《码出高效》这本书中，我又看到了其列举的在生产环境中，由于工程师没有控制耗流量，导致JIT没有来得及分析热点代码导致的线上事故，就更让我产生疑惑。
问题有2：
解释执行和编译执行有什么区别？
经过维基百科和google我搞清楚他们之间的区别。首先摘录一段关于JIT编译的维基原文中的关键一段
This can be done per-file, per-function or even on any arbitrary code fragment;
the code can be compiled when it is about to be executed (hence the name "just-in-time"),
and then cached and reused later without needing to be recompiled.
为了尽量少贴代码和原文我只选取了这一段，不过他已经足够表明最关键的地方了，核心词就是cached和reused。
即使用JIT编译的机器码，会被缓存起来，以后这一段就不用再解释编译了。
同时，维基百科也说明了JIT对代码直接编译成机器码是很灵活的，它可以对一个文件，一个函数，甚至是某个代码块进行直接编译，这点非常优秀。
JIT热点分析的遵从一个什么样的原理，阈值大致是多少？
维基百科对这个阈值问题没有给出明确说明，但是针对热点分析，它说了以下内容：
对代码的编译会导致软件有一个启动时间延迟，JIT执行的优化越多，它生成的代码就越好，但是初始的延迟也会增加。因此试试上聪明的JIT会在这里进行Trade-Off（取舍），如果只是会执行几次的字节码，它不会去编译，这节省了编译时间并减少了初始延迟，而对于频繁（很遗憾，这里任然没有给出一个定量的说明）执行的字节码，它就会编译。
总结
- 解释执行和编译执行的区别在于编译执行会把机器码缓存起来，解释执行不会。
- 编译会延长软件的初始启动时间，因此它会只对频繁执行的字节码进行编译
- 解释执行与编译执行相结合的混合执行的方式很多语言都有，例如Basic,C,List,Pascal,Python,Java,C#.
