程序主要有两种运行方式:静态编译与动态解释。静态编译的程序在执行前全部被翻译为机器码,通常将这种类型称为AOT (Ahead of time)即 “提前编译”;而解释执行的则是一句一句边翻译边运行,通常将这种类型称为JIT(Just-in-time)即“即时编译”。AOT程序的典型代表是用C/C++开发的应用,它们必须在执行前编译成机器码,而JIT的代表则非常多,如JavaScript、Python等,事实上,所有脚本语言都支持JIT模式。但需要注意的是JIT和AOT指的是程序运行方式,和编程语言并非强关联的,有些语言既可以以JIT方式运行也可以以AOT方式运行,如Java、Python,它们可以在第一次执行时编译成中间字节码、然后在之后执行时可以直接执行字节码,也许有人会说,中间字节码并非机器码,在程序执行时仍然需要动态将字节码转为机器码,是的,这没有错,不过通常我们区分是否为AOT的标准就是看代码在执行之前是否需要编译,只要需要编译,无论其编译产物是字节码还是机器码,都属于AOT。在此,读者不必纠结于概念,概念就是为了传达精神而发明的,只要读者能够理解其原理即可,得其神忘其形。
一个程序的编译过程可以是步骤迭代式的,即每一轮步骤结束后得到的结果都可独立运行,比如,先构造AST再输出字节码,中间状态AST也是可以解释执行的。由于编译的本质就是代码转换,因此对一个语言可以有多个独立的编译器,每个负责一轮步骤  

AOT Compiler和JIT Compiler就是针对编译形式做的分类:  
AOT:Ahead Of Time,指在运行前编译,比如普通的静态编译  
JIT:Just In Time,指在运行时编译,边运行边编译,比如java虚拟机在运行时就用到JIT技术  

JIT可能知道的人多些,AOT这个名词就相对少见一些了,其实除了JIT,剩下的都是AOT。wiki上JIT的解释也比AOT详尽很多,如果按wiki上的理解,一般来说,是从形式上来区分这两个概念,即看编译是不是在“运行时”进行  

然而,这两个概念又有模糊性,问题在于这个“运行时”怎么来区分,比方说,从这个概念来看,Python是用到JIT技术的,因为:  
... 
import a 
... 
当执行到import a的时候,当然是运行时,这时候如果只找到了a.py,则会进行编译工作,并生成a.pyc,这就是python的JIT特性,但是一般来说,认为python的JIT是psyco、pypy之类,并不认为python本身的动态性属于JIT范畴,或者说,它的这种“形式上”的JIT特性不纳入讨论范围。其他脚本语言,动态语言也有类似的情况。具体原因我觉得有几点  
首先被主流理论认定的JIT编译器对于被其编译的语言来说属于附加品,也就是说,就算去掉JIT,并不影响语言本身的运行,例如java,如果关闭JIT,依然可以解释执行,而上述python的运行时import的特性虽然形式上符合JIT,但这个机制是语言本身规定的,如果去掉,语言(的主流实现)就不完整了。反过来说,如果python采用源码直接解析执行,则编译为字节码的行为就可以看做是JIT,因为做不做都不影响解析执行过程  
其次,python的这种编译并非每次执行都会进行,因为一般来说会生成字节码结果pyc文件存在磁盘,它更像是对java源代码转class文件这一过程的惰性化,在需要的时候进行  
最后,JIT会消耗运行时资源,可能导致进程卡顿,而java等语言之所以引入JIT,是因为JIT对字节码编译后能以更快的速度运行,卡顿的时间能补救回来,因此从工程角度讲,JIT几乎就等于是运行时优化(虽然从概念和形式上并非如此),而python的import就只有卡顿,对速度没啥好处  
于是,虽然从概念来说,上面的例子的确符合JIT,但一般来说也不这么认为,出发角度问题,说python自带JIT特性或没有JIT都算说得通的  

之所以先举这个例子,因为我觉得能体现AOT和JIT概念的对立和统一,对立是形式上的,以“运行”为分界线,而统一则是说,其实所有需要执行的指令序列,都是需要先编译再执行的,比如import a,这个相对于整个进程当然是JIT,但相对于a.py这个模块(python进程首次import某个模块时会执行它)不妨看做AOT,如果有人觉得这么做不妥,那换个更明显的例子,如果一个python程序的所有import都在进程开启时立即运行,然后才进入执行,那按照概念来说,这是JIT,因为进程已经开始运行了,但是,为什么不能看做是先编译再执行的AOT模式,只是整个过程被批处理化了呢?  

带着这个问题再考虑很多资料(包括wiki)对JIT的另一个描述,JIT是在运行时将解释执行的语言(比如字节码)编译成机器指令,以提高运行速度。这个看法在前面的某篇也提过,的确很多JIT编译器,比如java的就是这么干的(我们下面就拿java举例),但是,既然字节码编译成机器指令可以提高速度,为何一定要放在运行时进行,做成AOT模式不是可以运行得更流畅吗,而且还能一次编译,N次执行,为啥非要做成运行时做,JIT本来是要提高运行速度,但这岂不是降低了效率?  

