單核CPU, 1G內(nèi)存，也能做JVM調(diào)優(yōu)嗎？

最近，筆者的技術(shù)群里有人問了一個(gè)有趣的技術(shù)話題：?jiǎn)魏薈PU, 1G內(nèi)存的超低配機(jī)器，怎么做JVM調(diào)優(yōu)？

這實(shí)際上是兩個(gè)問題。單核CPU的超低配機(jī)器，怎么充分利用CPU？單核CPU, 1G內(nèi)存的超低配機(jī)器，怎么做JVM調(diào)優(yōu)？

怎么充分利用CPU？

這個(gè)問題不能一概而論，要結(jié)合具體場(chǎng)景。對(duì)于IO密集型和CPU密集型的應(yīng)用調(diào)優(yōu)的方法會(huì)截然不同。

IO密集型：有頻繁外部設(shè)備訪問的應(yīng)用，如磁盤訪問和網(wǎng)絡(luò)訪問等。由于CPU性能相對(duì)硬盤讀寫和網(wǎng)絡(luò)訪問要好很多，系統(tǒng)執(zhí)行任務(wù)時(shí)，大部分的情況是CPU在等I/O (磁盤/網(wǎng)絡(luò)) 的讀/寫操作，在發(fā)生I/O操作時(shí)cpu處于等待狀態(tài)，這就可能導(dǎo)致cpu的利用率不高。

CPU密集型:  以計(jì)算為主，很少有磁盤和網(wǎng)絡(luò)訪問的應(yīng)用。這種任務(wù)CPU一直在運(yùn)行，CPU的利用率很高。

在給出CPU調(diào)優(yōu)結(jié)論之前，先花兩分鐘熟悉一下I/O基礎(chǔ)。

所謂的I/O（Input/Output）操作實(shí)際上就是輸入輸出的數(shù)據(jù)傳輸行為。程序員最關(guān)注的主要是磁盤IO和網(wǎng)絡(luò)IO，因?yàn)檫@兩個(gè)IO操作和應(yīng)用程序的關(guān)系最直接最緊密。

磁盤IO：磁盤的輸入輸出，比如磁盤和內(nèi)存之間的數(shù)據(jù)傳輸。

網(wǎng)絡(luò)IO：不同系統(tǒng)間跨網(wǎng)絡(luò)的數(shù)據(jù)傳輸，比如兩個(gè)系統(tǒng)間的遠(yuǎn)程接口調(diào)用。

下面這張圖展示了應(yīng)用程序中發(fā)生IO的具體場(chǎng)景：

通過上圖，我們可以了解到IO操作發(fā)生的具體場(chǎng)景。一個(gè)請(qǐng)求過程可能會(huì)發(fā)生很多次的IO操作：

1，頁面請(qǐng)求到服務(wù)器會(huì)發(fā)生網(wǎng)絡(luò)IO

2，服務(wù)之間遠(yuǎn)程調(diào)用會(huì)發(fā)生網(wǎng)絡(luò)IO

3，應(yīng)用程序訪問數(shù)據(jù)庫會(huì)發(fā)生網(wǎng)絡(luò)IO

4，數(shù)據(jù)庫查詢或者寫入數(shù)據(jù)會(huì)發(fā)生磁盤IO

下面是執(zhí)行top命令查看CPU狀況的截圖：

從上圖，我們可以看到:

CPU空閑率是0%（上圖中紅框id）

CPU使用率是22%（上圖中紅框 us 13% 加上 sy 9%，us可以理解成用戶進(jìn)程占用的CPU，sy可以理解成系統(tǒng)進(jìn)程占用的CPU）

CPU 在等待磁盤IO操作上花費(fèi)的時(shí)間占比是76.6% （上圖中紅框 wa）

不少人會(huì)這樣理解，如果CPU空閑率是0%，就代表CPU已經(jīng)在滿負(fù)荷工作，沒精力再處理其他任務(wù)了。真是這樣的嗎？

我們先看一下計(jì)算機(jī)是怎么管理磁盤IO操作的。計(jì)算機(jī)發(fā)展早期，磁盤和內(nèi)存的數(shù)據(jù)傳輸是由CPU控制的，也就是說從磁盤讀取數(shù)據(jù)到內(nèi)存中，是需要CPU存儲(chǔ)和轉(zhuǎn)發(fā)的，期間CPU一直會(huì)被占用。我們知道磁盤的讀寫速度遠(yuǎn)遠(yuǎn)比不上CPU的運(yùn)轉(zhuǎn)速度。這樣在傳輸數(shù)據(jù)時(shí)就會(huì)占用大量CPU資源，造成CPU資源嚴(yán)重浪費(fèi)。

