本文是《Java执行那些事》系列文章的第一篇，在阅读文章之前，请您思考标题的内容：Java是解释执行么？
答案（刮开涂层有惊喜）：【这句话说的并不准确，Java的执行是解释+编译混合的。你答对了么？】（手机的朋友请到文尾）
#解释执行与编译执行
解释执行描述的是将源语言直接作为输入，每次执行一条就将源代码解释成机器码，并不保留中间结果。因为每次都需要解释所以移植性和跨平台性很高。
我们可以将解释执行的过程类比成现实生活中的高级翻译——同声传译。翻译的工作就是将我们的语言翻译成对方国家的语言，你说一句，翻译就紧跟这翻译这一句，无需等待。也就是说只要我们带上足够的翻译，走遍全球都不是问题。
而编译执行描述的是将源代码事先编译成目标机器的机器码文件，这样一来就直接可以在目标机器上运行，但是由于目标机器的不同，每次更换目标都需要重新编译与之相对的机器码文件，所以移植性较差。
这个过程可以类比成将翻译的结果录制成磁带，好处就是你可以直接播放磁带让对方听得懂，不必随身带翻译了。但是当你在美国的时候需要把语言翻译成英语，而到了俄罗斯你就得再把你的语言翻译成俄语，灵活度不高。
解释执行是来一句翻译一句，当然没有编译执行这样直接执行的效率高，但是解释执行灵活，可谓写一次到处执行！！
#Java的执行过程
写一次到处执行（write once run anywhere）其实是Java的宣传语，这很容易让人联系到解释执行的低效问题，那么Java的执行过程到底是怎么样的呢？
首先我们编写好的Java代码会通过JavaC编译成字节码文件（bytecode），在运行的时候，通过JVM内嵌的解释器将字节码文件解释成机器码。但是常见的JVM例如Hotspot虚拟机，都提供了JIN（just int time）机制,此机制被称为动态编译机制，它可以将反复执行的热点代码直接编译成机器码，这种情况下部分热点代码的执行就属于编译执行，而不是解释执行了。
Hotspot JVM默认采用这种混合执行模式，综合两者优势将灵活和执行速度合二为一。
Java执行效率真的差么
及时编译的模式假定程序符合二八定律的，即百分之二十的代码占用了百分之八十的资源。对不常用的代码，根本无需耗时将其编译成机器码，采用解释执行完全可以满足要求。而对于常用的热点代码，可以将其编译成机器码，达到理想的运行效率。
现在的Java程序其实是可以快过C++，因为及时编译是动态编译，比C++事先编译能拿到程序运行时的更多信息，可以进行更多的优化。
AOT
而且在Java9中引入了实验室特征 AOT（ahead of time compilation），AOT能够在线下事先将java字节码文件编译成机器码！！！。
但是对于那些发布不频繁，或者说长时间运行的的程序，其实在选择线下编译和及时编译的效果一样，因为当程序运行一两个小时之后，及时编译已经基本完成，而且动态编译可以获取程序运行时的更多信息，优化效果更好。
不仅如此在主流Java版本中例如JDK8，提供了多种即时编译器模式：Server、Client 和多种及时编译器：C1、C2 和 Graal。
可见未来的Java性能超越C/C++已经不是梦想。
答案：【这句话说的并不准确，Java的执行是解释+编译混合的。你答对了么？】
文章的最后向您推荐两个关于Java的专栏。专栏的内容有音频有文稿， 无论是在路上还是业余时间的学习都很有裨益。
