本篇来自周志明的<<深入理解java虚拟机>>

许多Java虚拟机的执行引擎在执行Java代码的时候都有解释执行(通过解释器执行)和编译执行(通过即时编译器产生本地代码执行)两种选择,在本章中,我们先来探讨一下在解释执行时,虚拟机执行引擎是如何工作的。

解释执行

Java语言经常被人们定位为“解释执行”的语言,在Java初生的JDK 1.0时代 ,这种定义还算是比较准确的, 但当主流的虚拟机中都包含了即时编译器后,Class文件中的代码到底会被解释执行还是编译执行,就成了只有虚拟机自己才能准确判断的事情。再后来 ,Java也发展出了可以直接生成本地代码的编译器[如GCJ」(GNU Compiler for the Java )],而C/C++语言也出现了通过解释器执行的版本(如CINT) ,这时候再笼统地说“解释执行”,对于整个 Java语言来说就成了几乎是没有意义的概念,只有确定了谈论对象是某种具体的Java实现版本和执行引擎运行模式时,谈解释执行还是编译执行才会比较确切。


一、你可以说它是编译型的。因为所有的Java代码都是要编译的，.java不经过编译就什么用都没有。 

二、你可以说它是解释型的。因为java代码编译后不能直接运行，它是解释运行在JVM上的，所以它是解释运行的，那也就算是解释的了。 

三、但是，现在的JVM为了效率，都有一些JIT优化。它又会把.class的二进制代码编译为本地的代码直接运行，所以，又是编译的。


不论是解释还是编译,也不论是物理机还是虚拟机,对于应用程序,机器都不可能如人那样阅读、理解 ,然后就获得了执行能力。大部分的程序代码到物理机的目标代码或虚拟机能执行的指令集之前,都需要经过图8-4中的各个步骤。如果读者对编译原理的相关课程还有印象的话,很容易就会发现图8-4中下面那条分支,就是传统编译原理中程序代码到目标机器代码的生成过程,而中间的那条分支,自然就是解释执行的过程。

如今,基于物理机、Java虚拟机,或者非Java的其他高级语言虚拟机(HLLVM )的语 言 ,大多都会遵循这种基于现代经典编译原理的思路,在执行前先对程序源码进行词法分析和语法分析处理,把源码转化为抽象语法树( Abstract Syntax Tree,AST)。对于一门具体语言的实现来说,词法分析、语法分析以至后面的优化器和目标代码生成器都可以选择独立于执行引擎,形成一个完整意义的编译器去实现,这类代表是C/C++语言。也可以选择把其中一部分步骤(如生成抽象语法树之前的步骤)实现为一个半独立的编译器,这类代表是Java 语言。又或者把这些步骤和执行引擎全部集中封装在一个封闭的黑匣子之中,如大多数的JavaScript执行器。

图8-4 编译过程



Java语言中 ,Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树,再遍历语法树生成线性的字节码指令流的过程。因为这一部分动作是在Java虚拟机之外进行的, 而解释器在虚拟机的内部,所以Java程序的编译就是半独立的实现。

高级语言里一个程序的编译和执行大概是 下面的情况： 
 
 
 
编译器将高级语言从源代码翻译成与之等价的目标程序（就相当于从中文翻译成中文），而后就隐退了。在随后的某个时刻，用户启动目标程序由操作系统执行。实现高级语言的另外一种方式为解释： 
与编译不同的是，解释器在目标程序（其实根本就没有目标程序，只是与编译来对比）执行期间，解释器一直随之运行。这种执行过程完全由解释器控制的。从效果上看，解释器实现了一台“虚拟计算机”，其“机器语言”就是高级语言，解释器一次读入一条或多条语句，按照其自身规定的方式去执行相应的操作。一般说来，解释比编译有着很好的灵活性；编译一般有着较好的性能。但是有些语言确是采用了两者的混合形式： 
书中的原文：”如果初始阶段的翻译器比较简单，我们就说这个语言是“解释的”。如果翻译器很复杂，我们就说这一语言是“编译的”。现在两者的区分变得有些模糊了，因为“简单”和“复杂”都是修饰性术语，也因为完全可能出现用一个编译器（复杂的翻译过程）生成代码，而后又由一个复杂的虚拟机（解释器）执行。对于最后这种情况，如果翻译器对程序做了彻底的分析（而不是做某种“机械的”变换），而且有关的中间语言程序与源程序并没有很强的相似性，我们还是说这个语言是编译的。这两种特性----彻底的分析和非平凡的变换-----是刻画编译方式的标志性特征。“ 
 
 
举例：编译性语言：c、c++，delphi,Fortran、Pascal、Ada
 
        解释性语言：java，vb，python（持续总结中）
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Python语言是编译型语言还是解释型语言？
我们都知道，编程语言从程序执行过程分，分为编译型语言和解释性语言