这种看法是有道理的,事实上,java的确有一些AOT编译器,可以将字节码甚至java源码直接编译成机器指令的可执行文件,微软当初的VJ++似乎就这么搞的,和sun打了很久的架,sun还喊出了pure java(纯粹的java,即按照sun的设计理念和标准来实现java)的口号,有兴趣可以去搜一下这段历史,挺搞笑的  

另一方面,sun的jvm虽然采用了JIT编译,但同时也提供了client和server模式,在server模式下,虚拟机在一开始执行的时候会先尽可能多地对字节码进行编译,且优化程度也尽量高,这样可以使得服务器在运行过程中能尽量少卡顿,根据上面的讨论,这实际上相当于AOT批处理了。client模式下则不会这样做,主要是为了尽量缩短启动延迟,提高用户体验  

顺便说一句,对于JIT将字节码编译成机器指令,wiki的描述比较暧昧,有时候用MAChine code,有时候用native code,比方说我们用java实现一个A语言的虚拟机,解释A的字节码执行,并将字节码编译成java自己的字节码,这也是JIT,因为A跑在jvm上,则java字节码就看做是native code,而MAChine code这个MAChine也不见得是真实机器,jvm也是一种机器  

由于JIT编译耗费运行时间,则对于某些优化点就无法做到百分百支持,必须在代码优化和执行卡顿之间做一个权衡,AOT就没有这个问题,另外,AOT可以做到编译后持久化到存储,而JIT一般是每运行一次就会搞一遍重复的编译

如果我们不考虑AOT本身耗费的时间(比如编译一次,N次运行),也不考虑使用上的方便性(AOT可能会有多次编译过程),那是不是可以认为,AOT编译可以完全替换JIT编译,JIT就完全没必要了,实际情况当然不是这样,JIT还是有它的优势和必要性的,否则研究它的那群人岂不都是傻子  

从动静态来看这个问题,AOT是静态编译,而JIT是运行时动态编译,则JIT的优势在于,它不但能看到静态信息(代码),还能看到运行时的情况,这就是JIT的优势。接下来讨论的JIT是一种狭义的JIT,即在AOT搞不定的地方使用的JIT,而非上述形式上的  

关于JIT的优势,wiki上给出了四点理由,但有意思的是,其中有两条连它自己都承认并非只有JIT能做,也就是说至少理论上,用AOT实现(或部分实现)是可行的,这四条是:  
一、JIT可以根据当前的硬件情况实时编译成最优机器指令,比如cpu中如果含FPU,MMX,SSE2,或者Intel cpu的并行计算特性,则可以做到同一份字节码,在不同机器运行时最大限度利用硬件资源。而如果是AOT编译一个程序放出去给不同用户使用,就只能去兼容特性最少的cpu,或者内部实现多个版本  
二、JIT可以根据当前进程实际运行状态,将字节码编译成适合最优化的机器指令序列。wiki认为静态编译也可以通过分析profile来实现这方面的优化(可能有点麻烦)  
三、当程序需要支持动态链接时,即在静态编译阶段,可能不知道运行时会引入什么样的代码来和程序协作执行,这时候就只能依靠JIT  
四、考虑到垃圾收集,JIT可以根据进程中的内存实际情况来调整代码,使得cache能更充分地使用,wiki认为静态编译也可以做到,但JIT做起来更容易实现  

对于第一条,JIT的确可以实现这种优化,但是AOT一样可以实现,虽然AOT编译一个程序给不同用户执行无法做到,但是可以编译字节码发布,用户使用时再根据当前机器再做一次AOT  
对于第二条,首先我认为大多数程序的运行状态不会经常变动,比如同一个程序有时候是整数计算居多,有时候是浮点计算居多,一般来说程序应用场景是固定的;其次对于特定场景也可以AOT  
对于第三条,的确动态链接的全文静态优化AOT无法做到,但是如上篇所说,必要时候我们可以直接砍掉语言的动态性,再者静态编译时候也不是什么都感知不到,比如C语言做静态链接时,至少是知道头文件的,动态性没那么强  
对于第四条,AOT也是有可能实现的,虽然麻烦很多。另一方面,静态编译时也有指令乱序来提高cache使用效果,再者这块也和垃圾收集算法、程序本身的局部性有很大关系,如果程序本身写的烂,这个调整效果可能也比较有限  

所以我觉得,这四条虽然都有道理,但没精确说到点子上。再来审视这个问题,我们可以看出,从理论上讲,AOT可以完全代替JIT,因为一个进程的状态是有限的,AOT可以预测所有可能情况并进行优化,实际运行时的状态不会超出AOT的预测,采用最优代码执行即可,而JIT在这里的优势就是,它能精准地得知运行时状态,而不是像AOT那样预测,成本更低,如果一个AOT优化的成本过高,则应该选择JIT。AOT不是不能做,而是不可行  

