JVM:浅谈CodeCache

  在一次使用Arthas查看线上服务的JVM参数的时候，偶然发现dashboard上出现了一个之前没有留意过的区域-----CodeCache。后面经过查阅资料，终于弄清楚这个CodeCache是用来做什么的。

Dashboard

  在JVM中，java代码默认都是解释执行的。当某个方法被多次调用或者某个循环体被多次执行，触发JVM内置计数器的阈值时(该阈值在Client模式下默认为1500次，在Server模式下默认是10000次，我们可以通过JVM参数 -XX:CompileThreshold来设置)，将会触发JIT编译。当一个方法或某段代码被执行时，首先会去检查该方法/代码是否存在被JIT编译过的版本，如果存在，则优先使用编译后的本地代码来执行。在程序需要迅速启动和执行的时候，可以采用解释执行的方式，省去编译的时间，可以立刻执行代码。随着程序的不断运行，就可以采取编译执行的方式，使用JIT将代码编译到本地，提升执行效率。
  上面提到的经过JIT编译的本地代码会暂存在JVM的一块内存中，这部分内存区域就称为CodeCache，属于堆外内存。在我们的线上服务里，CodeCache默认为240M，其默认值与JVM的版本以及启动方式有关。下面列出不同模式下的CodeCache的大小:

JVM 版本和启动方式	默认 codeCache大小
Java 8 32-bit client	32M
Java 8 32-bit server	48M
Java 8 32-bit server with Tiered Compilation(分层编译)	240M
Java 8 64-bit server	48M
Java 8 64-bit server with Tiered Compilation	240M
Java 7 32-bit server	32M
Java 7 64-bit server	48M
Java 7 32-bit server with Tiered Compilation	96M
Java 7 64-bit server	48M
Java 7 64-bit server with Tiered Compilation	96M

  同JVM中其他区域一样，CodeCache也存在耗尽的可能。随着程序的运行，越来越多的方法被JIT编译，成为本地代码，保存在CodeCache中。当内存被耗尽时，JIT将停止编译执行，已编译的方法不受影响，未来得及编译的方法只能采取解释执行的方式。系统的表现就是响应变慢，CPU居高不下。说到底，这个还是JVM的锅，他们采用了Speculative flushing的策略来回收CodeCache的空间，当CodeCache将要耗尽时，JVM会将最早编译的一部分方法放到一个待回收队列中，如果在一定时间内该方法没有被调用，则该方法的本地代码将会从CodeCache中移除，而正是这个策略导致CPU被大量占用。另外，是否开启Speculative flushing由-XX:+UseCodeCacheFlushing参数控制。
  为了避免CodeCache耗尽，我们可以为我们的服务配置一个JVM参数:-XX:+PrintCodeCache(JDK8以上有效)，该参数的作用是在服务停止时，打印出CodeCache的使用情况，其中max_used就是在服务运行过程中CodeCache的最大使用量，我们可以通过设置-XX:ReservedCodeCacheSize将CacheCode调整为合适的大小来避免这部分内存耗尽。

PrintCodeCache

  以上就是我对于CodeCache的理解。