0 問題描述
一個(gè)應(yīng)用在運(yùn)行一段時(shí)間后，隨著訪問量不斷增加灵奖，突然處理能力下降。但是從流量估盘，jstack瓷患，gc上看基本正常。感覺好像突然從 “健康狀態(tài)” 進(jìn)入了 “虛弱狀態(tài)”忿檩。
1 排查問題
-
在JVM日志里尉尾，可以發(fā)現(xiàn)如下log：
Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=. ... “CompilerThread0” java.lang.OutOfMemoryError: requested 2854248 bytes for Chunk::new. Out of swap space?說明CodeCache已經(jīng)滿了。而且導(dǎo)致這個(gè)時(shí)候JIT就會(huì)停止燥透，JIT一旦停止，就不會(huì)再起來了辨图，可以想象一下班套，如果很多代碼沒有辦法去JIT的話，性能就會(huì)比較差故河。
-
使用如下命令檢查一下Code Cache的值：
jinfo -flag ReservedCodeCacheSize
2 解決問題
-
一個(gè)可行的方法吱韭，就是擴(kuò)大Code Cache空間：
使用 -XX:ReservedCodeCacheSize= 指定一個(gè)更大的空間，來支持更多的JIT編譯；
-
此外理盆，另一個(gè)可行的方法痘煤，啟用Code Cache的回收機(jī)制：
通過在啟動(dòng)參數(shù)上增加：-XX:+UseCodeCacheFlushing 來啟用；
打開這個(gè)選項(xiàng)猿规，在JIT被關(guān)閉之前衷快，也就是CodeCache裝滿之前，會(huì)在JIT關(guān)閉前做一次清理姨俩，刪除一些CodeCache的代碼蘸拔；
如果清理后還是沒有空間，那么JIT依然會(huì)關(guān)閉环葵。這個(gè)選項(xiàng)默認(rèn)是關(guān)閉的调窍；
3 背景知識(shí)
3.1 JIT即時(shí)編譯
在Java中提到“編譯”，自然很容易想到 javac 編譯器將.java文件編譯成為.class文件的過程张遭，這里的 javac 編譯器稱為前端編譯器邓萨，其他的前端編譯器還有諸如Eclipse，JDT中的增量式編譯器ECJ等菊卷。相對(duì)應(yīng)的還有 后端編譯器缔恳，它在程序運(yùn)行期間將字節(jié)碼轉(zhuǎn)變成機(jī)器碼（現(xiàn)在的Java程序在運(yùn)行時(shí)基本都是 解釋執(zhí)行加編譯執(zhí)行），如HotSpot虛擬機(jī)自帶的JIT（Just In Time Compiler）編譯器（分Client端和Server端）的烁。
Java程序最初是僅僅通過解釋器解釋執(zhí)行的褐耳，即對(duì)字節(jié)碼逐條解釋執(zhí)行，這種方式的執(zhí)行速度相對(duì)會(huì)比較慢渴庆，尤其當(dāng)某個(gè)方法或代碼塊運(yùn)行的特別頻繁時(shí)铃芦，這種方式的執(zhí)行效率就顯得很低。于是后來 在虛擬機(jī)中引入了JIT編譯器（即時(shí)編譯器）襟雷，當(dāng)虛擬機(jī)發(fā)現(xiàn)某個(gè)方法或代碼塊運(yùn)行特別頻繁時(shí)刃滓，達(dá)到某個(gè)閾值，就會(huì)把這些代碼認(rèn)定為“Hot Spot Code”（熱點(diǎn)代碼）耸弄，為了提高熱點(diǎn)代碼的執(zhí)行效率咧虎，在運(yùn)行時(shí)，虛擬機(jī)將會(huì)把這些代碼編譯成與本地平臺(tái)相關(guān)的機(jī)器碼计呈，并進(jìn)行各層次的優(yōu)化砰诵，完成這項(xiàng)任務(wù)的正是JIT編譯器。
現(xiàn)在主流的商用虛擬機(jī)（如：Sun HotSpot捌显、IBM J9）中幾乎 都同時(shí)包含解釋器和編譯器茁彭，三大商用虛擬機(jī)之一的JRockit是個(gè)例外，它內(nèi)部沒有解釋器扶歪，因此會(huì)有啟動(dòng)相應(yīng)時(shí)間長(zhǎng)之類的缺點(diǎn)理肺，但它主要是面向服務(wù)端的應(yīng)用，這類應(yīng)用一般不會(huì)重點(diǎn)關(guān)注啟動(dòng)時(shí)間。
解釋器與編輯器二者各有優(yōu)勢(shì)：
- 當(dāng)程序需要迅速啟動(dòng)和執(zhí)行時(shí)妹萨，解釋器可以首先發(fā)揮作用年枕，省去編譯的時(shí)間，立即執(zhí)行乎完；
- 當(dāng)程序運(yùn)行后熏兄，隨著時(shí)間的推移，編譯器逐漸會(huì)發(fā)揮作用囱怕，把越來越多的代碼編譯成本地代碼后霍弹，可以獲取更高的執(zhí)行效率；
- 解釋執(zhí)行可以節(jié)約內(nèi)存娃弓，而編譯執(zhí)行可以提升效率典格；
運(yùn)行過程中會(huì)被即時(shí)編譯器編譯的“熱點(diǎn)代碼”有兩類：
- 被多次調(diào)用的方法；
- 被多次調(diào)用的循環(huán)體台丛；
3.2 Code Cache
Java代碼在執(zhí)行時(shí)一旦被編譯器編譯為機(jī)器碼耍缴，下一次執(zhí)行的時(shí)候就會(huì)直接執(zhí)行編譯后的代碼，也就是說挽霉，編譯后的代碼被緩存了起來防嗡。緩存編譯后的機(jī)器碼的內(nèi)存區(qū)域就是codeCache。這是一塊獨(dú)立于Java堆之外的內(nèi)存區(qū)域侠坎。除了JIT編譯的代碼之外蚁趁，Java所使用的本地方法代碼（JNI）也會(huì)存在codeCache中。
Code Cache是JVM用于存儲(chǔ)經(jīng)過JIT C1/C2編譯優(yōu)化后的代碼他嫡。因?yàn)槭谴嬖趦?nèi)存中的，所以肯定得限制大小庐完，Code Cache的最大大小可通過jinfo -flag ReservedCodeCacheSize來獲取钢属，通常在64 bit機(jī)器上默認(rèn)是48m。
不同版本的JVM门躯、不同的啟動(dòng)方式codeCache的默認(rèn)大小也不同：
| JVM 版本和啟動(dòng)方式 | 默認(rèn) codeCache大小 |
|---|---|
| 32-bit client, Java 8 | 32 MB |
| 32-bit server, Java 8 | 48M |
| 32-bit server with Tiered Compilation, Java 8 | 240 MB |
| 64-bit server, Java 8 | 48M |
| 64-bit server with Tiered Compilation, Java 8 | 240 MB |
| 32-bit client, Java 7 | 32 MB |
| 32-bit server, Java 7 | 48 MB |
| 32-bit server with Tiered Compilation, Java 7 | 96 MB |
| 64-bit server, Java 7 | 48 MB |
| 64-bit server with Tiered Compilation, Java 7 | 96 MB |
3.3 分層編譯
JVM提供了一個(gè)參數(shù)-Xcomp淆党，可以使JVM運(yùn)行在純編譯模式下，所有方法在第一次被調(diào)用的時(shí)候就會(huì)被編譯成機(jī)器代碼讶凉。加上這個(gè)參數(shù)之后染乌，隨之而來的問題是啟動(dòng)時(shí)間變得很長(zhǎng)，差不多是原來的2倍還多懂讯。
除了純編譯方式和默認(rèn)的mixed之外慕匠，從JDK6u25開始引入了一種分層編譯的方式。
Hotspot JVM內(nèi)置了2種編譯器域醇，分別是 client方式啟動(dòng)時(shí)用的C1編譯器 和 server方式啟動(dòng)時(shí)用的C2編譯器 。
C2編譯器在將代碼編譯成機(jī)器碼之前，需要收集大量的統(tǒng)計(jì)信息以便在編譯的時(shí)候做優(yōu)化譬挚，因此編譯后的代碼執(zhí)行效率也高锅铅，代價(jià)是程序啟動(dòng)速度慢，并且需要比較長(zhǎng)的執(zhí)行時(shí)間才能達(dá)到最高性能减宣；
C1編譯器的目標(biāo)在于使程序盡快進(jìn)入編譯執(zhí)行階段盐须，因此編譯前需要收集的統(tǒng)計(jì)信息比C2少很多，編譯速度也快不少漆腌。代價(jià)是編譯出的目標(biāo)代碼比C2編譯的執(zhí)行效率要低贼邓。
盡管如此，C1編譯的執(zhí)行效率也比解釋執(zhí)行有巨大的優(yōu)勢(shì)闷尿。分層編譯方式是一種折衷方式塑径，在系統(tǒng)啟動(dòng)之初執(zhí)行頻率比較高的代碼將先被C1編譯器編譯，以便盡快進(jìn)入編譯執(zhí)行填具。隨著時(shí)間推進(jìn)统舀，一些執(zhí)行頻率高的代碼會(huì)被C2編譯器再次編譯，從而達(dá)到更高的性能劳景。
通過以下JVM參數(shù)開啟分層編譯模式：
-XX:+TieredCompilation
在JDK8中誉简，當(dāng)以server模式啟動(dòng)時(shí)，分層編譯默認(rèn)開啟盟广。需要注意的是闷串，分層編譯方式只能用于server模式中，如果需要關(guān)閉分層編譯筋量，需要加上啟動(dòng)參數(shù) -XX:-TieredCompilation烹吵；如果以client模式啟動(dòng)，-XX:+TieredCompilation 參數(shù)將會(huì)被忽略毛甲。
3.4 Code Cache 滿了怎么辦
隨著時(shí)間推移年叮，會(huì)有越來越多的方法被編譯，codeCache使用量會(huì)逐漸增加玻募，直至耗盡只损。當(dāng)Code Cache用滿了后，會(huì)打印下面的日志：
在JDK1.7.0_4之前七咧，你會(huì)在jvm的日志里看到這樣的輸出：
Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=.
...
“CompilerThread0” java.lang.OutOfMemoryError: requested 2854248 bytes for Chunk::new. Out of swap space?
JIT編譯器被停止了跃惫，并且不會(huì)被重新啟動(dòng)，此時(shí)會(huì)回歸到解釋執(zhí)行艾栋；
被編譯過的代碼仍然以編譯方式執(zhí)行爆存，但是尚未被編譯的代碼就 只能以解釋方式執(zhí)行了。
針對(duì)這種情況蝗砾，JVM提供了一種比較激進(jìn)的codeCache回收方式：Speculative flushing先较。
在JDK1.7.0_4之后這種回收方式默認(rèn)開啟携冤，而之前的版本需要通過一個(gè)啟動(dòng)參數(shù)來開啟：-XX:+UseCodeCacheFlushing。
在Speculative flushing開啟的情況下闲勺，當(dāng)codeCache將要耗盡時(shí)：
最早被編譯的一半方法將會(huì)被放到一個(gè)old列表中等待回收曾棕；
在一定時(shí)間間隔內(nèi)，如果old列表中方法沒有被調(diào)用菜循，這個(gè)方法就會(huì)被從codeCache充清除翘地；
很不幸的是，在JDK1.7中癌幕，當(dāng)codeCache耗盡時(shí)衙耕，Speculative flushing釋放了一部分空間，但是從編譯日志來看勺远，JIT編譯并沒有恢復(fù)正常橙喘，并且系統(tǒng)整體性能下降很多，出現(xiàn)大量超時(shí)谚中。
在Oracle官網(wǎng)上看到這樣一個(gè)Bug：http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8006952 由于codeCache回收算法的問題渴杆，當(dāng)codeCache滿了之后會(huì)導(dǎo)致編譯線程無法繼續(xù)，并且消耗大量CPU導(dǎo)致系統(tǒng)運(yùn)行變慢宪塔。Bug里影響版本是JDK8磁奖，但是從網(wǎng)上其他地方的信息看，JDK7應(yīng)該也存在相同的問題某筐，并且沒有被修復(fù)比搭。
所以，目前來看南誊，開啟UseCodeCacheFlushing會(huì)導(dǎo)致問題身诺，如下：
- Code Cache滿了時(shí)緊急進(jìn)行清掃工作，它會(huì)丟棄一半老的編譯代碼抄囚；
- Code Cache空間降了一半霉赡，方法編譯工作仍然可能不會(huì)重啟；
- flushing可能導(dǎo)致高的cpu使用幔托，從而影響性能下降穴亏；
3.6 Code Cache 調(diào)優(yōu)
以client模式或者是分層編譯模式運(yùn)行的應(yīng)用，由于需要編譯的類更多（C1編譯器編譯閾值低重挑，更容易達(dá)到編譯標(biāo)準(zhǔn)）嗓化，所以更容易耗盡codeCache。當(dāng)發(fā)現(xiàn)codeCache有不夠用的跡象（通過上一節(jié)提到的監(jiān)控方式）時(shí)谬哀，可以通過啟動(dòng)參數(shù)來調(diào)整codeCache的大小刺覆。
-XX:ReservedCodeCacheSize=256M
那具體應(yīng)該設(shè)置為多大合適，根據(jù)監(jiān)控?cái)?shù)據(jù)估算史煎，例如單位時(shí)間增長(zhǎng)量谦屑、系統(tǒng)最長(zhǎng)連續(xù)運(yùn)行時(shí)間等驳糯。如果沒有相關(guān)統(tǒng)計(jì)數(shù)據(jù)，一種推薦的設(shè)置思路是設(shè)置為當(dāng)前值（或者默認(rèn)值）的2倍伦仍。
需要注意的是结窘，這個(gè)codeCache的值不是越大越好。對(duì)于32位JVM充蓝，能夠使用的最大內(nèi)存空間為4g。這個(gè)4g的內(nèi)存空間不僅包括了java堆內(nèi)存喉磁，還包括JVM本身占用的內(nèi)存谓苟、程序中使用的native內(nèi)存（比如directBuffer）以及codeCache。如果將codeCache設(shè)置的過大协怒，即使沒有用到那么多涝焙，JVM也會(huì)為其保留這些內(nèi)存空間，導(dǎo)致應(yīng)用本身可以使用的內(nèi)存減少孕暇。對(duì)于64位JVM仑撞，由于內(nèi)存空間足夠大，codeCache設(shè)置的過大不會(huì)對(duì)應(yīng)用產(chǎn)生明顯影響妖滔。
在JDK 8中隧哮，提供了一個(gè)啟動(dòng)參數(shù) -XX:+PrintCodeCache 在JVM停止的時(shí)候打印出codeCache的使用情況。其中max_used就是在整個(gè)運(yùn)行過程中codeCache的最大使用量座舍【谙瑁可以通過這個(gè)值來設(shè)置一個(gè)合理的codeCache大小，在保證應(yīng)用正常運(yùn)行的情況下減少內(nèi)存使用曲秉。
3.7 問題解決
問題的前因后果都弄清楚了采蚀，也就好解決了。上面提到過純編譯方式和分層編譯方式都可以解決或緩解啟動(dòng)后負(fù)載過高的問題承二，那么我們就有2種選擇：
采用分層編譯方式榆鼠，并修改codeCache的大小為256M；
采用純編譯方式亥鸠，并修改codeCache的大小為256M妆够；
經(jīng)過一段時(shí)間運(yùn)行發(fā)現(xiàn)，在啟動(dòng)后負(fù)載控制方面读虏，純編譯方式要好一些责静，啟動(dòng)之后負(fù)載幾乎不上升，而 分層編譯方式啟動(dòng)后負(fù)載會(huì)有所上升盖桥，但是不會(huì)很高灾螃，也會(huì)在較短時(shí)間內(nèi)降下來。但是啟動(dòng)時(shí)間方面揩徊，分層編譯比原來的默認(rèn)啟動(dòng)方式縮短了大概10秒（原來啟動(dòng)需要110-130秒）腰鬼，而純編譯方式啟動(dòng)時(shí)間比原來多了一倍嵌赠，達(dá)到了250秒甚至更高。所以看起來分層編譯方式是更好的選擇熄赡。
然而JDK 7在codeCache的回收方面做的很不好姜挺。即使我們將codeCache設(shè)置為256M，線上還是輕易達(dá)到了設(shè)置的報(bào)警閾值200M彼硫。而且一旦codeCache滿了之后又會(huì)導(dǎo)致系統(tǒng)運(yùn)行變慢的問題炊豪。所以我們的目標(biāo)指向了JDK 8。
測(cè)試表明拧篮，JDK 8對(duì)codeCache的回收有了很明顯的改善词渤。不僅codeCache的增長(zhǎng)比較平緩，而且當(dāng)使用量達(dá)到75%時(shí)串绩，回收力度明顯加大缺虐，codeCache使用量在這個(gè)值上下浮動(dòng)，并緩慢增長(zhǎng)礁凡。最重要的是高氮，JIT編譯還在正常執(zhí)行，系統(tǒng)運(yùn)行速度也沒有收到影響顷牌。
3.8 運(yùn)行時(shí)查看Code Cache
如果想在運(yùn)行時(shí)查看code cache的大小剪芍，需要寫段代碼，目前只能通過JMX來獲取到Code Cache區(qū)域的使用狀況韧掩，代碼類似如下：
import java.io.File;
import javax.management.MBeanServerConnection;
import javax.management.ObjectName;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import com.sun.tools.attach.VirtualMachine;
public class CodeCacheUsage {
private static final String CONNECTOR_ADDRESS = "com.sun.management.jmxremote.localConnectorAddress";
public static void main(String[] args) throws Exception {
if(args.length != 1) {
System.err.println("Must enter one arg: pid");
System.exit(0);
}
VirtualMachine vm = VirtualMachine.attach(args[0]);
JMXConnector connector = null;
try {
String connectorAddress = vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);
if (connectorAddress == null) {
String agent = vm.getSystemProperties().getProperty("java.home")
+ File.separator
+ "lib"
+ File.separator + "management-agent.jar";
vm.loadAgent(agent);
connectorAddress = vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);
}
JMXServiceURL url = new JMXServiceURL(connectorAddress);
connector = JMXConnectorFactory.connect(url);
MBeanServerConnection mbeanConn = connector.getMBeanServerConnection();
ObjectName name = new ObjectName("java.lang:type=MemoryPool,name=Code Cache");
System.out.println(mbeanConn.getAttribute(name, "Usage"));
} finally {
if(connector != null)
connector.close();
vm.detach();
}
}
}
傳入pid紊浩，執(zhí)行上面的代碼后，會(huì)輸出類似下面的信息：
javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=
(
(itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),
(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),
(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),
(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long))
)),
contents={committed=50331648, init=2555904, max=50331648, used=48281152})
上面的信息顯示Code Cache區(qū)域初始化的時(shí)候?yàn)?555904疗锐，最大為50331648坊谁，已占用了50331648，使用了48281152滑臊。
