为什么JIT
JIT 是 just in time 的缩写, 也就是即时编译编译器。使用即时编译器技术，能够加速程序的执行速度。
以Java/C#,NET为代表的Coffee Based 语言，是建立在虚拟机之上的。
这种虚拟机和一般其他语言的运行库有一个很大不同，就是它好像一个有独立体系结构的计算机。
Java/C#,NET的程序要运行在这些虚拟机之上，就必须要编译成虚拟机独有的中间语言。Java叫字节码，C#,NET有很多种叫法，姑且简称CIL。这些中间语言身上有很深很深的汇编指令集样式语法痕迹，这也从 另一个侧面说明虚拟机的体系结构多么像一个冯诺依曼计算机。
虚拟机传统的解释器，就是要在中间语言，和真正的平台体系结构之间的指令做映射。比如把Java的load指令换成native code 的load指令。
JIT的出现，是为了补强虚拟机边运行边解释的低性能。它会智能地对热点代码进行优化且重复利用。从策略的角度来讲，就是通过查表或者缓存而不是重复解决子问题而大大缩短解决问题的时间。
它的优点是，智能缩短映射的过程。
它的缺点是，过于复杂。
首先代码优化的种种策略都是基于各种各样的假定，假定不一定会成真，即使费尽心机做的代码优化，也有可能在现实中无法提高性能。其次，不同平台和体系结构的技术特点千差万别，这个映射过程只能单独定制。比如至今Java平台还不能在IOS上做基本映射（即解释器都不行）。
以前JIT刚出现的时候，只是一个挂载的外挂一样的东西。现在开始喧宾夺主取代了解释器。这种转变其实是对中间语言解释器作为一个“薄的胶合层”的一个设计上的自我否定，极大地增加了设计的复杂性。目前对于这种强行加速做得比较好的，就是Java系为代表的各种虚拟机，微软的虚拟机，或者谷歌搞出来的V8引擎（这不知道是不是目前为止设计进生产实践中惟一被广泛应用的动态强行加速）。这几件东西其实无一不是大型商业公司的强大支持的产物。现在主流的动态语言大多都是社区在推进，没那么多资源来投入JIT，这是他们没有好的JIT的一个关键因素。
本身动态语言的应用场景就不是为了追求高性能，更何况现在各种应用场景下的瓶颈大部分都在语言之外，语言的性能考量又是一个比较次要的需求了。但是JIT对于编译层的优化还是显而易见的，甚至可以说汇聚了很多生产环境中的经验，通过JIT的优化，服务的请求质量可以提升一个档次，对于业务帮助也很大，下面我们着重介绍一下java中的JIT与其实现。
Java中的JIT
Java程序最初是仅仅通过解释器解释执行的，即对字节码逐条解释执行，这种方式的执行速度相对会比较慢，尤其当某个方法或代码块运行的特别频繁时，这种方式的执行效率就显得很低。于是后来在虚拟机中引入了JIT编译器（即时编译器），当虚拟机发现某个方法或代码块运行特别频繁时，就会把这些代码认定为“Hot Spot Code”（热点代码），为了提高热点代码的执行效率，在运行时，虚拟机将会把这些代码编译成与本地平台相关的机器码，并进行各层次的优化，完成这项任务的正是JIT编译器。
现在主流的商用虚拟机（如Sun HotSpot、IBM J9）中几乎都同时包含解释器和编译器（三大商用虚拟机之一的JRockit是个例外，它内部没有解释器，因此会有启动相应时间长之类的缺点，但它主要是面向服务端的应用，这类应用一般不会重点关注启动时间）。二者各有优势：当程序需要迅速启动和执行时，解释器可以首先发挥作用，省去编译的时间，立即执行；当程序运行后，随着时间的推移，编译器逐渐会返回作用，把越来越多的代码编译成本地代码后，可以获取更高的执行效率。解释执行可以节约内存，而编译执行可以提升效率。
HotSpot虚拟机中内置了两个JIT编译器：Client Complier和Server Complier，分别用在客户端和服务端，分别对应JVM的Client与Server模式，目前主流的HotSpot虚拟机中默认是采用解释器与其中一个编译器直接配合的方式工作。
运行过程中会被即时编译器编译的“热点代码”有两类：
- 被多次调用的方法。
被多次调用的循环体。
两种情况，编译器都是以整个方法作为编译对象，这种编译也是虚拟机中标准的编译方式。要知道一段代码或方法是不是热点代码，是不是需要触发即时编译，需要进行Hot Spot Detection（热点探测）。目前主要的热点 判定方式有以下两种：
基于采样的热点探测：采用这种方法的虚拟机会周期性地检查各个线程的栈顶，如果发现某些方法经常出现在栈顶，那这段方法代码就是“热点代码”。这种探测方法的好处是实现简单高效，还可以很容易地获取方法调用关系，缺点是很难精确地确认一个方法的热度，容易因为受到线程阻塞或别的外界因素的影响而扰乱热点探测。
基于计数器的热点探测：采用这种方法的虚拟机会为每个方法，甚至是代码块建立计数器，统计方法的执行次数，如果执行次数超过一定的阀值，就认为它是“热点方法”。这种统计方法实现复杂一些，需要为每个方法建立并维护计数器，而且不能直接获取到方法的调用关系，但是它的统计结果相对更加精确严谨。
在HotSpot虚拟机中使用的是第二种——基于计数器的热点探测方法，因此它为每个方法准备了两个计数器：方法调用计数器和回边计数器。
方法调用计数器用来统计方法调用的次数，在默认设置下，方法调用计数器统计的并不是方法被调用的绝对次数，而是一个相对的执行频率，即一段时间内方法被调用的次数。
回边计数器用于统计一个方法中循环体代码执行的次数（准确地说，应该是回边的次数，因为并非所有的循环都是回边），在字节码中遇到控制流向后跳转的指令就称为“回边”。
在确定虚拟机运行参数的前提下，这两个计数器都有一个确定的阀值，当计数器的值超过了阀值，就会触发JIT编译。触发了JIT编译后，在默认设置下，执行引擎并不会同步等待编译请求完成，而是继续进入解释器按照解释方式执行字节码，直到提交的请求被编译器编译完成为止（编译工作在后台线程中进行）。当编译工作完成后，下一次调用该方法或代码时，就会使用已编译的版本。
由于方法计数器触发即时编译的过程与回边计数器触发即时编译的过程类似，因此这里仅给出方法调用计数器触发即时编译的流程：
jvm使用JIT
JIT是java性能在同等条件下课超越C系列语言的关键！