JIT相关的资料,相比wiki我更推荐这篇论文:《Representation-based Just-in-time Specialization and the Psyco prototype for Python》 by Armin Rigo,这个论文是以python和其JIT插件库psyco为例来分析,论文题目中的单词Specialization可谓画龙点睛,它指出至少在动态类型语言中,JIT的关键作用之一是特化,用上篇的话说,就是动态行为静态化,而这些场景中AOT不可行的原因是它很难找到特化的方向,而枚举所有特化是不可行的  

一个典型的特化案例,也是论文中提到的,假设有一个函数f(x,y),则对于x的输入x1,x2,x3...,我们可以特化这个函数为f1(y),f2(y),f3(y)...,其中fk(y)在功能上对应f(xk,y),这样一来,每个fk可以单独地做优化,与其他函数无关,而特化后的函数列表至少不会比原来的f(x,y)慢。唯一的问题是,x的取值可能很多,比如x是一个int,则如果采用AOT方式来特化,则需要编译42亿多个函数,这显然是不现实的,但是JIT就有可能对这个场景做优化,原因在于,x的取值虽然很多,但在一个具体运行过程中范围相对小,甚至是很小,这符合二八定律  

于是,在运行时我们可以对函数f做监控,统计每次输入的x的值,如果发现这些值的分布不平均,比如x为123的情况占大多数,则动态特化一个f123(y),对其进行高度优化,然后修改f函数为:  
func f(x, y): 
    if x == 123: 
        return f123(y) 
    ... //f的正常流程 
于是只需要一个特化函数,就能带来运行时效率的提升,这就是JIT特化的优势  

对很多程序来说,对这种数值做监控和特化可能性价比不高,因为不是每个函数的输入值范围都呈现不平衡状态,或者说不是那么明显,但上面这个例子中,x和y不一定是变量,也可以是类型,这样一来对动态类型语言就有很大的意义  

前面讲过,在C++中可以用模板来实现鸭子类型,实质是通过代码替换来实现类型静态化,C++这个方式虽然效率高,但渠道是通过静态编译中的全文分析,是AOT编译,如果改成稍微动态性强一些的语言,就用不上了。在动态类型中,一个函数如果有k个参数,有n个可能类型,则AOT需要将一个函数扩展为n^k个特化实例,n和k稍大一点就不可操作了,何况本身就是动态类型,n的范围都不一定在编译期能知道  

对这种场景,JIT就可以通过统计的方式来选择性地特化,这个的可行性和现实意义更大,原因在于,程序员在用动态类型写程序的时候,比如写一个函数:  
func f(x, y): 
    return x + y 
理论上,这个函数可以接受任意类型的x和y,只要x能和y相加即可,但具体到一个确定的程序,这个函数的业务意义一般是固定的,或者是做字符串拼接,或者是数值相加,很少说写一个函数,接收八竿子打不着的不同的类型还能运算,而且还是程序员刻意这么设计,就像前面讲过的C++模板的二义性一样,基本见不到这种需求,所以在函数的输入参数类型上,符合二八定律。于是对于上述代码,假设x和y绝大多数情况下都是整数,则进行特化(假设这个伪代码中不考虑整数溢出):  
func f(x, y): 
    if not (x instanceof int and y instanceof int): 
        //有一个不是整数,走原有流程 
        return x + y 
    //整数加法的特化流程 
    internal_code: 
        int ix = get_internal_int(x) 
        int iy = get_internal_int(y) 
        int iresult 
        asm: 
            push ... //当前状态压栈 
            mov eax, ix 
            mov ebx, iy 
            add eax, ebx 
            mov iresult, eax 
            pop ... //状态出栈 
        return build_int_object(iresult)
 
当然这只是个例子,如果只是为了一个加法,这多少有点小题大做,但如果f的逻辑较为复杂,优化就很明显了  

还可以逆向思维一下,AOT难以实现特化的原因是无法考虑所有情况,但我们也没有必要考虑所有情况,实际上类型使用的二八定律本身也在另一个二八定律里,具体到int类型,一个绝大多数使用到的类型都是int的程序在所有程序中占绝大多数,至少在一个有限的领域是这样,因此干脆对于每个函数都只做int相关的特化,这样2^k种情况还算能接受(实际情况数比2^k低很多,因为很多参数如果被假定为int,会语法错误,就不用假设了),如果再做的好一点,还可以做成编译器选项,由用户来指定AOT的时候对哪个类型特化,这样就比较完美了  

除类型的动态性外,其他动态性也可以类似讨论,仅拿上篇的例子,不赘述了:  
for i in range(n): 
    print(i) 
转换为:  
if not (range is builtins.range and print is builtins.print): 
    for i in range(n): 
        print(i) 
else: 
    internal_code: 
        long tmp = get_internal_long(n) 
        long i 
        //这里应该用汇编,仅表个意思 
        for (i = 0; i < tmp; ++ i): 
            print_long(i) 
需要在程序启动时在builtins里面保存默认函数,用于检测当前运行环境是否被用户修改过,这样就兼顾了效率和动态性,跟上面一样,这里JIT或AOT实现都可以