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ù)庫，緩存，網(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次

1. 惡鄰B君
   又過了若干個(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)用有交互的部分，原來對(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)方法很簡單，我們自己定制了一下JMX Client，將7個(gè)數(shù)據(jù)合并在一個(gè)命令里獲得，另外定制了一下JMX Client的JVM參數(shù)，將它啟動(dòng)的動(dòng)靜盡量減少。

1. 逆優(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)行。

1. 從失敗的取經(jīng)開始
   第一時(shí)間，覺得和JDK自帶的jmap，jstack們用一樣的參數(shù)就好了，多簡單。

在它們運(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，感覺也是比較弱氣的選項(xiàng)，但在這個(gè)多核的64位Linux服務(wù)器上是根本無效的，一定是-server，必須是-server。

1. 逆優(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

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

最后，jstack看線程。

1. 類的加載和編譯優(yōu)化
   6.1 -Xverify:none
   來自優(yōu)化Eclipse啟動(dòng)速度的經(jīng)驗(yàn)，說關(guān)閉Java類加載驗(yàn)證可以加快10% -15%的啟動(dòng)速度，嗯，好，加。

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

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

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

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

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

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

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

看各位大大炫，但我還沒玩過。

1. 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

1. 內(nèi)存優(yōu)化
   首先，JVM的堆內(nèi)存

一，默認(rèn)的JVM初始內(nèi)存大小，在大內(nèi)存的服務(wù)器上會(huì)比較大，必須設(shè)置。

二，-Xms 與 -Xmx 不等時(shí)， 自動(dòng)擴(kuò)張并沒有想象中那么智能和合理。

三、新生代默認(rèn)只有1/3堆大小，而在腳本看來新生代才是大頭。

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

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

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

1. 小結(jié)
   想起寫這個(gè)，主要是看楊曉峰的《Java核心技術(shù)36講》里的某幾篇挑起的興趣。