后來有人設(shè)計(jì)了一個(gè)IO控制器，專門控制磁盤IO。當(dāng)發(fā)生磁盤和內(nèi)存間的數(shù)據(jù)傳輸前，CPU會(huì)給IO控制器發(fā)送指令，讓IO控制器負(fù)責(zé)數(shù)據(jù)傳輸操作，數(shù)據(jù)傳輸完IO控制器再通知CPU。因此，從磁盤讀取數(shù)據(jù)到內(nèi)存的過程就不再需要CPU參與了，CPU可以空出來處理其他事情，大大提高了CPU利用率。這個(gè)IO控制器就是“DMA”，即直接內(nèi)存訪問，Direct Memory Access?，F(xiàn)在的計(jì)算機(jī)基本都采用這種DMA模式進(jìn)行數(shù)據(jù)傳輸。

通過上面內(nèi)容我們了解到，IO數(shù)據(jù)傳輸時(shí)，是不占用CPU的。當(dāng)應(yīng)用進(jìn)程或線程發(fā)生IO等待時(shí)，CPU會(huì)及時(shí)釋放相應(yīng)的時(shí)間片資源并把時(shí)間片分配給其他進(jìn)程或線程使用，從而使CPU資源得到充分利用。所以，假如CPU大部分消耗在IO等待（wa）上時(shí)，即便CPU空閑率（id）是0%，也并不意味著CPU資源完全耗盡了，如果有新的任務(wù)來了，CPU仍然有精力執(zhí)行任務(wù)。如下圖：

在DMA模式下執(zhí)行IO操作是不占用CPU的，所以CPU IO等待（上圖的wa）實(shí)際上屬于CPU空閑率的一部分。所以我們執(zhí)行top命令時(shí)，除了要關(guān)注CPU空閑率，CPU使用率（us，sy），還要關(guān)注IO Wait（wa）。注意，wa只代表磁盤IO Wait，不包括網(wǎng)絡(luò)IO Wait。

了解完IO的基礎(chǔ)知識(shí)，我們看看在單核CPU的超低配機(jī)器上，怎么充分利用CPU？

對(duì)于IO密集型應(yīng)用。CPU會(huì)有很多時(shí)間花在IO等待上，發(fā)生IO時(shí)雖然CPU空閑率（上圖的id）受到影響，但是實(shí)際上cpu并沒有干活。這時(shí)就需要較多的線程數(shù)量，當(dāng)一部分線程因?yàn)镮O問題被阻塞時(shí)，其他空閑線程還能繼續(xù)接收并執(zhí)行其他請(qǐng)求任務(wù)。這樣cpu利用率就會(huì)更高。同時(shí)還要考慮線程間上下文切換帶來的性能開銷，線程數(shù)量不能太高。對(duì)于單核CPU，要根據(jù)IO的密集程度設(shè)置線程數(shù)。由于CPU只有一核，資源有限，所以除了對(duì)線程數(shù)的優(yōu)化外，主要還是要優(yōu)化IO操作，減少IO操作頻率，縮短IO操作時(shí)間。IO操作優(yōu)化之后，線程數(shù)可以設(shè)置成更少，線程切的換頻率和性能開銷也會(huì)隨之降低。

對(duì)于CPU密集型應(yīng)用。線程數(shù)應(yīng)該盡可能少一些，在沒有任何IO操作的情況下，為了減少線程切換帶來的性能開銷，理論上最佳的線程數(shù)量應(yīng)該設(shè)置成CPU的核數(shù)。不過實(shí)際場(chǎng)景中，絕大多數(shù)應(yīng)用或多或少都會(huì)有一定的IO操作（比如記錄Log，訪問數(shù)據(jù)庫或者跨網(wǎng)絡(luò)的遠(yuǎn)程調(diào)用等），這樣線程數(shù)就需要適當(dāng)調(diào)大。至于設(shè)置成多少，就沒有定論了，需要我們多次調(diào)整驗(yàn)證（取性能測(cè)試的最優(yōu)結(jié)果）。對(duì)于單核CPU，為了減少線程切換帶來的性能開銷，一兩個(gè)線程基本就夠了。