什么是编译型语言和解释型语言？

Python是一种解释型语言
Python程序源码不需要编译，可以直接从源代码运行程序。Python解释器将源代码转换为字节码，然后把编译好的字节码转发到Python虚拟机（PVM）中进行执行。
下面用一张图来解释这个过程：

当我们运行Python文件的时候，Python解释器会执行两个步骤：


把源代码编译为字节码（以.pyc文件保存）


把编译好的字节码转发到PVM中加以执行


这样，Python程序的执行过程就清楚了
所以，Python是一种典型的解释型语言

另一种解释型热门语言：Java

Python是一门解释型语言？
我初学Python时，听到的关于Python的第一句话就是Python是一门解释型语言，我就这样一直相信下去，直到发现*.pyc文件的存在，如果真是解释型语言，那么生成的*.pyc文件的是什么呢？c应该是compiled的缩写才对啊！

为了防止其他学习Python的人也被这句话误解，那么我们就在文中来澄清一下这个问题，并且把一些基础概念给理一理。
解释型语言和编译型语言
计算机是不能够识别高级语言的，所以当我们运行一个高级语言程序的时候，就需要一个“翻译机”来从事把高级语言转变成计算机能读懂的机器语言的过程。这个过程分成两类，第一种是编译，第二种是解释。

编译型语言在程序执行之前，先会通过编译器对程序执行一个编译的过程，把程序转变成机器语言。运行时就不需要翻译，而直接执行就可以了，最典型的例子就是C语言。

解释型语言就没有这个编译过程，而是在程序运行的时候，通过解释器对程序逐行做出解释，然后直接运行，最典型的例子是Ruby。

通过以上的例子，我们可以来总结一下解释型语言和编译型语言的优缺点，因为编译型语言在程序运行之前就已经对程序做出了“翻译”，所以在运行时就少掉了“翻译”的过程，所以效率比较高。但是我们也不能一概而论，一些解释型语言也可以通过解释器的优化来在对程序做出翻译时对整个程序做出优化，从而在效率上超过编译型语言。

此外，随着Java等基于虚拟机的语言的兴起，我们又不能把语言纯粹的分成解释型和编译型这两种。

用Java来举例，Java首先是通过编译器编译成字节码文件，然后在运行时通过解释器给解释成机器文件。所以我们说Java是一种先编译后解释的语言。

再换成C#，C#首相是通过编译器将C#文件编译成IL文件，然后在通过CLR将IL文件编译成机器文件。所以我们说C#是一门纯编译语言，但是C#是一门需要二次编译的语言。同理也可以等效运用到基于.NET平台上的 其他语言。
Python到底属于哪一种类型？
其实Python和Java/C#一样，也是一门基于虚拟机的语言，我们先来从表面上简单的了解一下Python程序的运行过程吧。

当我们在命令行中输入python hello.py时，其实是激活了Python的“解释器”，告诉“解释器”：你要开始工作了。可是在“解释”之前，其实执行的第一项工作和Java一样，是编译。

熟悉Java的同学可以想象一下我们在命令行中如何执行一个Java的程序：

javac hello.java

java hello
只是我们在用eclipse之类的IDE时，将这两步给融合成了一步而已。其实Python也是一样的，当我们执行python hello.py时，它也一样执行了这么一个过程，所以我们应该这样来描述Python，Python是一门先编译后解释的语言。
简述Python中程序的运行过程
在说这个问题之前，我们先来说两个概念，PyCodeObject和pyc文件。

我们在硬盘上看到的pyc自然不必多说，而其实PyCodeObject则是Python编译器真正编译成的结果。我们先简单知道就可以了，继续向下看。

