[[259182]]

 1. 惡鄰A君

唯品會(huì)在服務(wù)化體系改造的初期，一個(gè)對(duì)延時(shí)敏感的應(yīng)用，偶然會(huì)發(fā)生一些超時(shí)，事發(fā)當(dāng)時(shí)zabbix分鐘級(jí)監(jiān)控，dstat秒級(jí)監(jiān)控的服務(wù)器指標(biāo)都正常，應(yīng)用，數(shù)據(jù)庫(kù)，緩存，網(wǎng)絡(luò)也正常，那這是為什么呢?

某天腦洞大開，把懷疑的目光投向了在后臺(tái)運(yùn)行日志收集程序Flume，發(fā)現(xiàn)它的GC運(yùn)行得比較狂野，于是對(duì)它的GC線程數(shù)做了限制：

• 修改前：15分鐘內(nèi)， 大于30ms的業(yè)務(wù)調(diào)用173次， 大于50ms的23次
• 修改后： 246分鐘內(nèi)，大于30ms的業(yè)務(wù)調(diào)用41次， 大于50ms的4次

2. 惡鄰B君

又過(guò)了若干個(gè)月，又有某些應(yīng)用，又開始抽風(fēng)。這次相對(duì)好查一些，因?yàn)槲覀冃律?jí)了服務(wù)器的監(jiān)控系統(tǒng)，只要在兩臺(tái)機(jī)器上做一下對(duì)比測(cè)試就好了。 只花了一個(gè)晚上，基本就能驗(yàn)明兇手了。

那這個(gè)新升級(jí)的監(jiān)控系統(tǒng)，又是怎么影響到主應(yīng)用的呢?找出它與應(yīng)用有交互的部分，原來(lái)對(duì)于JVM的各種線程數(shù)信息，堆內(nèi)存各代的信息，每拿一個(gè)數(shù)據(jù)都會(huì)啟動(dòng)一次JMX Client，所以每分鐘都有一秒要連拿7個(gè)數(shù)據(jù)，啟動(dòng)7個(gè)JMX Client。

改進(jìn)方法很簡(jiǎn)單，我們自己定制了一下JMX Client，將7個(gè)數(shù)據(jù)合并在一個(gè)命令里獲得，另外定制了一下JMX Client的JVM參數(shù)，將它啟動(dòng)的動(dòng)靜盡量減少。

3. 逆優(yōu)化

可見，JVM是個(gè)運(yùn)行服務(wù)端應(yīng)用的好VM，但體量有點(diǎn)大。如果你只是想頻繁地運(yùn)行一段Java寫的腳本，或者在跑一些輔助性的程序比如監(jiān)控和日志收集，往常推薦的JVM參數(shù)也就不再合適里，需要進(jìn)行逆優(yōu)化才能做個(gè)安靜的好鄰居：

• 啟動(dòng)快速，動(dòng)靜小。
• 低成本，節(jié)約CPU、內(nèi)存和線程。
• 低擾動(dòng)，不干擾主應(yīng)用的運(yùn)行。

4. 從失敗的取經(jīng)開始

***時(shí)間，覺(jué)得和JDK自帶的jmap，jstack們用一樣的參數(shù)就好了，多簡(jiǎn)單。

在它們運(yùn)行時(shí)，跑jps -v ，結(jié)果發(fā)現(xiàn)通通只有一個(gè)-Xms8m 。

還不死心，又去翻源碼，JDK7在 Makefile.launcher，JDK8在CompileLaunchers.gmk，結(jié)果發(fā)現(xiàn)全部8M，通通8M，再?zèng)]別的參數(shù)了。

有同學(xué)又從久遠(yuǎn)的記憶中想起一個(gè)-client，感覺(jué)也是比較弱氣的選項(xiàng)，但在這個(gè)多核的64位Linux服務(wù)器上是根本無(wú)效的，一定是-server，必須是-server。

5. 逆優(yōu)化的思路

JVM與上述訴求相沖的幾個(gè)地方：

• 各種吃內(nèi)存
• 各種后臺(tái)線程
• JIT時(shí)CPU表現(xiàn)狂野
• GC時(shí)CPU表現(xiàn)狂野
• 那我們就從這幾個(gè)方面著手。

在開始折騰前，先準(zhǔn)備好測(cè)試手段：