怎么做JVM調(diào)優(yōu)？

選擇合適的垃圾收集器

以CMS回收過程為例，在耗時(shí)較長(zhǎng)的并發(fā)標(biāo)記和并發(fā)清除階段，垃圾收集線程和用戶線程是同時(shí)并行工作的，也就是說并發(fā)階段不會(huì)導(dǎo)致用戶線程停頓。不過CMS對(duì)CPU資源非常敏感。 其實(shí)，所有高并發(fā)的應(yīng)用對(duì)CPU資源都很敏感。在CMS并發(fā)階段（并發(fā)標(biāo)記和并發(fā)清除階段），雖然不會(huì)導(dǎo)致用戶線程停頓，但是垃圾收集線程會(huì)占用一部分CPU資源，進(jìn)而導(dǎo)致應(yīng)用程序變慢，吞吐量降低。CMS默認(rèn)啟動(dòng)的垃圾收集線程數(shù)是（CPU核數(shù)+3）/4，當(dāng)CPU核數(shù)在4個(gè)以上時(shí)，并發(fā)回收階段垃圾收集線程不少于25%的CPU資源（CPU核數(shù)）。但是當(dāng)CPU核數(shù)不足4個(gè)時(shí)，比如CPU核數(shù)為2個(gè)，CMS對(duì)用戶程序的影響就可能變得很大，此時(shí)需要分配1個(gè)核的資源去執(zhí)行垃圾收集任務(wù)，如果本來CPU負(fù)載就比較大，還要分出一半的計(jì)算能力去執(zhí)行垃圾收集任務(wù)，就可能導(dǎo)致應(yīng)用程序的執(zhí)行速度大幅下降，甚至忽然降低50%以上，著實(shí)讓人無法接受。

在單核CPU環(huán)境下，并發(fā)標(biāo)記和并發(fā)清除階段是無法真正做到并發(fā)的，當(dāng)垃圾收集線程執(zhí)行標(biāo)記和清除任務(wù)時(shí)，單核CPU唯一的核就無法執(zhí)行用戶線程，這樣就會(huì)造成嚴(yán)重的用戶線程阻塞問題，導(dǎo)致應(yīng)用程序響應(yīng)超慢。

說到這有人可能會(huì)問：換成其他垃圾收集器，在單核CPU環(huán)境下，不一樣會(huì)有這種因?yàn)榫€程阻塞導(dǎo)致的應(yīng)用程序執(zhí)行變慢的問題嗎？

沒錯(cuò)，換成其他垃圾收集器，在單核CPU環(huán)境下，一樣會(huì)有同樣的問題。不過情況應(yīng)該會(huì)比使用CMS或者G1要好！CMS是響應(yīng)速度優(yōu)先的老年代垃圾收集器，是一種以降低GC全局停頓時(shí)間（Stop The World）為目標(biāo)的收集器。為了實(shí)現(xiàn)這一目標(biāo)，CMS把垃圾回收分成了初始標(biāo)記，并發(fā)標(biāo)記，重新標(biāo)記和并發(fā)清除4個(gè)階段。其中初始標(biāo)記和重新標(biāo)記兩個(gè)階段會(huì)停止所有用戶線程（發(fā)生STW），不過耗時(shí)很短。并發(fā)標(biāo)記和并發(fā)清除兩個(gè)階段耗時(shí)最長(zhǎng)，但是這兩個(gè)階段垃圾收集線程可以和用戶線程一起工作，不會(huì)停止用戶線程。CMS的這種設(shè)計(jì)雖然縮短了STW的時(shí)間，但是整個(gè)GC過程（四個(gè)階段加在一起的總時(shí)間）更長(zhǎng)了。如果在單核CPU環(huán)境下，并發(fā)標(biāo)記和并發(fā)清除兩個(gè)階段就無法做到真正的并發(fā)，因?yàn)閱魏说膯栴}，垃圾收集線程和用戶線程不可能同時(shí)占用唯一的CPU資源，所以在垃圾收集線程運(yùn)行時(shí)所有用戶線程都會(huì)被停止，相當(dāng)于發(fā)生了STW。基本上可以這樣理解，在單核CPU環(huán)境下，CMS的四個(gè)階段都會(huì)發(fā)生Stop The World。也就是說，在單核CPU環(huán)境下，CMS的Stop The World時(shí)間比傳統(tǒng)的老年代收集器Serial Old和Parallel Old還要長(zhǎng)。所以在單核CPU環(huán)境下，絕對(duì)不能選擇CMS和G1這種對(duì)CPU特別敏感的收集器。考慮到Parallel Old是一款多線程并發(fā)收集器，主要為了利用多核CPU來提高垃圾回收效率，不適合單核環(huán)境。所以，基本上最古老的Serial Old收集器就成了單核CPU的最佳選擇啦。

