jvm——CodeCache

https://juejin.im/post/5c890f21f265da2d993dc692

CodeCache是热点代码的暂存区，经过即时编译器编译的代码会放在这里，它存在于堆外内存。除了JIT编译的代码之外，Java所使用的本地方法代码（JNI）也会存在codeCache中。

JVM内部会先尝试解释执行Java字节码，当方法调用或循环回边达到一定次数时，会触发即时编译，将Java字节码编译成本地机器码以提高执行效率。这个编译的本地机器码是缓存在CodeCache中的，如果有大量的代码触发了即时编译，而且没有及时GC的话，CodeCache就会被填满。

一旦CodeCache被填满，已经被编译的代码还会以本地代码方式执行，但后面没有编译的代码只能以解释执行的方式运行。

通过第2小节的比较，可以清晰看出解释执行和编译执行的性能差异。所以对于大多数应用来说，这种情况的出现是灾难性的。

JVM针对CodeCache提供了GC方式： -XX:+UseCodeCacheFlushing。在JDK1.7.0_4之后这个参数默认开启，当CodeCache即将填满时会尝试回收。JDK7在这方面的回收做的不是很少，GC收益较低，在JDK8有了很大的改善，所以可以通过升级到JDK8来直接提升这方面的性能。

在Java8中提供了一个JVM启动参数：-XX:+PrintCodeCache，他可以在JVM停止时打印CodeCache的使用情况，可以在每次停止应用时观察一下这个值，慢慢调整为一个最合适的大小。

通过在启动参数上增加：-XX:+UseCodeCacheFlushing 来启用；

打开这个选项，在JIT被关闭之前，也就是CodeCache装满之前，会在JIT关闭前做一次清理，删除一些CodeCache的代码；

如果清理后还是没有空间，那么JIT依然会关闭。这个选项默认是关闭的；

在JDK8中，当以server模式启动时，分层编译默认开启。需要注意的是，分层编译方式只能用于server模式中，如果需要关闭分层编译，需要加上启动参数 -XX:-TieredCompilation；如果以client模式启动，-XX:+TieredCompilation 参数将会被忽略。

https://juejin.im/post/5aebf997f265da0ba76f99db

JIT编译器被停止了，并且不会被重新启动，此时会回归到解释执行；

被编译过的代码仍然以编译方式执行，但是尚未被编译的代码就只能以解释方式执行了。
针对这种情况，JVM提供了一种比较激进的codeCache回收方式：Speculative flushing。

在JDK1.7.0_4之后这种回收方式默认开启，而之前的版本需要通过一个启动参数来开启：-XX:+UseCodeCacheFlushing。

在Speculative flushing开启的情况下，当codeCache将要耗尽时：

最早被编译的一半方法将会被放到一个old列表中等待回收；

在一定时间间隔内，如果old列表中方法没有被调用，这个方法就会被从codeCache充清除；

Code Cache满了时紧急进行清扫工作，它会丢弃一半老的编译代码；

Code Cache空间降了一半，方法编译工作仍然可能不会重启；

flushing可能导致高的cpu使用，从而影响性能下降；

JDK 8对codeCache的回收有了很明显的改善。不仅codeCache的增长比较平缓，而且当使用量达到75%时，回收力度明显加大，codeCache使用量在这个值上下浮动，并缓慢增长。最重要的是，JIT编译还在正常执行，系统运行速度也没有收到影响。