首先，給工具腳本配上GC 日志參數(shù)，在GC日志里就能看到實(shí)際啟動(dòng)參數(shù)，GC紀(jì)錄，以及運(yùn)行結(jié)束時(shí)內(nèi)存各代的占用。

-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime

其次，長(zhǎng)期跑一個(gè) pidstat -l 1| grep xxx ，緊密監(jiān)控進(jìn)程的CPU消耗。

***，jstack看線程。

6. 類的加載和編譯優(yōu)化

6.1 -Xverify:none

來(lái)自優(yōu)化Eclipse啟動(dòng)速度的經(jīng)驗(yàn)，說(shuō)關(guān)閉Java類加載驗(yàn)證可以加快10% -15%的啟動(dòng)速度，嗯，好，加。

6.2 設(shè)定編譯級(jí)別

JIT編譯之后的代碼比解釋執(zhí)行字節(jié)碼更快，更省CPU。比如vjtools里的vjtop，沒(méi)編譯時(shí)每回運(yùn)行要50%單核CPU，75ms執(zhí)行完一個(gè)探測(cè)循環(huán)，而編譯后10%單核，15ms就能完工。

但編譯本身就需要CPU，也需要額外的編譯線程。

如果腳本只簡(jiǎn)單的跑一次，比如vjtools里的vjmxcli，建議就不要進(jìn)行JIT編譯了，編譯完了也用不上，直接解釋執(zhí)行就好。禁止它：-Djava.compiler=NONE

如果腳本用于密集計(jì)算，比如vjtools里的vjmap，則建議打開多層編譯，一開始就對(duì)運(yùn)行到的方法進(jìn)行靜態(tài)編譯，不用等方法被調(diào)用1萬(wàn)次。多層編譯在JDK8默認(rèn)打開，顯式打開：-XX:+TieredCompilation。

但打開多層編譯也會(huì)導(dǎo)致程序運(yùn)行初期有較多的編譯任務(wù)，吃比較多的CPU，可以顯式關(guān)掉多層編譯 -XX:-TieredCompilation來(lái)對(duì)比一下，綜合其帶來(lái)的性能提升，腳本的運(yùn)行時(shí)間的長(zhǎng)短，以及額外的CPU支出來(lái)綜合評(píng)價(jià)。

6.3 編譯線程的設(shè)定

在24核服務(wù)器上，默認(rèn)有4條C1編譯線程，8條C2編譯線程(多層編譯下)，可以把它設(shè)到最小的-XX:CICompilerCount=2。

6.4 未來(lái)黑科技-AOT

JIT真的不適合腳本，還是預(yù)先把代碼編譯(Ahead-of-Time，AOT) 更好。 JDK9里有一個(gè)Hotspot編譯器組搞的試驗(yàn)性的jaotc，另一個(gè)選擇是GraalVM全家桶里帶的SubstrateVM，支持JDK8。

看各位大大炫，但我還沒(méi)玩過(guò)。

7. GC 優(yōu)化

腳本們一般不介意GC延時(shí)，建議使用吞度量最的串行收集算法 -XX:+UseSerialGC，避免了其他GC算法所需的大量GC線程，更絕對(duì)保證了自己GC時(shí)不會(huì)影響到主應(yīng)用。

如果依然想使用并行算法，就一定要設(shè)置GC線程數(shù)，在24核機(jī)器上YGC和CMS GC的線程數(shù)默認(rèn)分別是18和5，為了避免成為惡鄰A君?？稍O(shè)為：

-XX:ParallelGCThreads=4 -XX:ConcGCThreads=2

8. 內(nèi)存優(yōu)化

• 首先，JVM的堆內(nèi)存
• 默認(rèn)的JVM初始內(nèi)存大小，在大內(nèi)存的服務(wù)器上會(huì)比較大，必須設(shè)置。
• -Xms 與 -Xmx 不等時(shí)， 自動(dòng)擴(kuò)張并沒(méi)有想象中那么智能和合理。
• 新生代默認(rèn)只有1/3堆大小，而在腳本看來(lái)新生代才是大頭。

建議根據(jù)GC日志的結(jié)果，完整設(shè)置-Xms 和 -Xmx，并用-Xmn(新生代占大頭) 或-XX:NewRatio=1(一半半) 來(lái)設(shè)置新生代大小。

其次，每條線程的內(nèi)存，從默認(rèn)1M回到256k: -xss256k

其他***代，CodeCache的初始值還算合理，沒(méi)看到特別浪費(fèi)的情況不用管。