另外，1G的內(nèi)存空間太小，也不適合CMS和G1。數(shù)年前，在CMS和G1還沒誕生之前，很多互聯(lián)網(wǎng)系統(tǒng)使用Serial Old和Parallel Old做為老年代收集器，這樣會(huì)帶來一個(gè)嚴(yán)重問題，堆內(nèi)存越大垃圾回收時(shí)STW（Stop The World）時(shí)間就越長(zhǎng)，在互聯(lián)網(wǎng)系統(tǒng)中，堆內(nèi)存往往會(huì)超過4G，每次Full GC時(shí)STW時(shí)間會(huì)很長(zhǎng)，可能會(huì)達(dá)到幾秒鐘甚至更長(zhǎng)，也就是說JVM在這幾秒鐘內(nèi)無法處理任何用戶請(qǐng)求。這在高并發(fā)的互聯(lián)網(wǎng)系統(tǒng)中是無法接受的。后來隨著CMS和G1先后應(yīng)運(yùn)而生，解決了較大堆內(nèi)存GC時(shí)STW時(shí)間過長(zhǎng)的問題。所以說CMS和G1只是為了大內(nèi)存場(chǎng)景設(shè)計(jì)的，不適合小內(nèi)存場(chǎng)景，在小內(nèi)存場(chǎng)景下不能發(fā)揮自己的優(yōu)勢(shì)。如果內(nèi)存只有1G，單核CPU下為了提高吞吐量可以選擇Serial Old。多核CPU下，為了充分發(fā)揮多核作用提高垃圾收集效率，可以選擇多線程并發(fā)收集器Parallel Old。

降低GC頻次

JVM將堆內(nèi)存分為了三部分：新生代（Young Generation），老年代（Old Generation），永久代（Permanent Generation）。其中新生代又分為三部分：伊甸園區(qū)（Eden），和兩個(gè)幸存區(qū)S0和S1。

注：JDK1.8之后，Java官方的HotSpot JVM去掉了永久代，取而代之的是元數(shù)據(jù)區(qū)Metaspace。Metaspace使用的是本地內(nèi)存，而不是堆內(nèi)存，也就是說在默認(rèn)情況下Metaspace的大小只與本地內(nèi)存的大小有關(guān)。因此JDK1.8之后，就見不到j(luò)ava.lang.OutOfMemoryError: PermGen space這種由于永久代空間不足導(dǎo)致的內(nèi)存溢出的問題了。

堆內(nèi)存中對(duì)象的分配和流轉(zhuǎn)過程

新創(chuàng)建的對(duì)象會(huì)先被分配到到Eden區(qū)。JVM剛啟動(dòng)時(shí)，Eden區(qū)對(duì)象數(shù)量較少，兩個(gè)Survivor區(qū)S0、S1幾乎是空的。

隨著時(shí)間的推移，Eden區(qū)的對(duì)象越來越多。當(dāng)Eden區(qū)放不下時(shí)（占用空間達(dá)到容量閾值），新生代就會(huì)發(fā)生垃圾回收，我們稱之為Minor GC或者Young GC。

發(fā)生GC時(shí)，第一步會(huì)通過可達(dá)性分析算法找到可達(dá)對(duì)象。如上圖，藍(lán)色為可達(dá)對(duì)象，其他紫色為不可達(dá)對(duì)象。第二步，被標(biāo)示的可達(dá)對(duì)象會(huì)被轉(zhuǎn)移到S0（此時(shí)S0是From Survivor），此時(shí)存活對(duì)象年齡加1，三個(gè)對(duì)象年齡都變?yōu)?。第三步，清除Eden區(qū)所有對(duì)象。

GC后各區(qū)域?qū)ο笳加们闆r，如上圖所示。

