10w 級(jí)的并發(fā)場(chǎng)景，JVM 有哪些方面值得優(yōu)化呢？
背景
以秒殺為例，大型電商系統(tǒng)會(huì)拆分多個(gè)微服務(wù)，比如訂單服務(wù)，商品服務(wù)，優(yōu)惠服務(wù)，庫(kù)存服務(wù)，支付服務(wù)等等。
我們以下單為例，如下是簡(jiǎn)約版下單流程
一般我們需要結(jié)合業(yè)務(wù)和已有的資源，再去評(píng)估 JVM 的 GC 頻率來(lái)作為參考：
- 首先結(jié)合業(yè)務(wù)流程分析，計(jì)算我們服務(wù)系統(tǒng)每秒產(chǎn)生的對(duì)象占用內(nèi)存大小。
- 假設(shè)我們采用服務(wù)器規(guī)模 8C*16G，估算下新生代的空間，大概多久觸發(fā) MinorGC。
- 為了避免頻繁的 Full GC，我們可以重新估算具體需要的機(jī)器配置和數(shù)量，給 JVM 設(shè)置多大內(nèi)存。
我們先來(lái)分析下在 10W TPS 下單場(chǎng)景中，我們每秒產(chǎn)生的對(duì)象占用內(nèi)存大小。
如何選擇垃圾回收器？
在選擇垃圾回收器的時(shí)候，我們需要考慮兩個(gè)指標(biāo)：
- 吞吐量：CPU 在用戶(hù)應(yīng)用程序運(yùn)行的時(shí)間/（CPU 在用戶(hù)應(yīng)用程序運(yùn)行的時(shí)間+CPU 垃圾回收器運(yùn)行的時(shí)間）。
- 響應(yīng)時(shí)間：平均每次 GC 的耗時(shí)。
目前主流的垃圾回收器配置是新生代采用 ParNew，老年代采用 CMS 組合的方式，雖然在 JDK8 以后更加推薦使用 G1。一般來(lái)說(shuō)，對(duì)于延遲敏感的推薦 CMS；在大內(nèi)存、要求高吞吐推薦 G1。
在電商下單場(chǎng)景中，用戶(hù)對(duì)于些許的延遲可能會(huì)比較敏感，所以以下還是以 CMS 使用為例。
然后，我要如何設(shè)置 JVM 參數(shù)呢？
堆內(nèi)存大小設(shè)置
對(duì)于 8G 內(nèi)存，我們一般設(shè)置內(nèi)存一半給 JVM，正常的 JVM 參數(shù)設(shè)置如下
-Xms8192M -Xmx8192M Xmn2048M -Xss1M -XX:MMetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8
這樣設(shè)置，而在下單場(chǎng)景，大多對(duì)象都是短期存活的，這樣設(shè)置因?yàn)閯?dòng)態(tài)對(duì)象年齡判斷原則導(dǎo)致頻繁出發(fā) Full GC。
所以可以調(diào)整新生代內(nèi)存大小
-Xms8192M -Xmx8192M -Xmn4086M -Xss1M -XX:MMetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8
這樣就降低了對(duì)象頻繁進(jìn)入老年代的問(wèn)題，實(shí)際上很多優(yōu)化都是圍繞著如何減少 Full GC 去做的，就是盡可能把短期存活的對(duì)象留在 survivor 里，不要進(jìn)入老年代，這樣就可以在 Minor GC 的時(shí)候回收掉這些對(duì)象，不會(huì)產(chǎn)生 Full GC，從而引發(fā) STW，影響系統(tǒng)性能。
除了新生代大小外，還有什么可以?xún)?yōu)化呢？
常見(jiàn) JVM 參數(shù)優(yōu)化
- 新生代動(dòng)態(tài)對(duì)象年齡：默認(rèn)設(shè)置為 15。本例子中每次 Minor GC 間隔 20s 左右，而在下單場(chǎng)景中，一般對(duì)象幾秒內(nèi)就會(huì)變成垃圾對(duì)象了，像這么長(zhǎng)時(shí)間都還沒(méi)被回收的話(huà)，其實(shí)可以早點(diǎn)放到老年代，這樣也不會(huì)占用新生代的內(nèi)存了，比如通過(guò)設(shè)置參數(shù)-XX:MaxTenuringThreshold=5，那么經(jīng)歷過(guò) 5 次 Minor GC 后就會(huì)進(jìn)入老年代。
- 針對(duì)大對(duì)象，有時(shí)我們會(huì)在本地緩存一些不常變化的配置，可結(jié)合實(shí)際業(yè)務(wù)評(píng)估這些對(duì)象大小比如會(huì)超過(guò) 2M，而且會(huì)一直存活保留，那么針對(duì)這些對(duì)象其實(shí)可以直接進(jìn)入老年代，可以通過(guò)設(shè)置參數(shù)-XX:PretenureSizeThreshold=2M。
- 針對(duì) CMS 的碎片整理，因?yàn)?CMS 基于標(biāo)記-清除算法實(shí)現(xiàn)，會(huì)產(chǎn)生內(nèi)存碎片，如果這些內(nèi)存碎片長(zhǎng)時(shí)間不清理的話(huà)，那么老年代的內(nèi)存可用空間會(huì)降低，所以 CMS 也提供了兩個(gè)參數(shù)用于內(nèi)存碎片的整理：
- -XX:+UseCMSCompactAtFullCollection，開(kāi)啟內(nèi)存碎片整理。
- -XX:CMSFullGCsBeforeCompaction，執(zhí)行指定次數(shù)的 Full GC 后，進(jìn)行一次內(nèi)存整理壓縮整理的 Full GC。
- 元空間大小，Meta 區(qū)域的大小一定要指定，如果我們代碼類(lèi)或引入動(dòng)態(tài)生成類(lèi)的技術(shù)超過(guò)元空間大小，那么會(huì)觸發(fā) Full GC，可以通過(guò) jstat 命令查看項(xiàng)目生成類(lèi)的大小來(lái)評(píng)估具體設(shè)置值，一般設(shè)置 256M 夠了。
- JIT 即時(shí)編譯，-XX:ReservedCodeCacheSize。JIT 是 JVM 一個(gè)非常重要的特性，CodeCahce 存放的就是即時(shí)編譯器所生成的二進(jìn)制代碼。
- JVM 逃逸分析，逃逸分析也是一種優(yōu)化手段，JVM 如果分析確定一個(gè)對(duì)象不會(huì)逃逸于方法之外，那么這個(gè)對(duì)象會(huì)被分配在棧上，而不是在堆上，這樣一定程度上就可以減輕 GC 壓力。