当Python程序运行时，编译的结果则是保存在位于内存中的PyCodeObject中，当Python程序运行结束时，Python解释器则将PyCodeObject写回到pyc文件中。

当Python程序第二次运行时，首先程序会在硬盘中寻找对应的pyc文件，如果找到，则直接载入，否则就重复上面的过程。

所以我们应该这样来定位PyCodeObject和pyc文件：pyc文件其实是PyCodeObject的一种持久化保存方式。
我们先来简单看两个例子
写一段简单的程序运行一下：


运行结果：


我们发现在运行完test.py这个程序后，当前路径下并没有生成相应的pyc文件。那是为什么呢？

我们再来做一个小测试，将test.py当做模块导入到test888.py文件中，然后在这个程序中运行print_hello这个程序：


然后运行程序：

我们可以发现运行完test888.py文件后在当前路径下出现了一个名叫__pycache__的文件夹，里面包含了一个pyc文件，下面我们来分析一下这个过程到底发生了什么。
pyc文件的目的
回想上面我们在分析编译型语言和解释型语言的优缺点时，编译型语言的优点在于，我们可以在程序运行时不用解释，而直接利用已经翻译过的文件。也就是说，我们之所以要把py文件编译成pyc文件，最大的优点在于我们在运行程序时，不需要重新对该模块进行再次解释。

所以，需要编译成pyc文件的应该是那些可以重用的模块，这于我们在设计类时是一样的目的。所以Python的解释器认为：只有import进来的模块，才是需要被重用的模块。

这个时候也许有人会有疑问，我的test.py不是也需要运行吗，虽然不是一个模块，但是以后我每次运行也可以节省时间啊！

OK，我们从实际情况出发，思考一下我们在什么时候才可能运行python xxx.py文件：
执行测试时；
开启一个Web进程时；
执行一个脚本时。
我们来逐条分析，第一种情况就不多说了，这个时候哪怕所有的文件都没有pyc文件都是无所谓的。

第二种情况，试想一个web.py的程序，通常是这样执行的：


然后这个程序就类似于一个守护进程一样一直监视着8000端口，而一旦中断，只可能是程序被杀死或者其他的意外情况，那么你要做的是把整个Web服务重启，那么既然一直监视着，把PyCodeObject一直放在内存中就足够了，完全没有必要持久化到硬盘上。

再来看看最后一个情况，执行一个程序脚本，一个程序的主入口其实很类似于Web程序中的Controller，也就是说，他负责的应该是Model之间的调度，而不包含任何的主逻辑在内，只是负责把参数转来转去而已，那么如果做算法的同学可以知道，在一段算法脚本中，最容易改变的就是算法的各个参数，那么这个时候将它持久化成pyc文件就未免有些画蛇添足了。
所以我们可以这样理解Python解释器的意图，Python解释器只是把我们可能重用到的模块持久化成pyc文件。
pyc文件的过期时间
说完了pyc文件，可能有人会想到，每次Python解释器都把模块给持久化成pyc文件，那么当我的模块发生改变的时候，是不是都要手动的把之前的pyc文件remove掉呢？

当然Python的设计者是不会犯这样的错误的，这个过程其实取决于PyCodeObject是如何写入pyc文件中的。

我们仔细看一下Import模块的源码其实不难发现，它在写入pyc文件的时候，写了一个Long型变量，变量的内容则是文件的最近修改日期，同理，在pyc文件中，每次在载入之前都会检查一下py文件和pyc文件保存的最后修改日期，如果不一致则重新生成新的pyc文件。
总结
其实了解Python程序的执行过程对于大部分程序员来说意义都是不大的，那么真正有意义的是，我们可以从Python解释器的做法上学到一些处理问题的方式和方法：
在Python中判断是否生成pyc文件和我们在设计缓存系统时是一样的，我们可以仔细想想，到底什么是值得扔在缓存里面的，什么是不值得的。
在运行一个耗时的Python脚本时，我们如何能够做到稍微压榨一些程序的运行时间呢？就是将模块从主模块分开。（虽然往往这都不是瓶颈）
在设计一个软件系统时，重用和非重用的东西是不是也可以分开来对待，这是软件设计原则的重要部分。
在设计缓存系统（或者其他系统）时，我们如何来避免程序的过期，其实Python解释器为我们提供了一个特别常见而且有效的解决方案。