程序繼續(xù)運(yùn)行，Eden區(qū)再次達(dá)到容量閾值時(shí)，會(huì)再次發(fā)生GC。這時(shí)S0（From Survivor）已經(jīng)有了對(duì)象。還是同樣的步驟，通過可達(dá)性分析算法找到可達(dá)對(duì)象，然后再將Eden和S0中的可達(dá)對(duì)象轉(zhuǎn)移到S1（To Survivor），各存活對(duì)象年齡加1。最后將Eden和S0中的所有對(duì)象清除。

通過上面的圖文內(nèi)容，我們了解了堆內(nèi)存中對(duì)象的分配和流轉(zhuǎn)過程。那么可以基于這些知識(shí)來做一些JVM調(diào)優(yōu)的工作。

所謂降低GC頻次，主要指的是降低Major GC（老年代GC）次數(shù)。內(nèi)存只有1G，為了減少M(fèi)ajor GC，最簡(jiǎn)單的做法是適當(dāng)調(diào)大老年代比例，但是老年代空間總有個(gè)上限，需要在老年代和年輕代之間找一個(gè)平衡點(diǎn)。還可以適當(dāng)調(diào)大MaxTenuringThreshold，來提高年輕代幸存區(qū)s0和s1的交換次數(shù)，進(jìn)而減少對(duì)象晉升到老年代的幾率。另外調(diào)大幸存區(qū)比例，也可以減少基于動(dòng)態(tài)對(duì)象年齡判定導(dǎo)致對(duì)象晉升老年代的幾率。不管是哪種優(yōu)化手段，都需要反復(fù)調(diào)整和驗(yàn)證（可以做性能測(cè)試驗(yàn)證調(diào)整結(jié)果）。

再補(bǔ)充一個(gè)基礎(chǔ)知識(shí)點(diǎn)。Full GC，Major GC，Minor GC之間是什么關(guān)系？

當(dāng)前絕大部分垃圾收集器都采用分代回收的策略，年輕代和老年代的GC分別獨(dú)立進(jìn)行。一般情況下，老年代Major GC是由年輕代Minor GC觸發(fā)的，Minor GC會(huì)導(dǎo)致部分存活時(shí)間較長(zhǎng)的對(duì)象晉升到老年代，在晉升過程中如果老年代使用空間達(dá)到閾值就會(huì)發(fā)生Major GC。這種由Minor GC觸發(fā)Major GC引發(fā)整個(gè)堆內(nèi)存GC的情況，我們一般稱之為Full GC。還有一些情況也會(huì)觸發(fā)Major GC，比如大對(duì)象初始化時(shí)會(huì)跨過年輕代直接分配到老年代，這種情況觸發(fā)的Major GC和Minor GC就沒半點(diǎn)關(guān)系了?？梢酝ㄟ^-XX:PretenureSizeThreshold參數(shù)設(shè)置大對(duì)象的大小，如果參數(shù)被設(shè)置成5MB，超過5MB的大對(duì)象會(huì)直接分配到老年代。

縮短GC時(shí)間

縮短GC時(shí)間和降低GC頻次，兩者是魚和熊掌的關(guān)系，不可兼得。如上面所說，在1G內(nèi)存單核CPU的場(chǎng)景下，響應(yīng)時(shí)間優(yōu)先的CMS和G1都不適合。在垃圾收集器沒有太多選擇的情況下，如果想縮短Major GC時(shí)間，基本上只能減小老年代的比例了，老年代空間越小，每次Major GC需要處理的對(duì)象就越少，GC時(shí)間也就越短。老年代空間越小，GC的頻次自然也會(huì)更高，內(nèi)存空間就那么多，所以我們需要反復(fù)試驗(yàn)，在GC頻次和GC時(shí)間上找到最佳平衡點(diǎn)來滿足業(yè)務(wù)系統(tǒng)的要求。

結(jié)語

JVM調(diào)優(yōu)沒有什么可以拿來即用的固定模板或規(guī)范，每個(gè)應(yīng)用都有自己的獨(dú)特場(chǎng)景。不同的應(yīng)用并發(fā)程度不一樣，對(duì)響應(yīng)時(shí)間和吞吐量要求也不一樣，堆內(nèi)存對(duì)象規(guī)模、對(duì)象生命周期、對(duì)象大小等等都不會(huì)完全一樣，這些因素都會(huì)影響到JVM的性能。所以，JVM調(diào)優(yōu)是一個(gè)循序漸進(jìn)的過程，必然需要經(jīng)歷多次迭代，最終才能得到一個(gè)較好的折中方案。