在一次使用Arthas查看线上服务的JVM参数的时候,偶然发现dashboard上出现了一个之前没有留意过的区域-----CodeCache。后面经过查阅资料,终于弄清楚这个CodeCache是用来做什么的。
在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调整为合适的大小来避免这部分内存耗尽。