开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第13天，点击查看活动详情
JIT技术 提出疑问：为什么应用刚启动的时候比较卡，过一会就好了？
解答：
JVM 中内置了解释器，在运行时对字节码进行解释翻译成机器码，然后再执行。
解释器的执行方式是一边翻译，一边执行，因此执行效率很低。为了解决这样的低效问题，HotSpot 引入了JIT 技术。
有了 JIT 技术之后，JVM 虽然还是通过解释器进行解释执行，但是，当 JVM 发现某个方法或代码块运行时执行的特别频繁的时候，就会认为这是“热点代码”，然后 JIT 会把部分“热点代码”翻译成本地机器相关的机器码，并进行优化，然后再把翻译后的机器码缓存起来，以备下次使用，这也是 HotSpot 虚拟机的名字的由来。
JIT 优化是在运行期进行的，并且也不是 Java 进程刚一启动就能优化的，是需要先执行一段时间的，因为他需要先知道哪些是热点代码。
所以，在 JIT 优化开始之前，我们的所有请求，都是要经过解释执行的，这个过程就会相对慢一些。
如果请求量比较大的的话，这种问题就会更加明显，在应用启动过程中，会有大量的请求过来，这就会导致解释器持续的在努力工作。一旦解释器对 CPU 资源占用比较大的话，就会间接的导致 CPU、LOAD 等飙高，导致应用的性能进一步下降。
这也是为什么很多应用在发布过程中，会出现刚刚重启好的应用会发生大量的超时问题了。而随着请求的不断增多，JIT 优化就会被触发，这就是使得后续的热点请求的执行可能就不需要在通过解释执行了，直接运行 JIT 优化后缓存的机器码就行了。
解决思路：
1、提升 JIT 优化的效率
2、降低瞬时请求量
在提升 JIT 优化效率的设计上，大家可以了解一下阿里研发的 JDK——Dragonwell。
这个相比 OpenJDK 提供了一些专有特性，其中一项叫做JwarmUp的技术就是解决 JIT 优化效率的问题的。
这个技术主要是通过记录 Java 应用上一次运行时候的编译信息到文件中，在下次应用启动时，读取该文件，从而在流量进来之前，提前完成类的加载、初始化和方法编译，从而跳过解释阶段，直接执行编译好的机器码。
除了针对 JDK 做优化之外，还可以采用另外一种方式来解决这个问题，那就是做预热。
很多人都听说过缓存预热，其实思想是类似的。
就是说在应用刚刚启动的时候，通过调节负载均衡，不要很快的把大流量分发给他，而是先分给他一小部分流量，通过这部分流量来触发 JIT 优化，等优化好了之后，再把流量调大。
