作者：京東零售 劉樂
吞吐量和停頓時長，這兩個優化目標是有衝突的。那麼有沒有可能提高吞吐量而不影響停頓時長，甚至縮短停頓時長呢？答案是有可能的，提高內存佔用（Memory Footprint）就有可能同時優化這兩個標的，這篇文章就來聊聊內存相關內容。
內存佔用一般指應用運行需要的所有內存，包括堆內內存（On-heap Memory)和堆外內存（Off-heap Memory）
1. 堆內內存
堆內內存是分配給JVM的部分內存，用來存放所有Java Class對象實例和數組，JVM GC操作的就是這部分內容。我們先來回顧一下堆內內存的模型：
圖1. 堆內內存
堆內內存包括年輕代（淺綠色），老年代（淺藍色），在JDK7或者更老的版本，圖中右邊還有個永久代（永久代在邏輯上位於JVM的堆區，但又被稱爲非堆內存，在JDK8中被元空間取代）。JVM有動態調整內存策略，通過-Xms，-Xmx指定堆內內存動態調整的上下限。 在JVM初始化時實際只分配部分內存，可通過-XX:InitialHeapSize指定初始堆內存大小，未被分配的空間爲圖中virtual部分。年輕代和老年代在每次GC的時候都有可能調整大小，以保證存活對象佔用百分比在特定閾值範圍內，直到達到Xms指定的下限或Xms指定的上限。（閾值範圍通過-XX:MinHeapFreeRatio,XX:MaxHeapFreeRatio指定，默認值分別爲40， 70）。
GC調優中還有個的重要參數是老年代和年輕代的比例，通過-XX:NewRatio設定，與此相關的還有-XX:MaxNewSize和-XX:NewSize，分別設定年輕代大小的上下限，-Xmn則直接指定年輕代的大小。
1.1 參數默認值
◦-Xmx: Xmx的默認值比較複雜，官方文檔上有時候寫的是1GB，但實際值跟JRE版本、JVM 模式（client, server）和系統（平臺類型，32位，64位）等都有關。經過查閱源碼和實驗，確定在生產環境下（server模式，64位Centos，JRE 8），Xmx的默認值可以採用以下規則計算：
▪容器內存小於等於2G：默認值爲容器內存的1/2，最小16MB， 最大512MB。
▪容器內存大於2G：默認值爲容器內存的1/4, 最大可到達32G。
◦-Xms: 默認值爲容器內存的1/64, 最小8MB，如果明確指定了Xmx並且小於容器內存1/64, Xms默認值爲Xmx指定的值。
◦-NewRatio: 默認2，即年輕代和年老代的比例爲1:2， 年輕代大小爲堆內內存的1/3。
NOTE：在JRE版本1.8.0_131之前，JVM無法感知Docker的資源限制，Xmx, Xms未明確指定時，會使用宿主機的內存計算默認值。
1.2 最佳實踐
由於每次Eden區滿就會觸發YGC，而每次YGC的時候，晉升到老年代的對象大小超過老年代剩餘空間的時候，就會觸發FGC。所以基本來說，GC頻率和堆內內存大小是成反比的，也就是說堆內內存越大，吞吐量越大。
如果Xmx設置過小，不僅浪費了容器資源，在大流量下會頻繁GC，導致一系列問題，包括吞吐量降低，響應變長，CPU升高，
java.lang.OutOfMemoryError異常等。當然Xmx也不建議設置過大，否則會導致進程hang住或者使用容器Swap。所以合理設置Xmx非常重要，特別是對於1.8.0_131之前的版本，一定要明確指定Xmx。推薦設置爲容器內存的50%，不能超過容器內存的80%。
JVM的動態內存策略不太適合服務使用，因爲每次GC需要計算Heap是否需要伸縮，內存抖動需要向系統申請或釋放內存，特別是在服務重啓的預熱階段，內存抖動會比較頻繁。另外，容器中如果有其他進程還在消費內存，JVM內存抖動時可能申請內存失敗，導致OOM。因此建議服務模式下，將Xms設置Xmx一樣的值。
NewRatio建議在2~3之間，最優選擇取決於對象的生命週期分佈。一般先確定老年代的空間（足夠放下所有live data，並適當增加10%~20%)，其餘是年輕代，年輕代大小一定要小於老年代。
另外，以上建議都是基於一個容器部署一個JVM實例的使用情況。有個別需求，需要在一個容器內啓用多個JVM，或者包含其他語言的，研發需要按業務需求在推薦值範圍內分配JVM的Xmx。
2. 堆外內存
和堆內內存對應的就是堆外內存。堆外內存包括很多部分，比如Code Cache， Memory Pool，Stack Memory，Direct Byte Buffers, Metaspace等等，其中我們需要重點關注的是Direct Byte Buffers和Metaspace。
2.1 Direct Byte Buffers
Direct Byte Buffers是系統原生內存，不位於JVM裏，狹義上的堆外內存就是指的Direct Byte Buffers。爲什麼要使用系統原生內存呢? 爲了更高效的進行Socket I/O或文件讀寫等內核態資源操作，會使用JNI（Java原生接口），此時操作的內存需要是連續和確定的。而Heap中的內存不能保證連續，且GC也可能導致對象隨時移動。因此涉及Output操作時，不直接使用Heap上的數據，需要先從Heap上拷貝到原生內存，Input操作則相反。因此爲了避免多餘的拷貝，提高I/O效率，不少第三方包和框架使用Direct Byte Buffers，比Netty。
Direct Byte Buffers雖然有上述優點，但使用起來也有一定風險。常見的Direct Byte Buffers使用方法是用java.nio.DirectByteBuffer的unsafe.allocateMemory方法來創建，DirectByteBuffer對象只保存了系統分配的原生內存的大小和啓始位置，這些原生內存的釋放需要等到DirectByteBuffer對象被回收。有些特殊的情況下（比如JVM一直沒有FGC，設置-XX:+DisableExplicitGC禁用了System.gc），這部分對象會持續增加，直到堆外內存達到-XX:MaxDirectMemorySize指定的大小或者耗盡所有的系統內存。
MaxDirectMemorySize不明確指定的時候，默認值爲0，在代碼中實際爲Runtime.getRuntime().maxMemory()，略小於-Xmx指定的值（堆內內存的最大值減去一個Survivor區大小）。此默認值有點過大，MaxDirectMemorySize未設置或設置過大，有可能發生堆外內存泄露，導致進程被系統Kill。
由於存在一定風險，建議在啓動參數裏明確指定-XX:MaxDirectMemorySize的值，並滿足下面規則：
◦Xmx * 110% + MaxDirectMemorySize + 系統預留內存 <= 容器內存
◦Xmx * 110% 中額外的10%是留給其他堆外內存的，是個保守估計，個別業務運行時線程較多，需自行判斷，上式中左側還需加上Xss * 線程數
◦系統預留內存512M到1G，視容器規格而定
◦I/O較多的業務適當提高MaxDirectMemorySize比例
2.2 Metaspace
Metaspace（元空間）是JDK8關於方法區新的實現，取代之前的永久代，用來保存類、方法、數據結構等運行時信息和元信息的。很多研發在老版本時可能遇到過
java.lang.OutOfMemoryError: PermGen Space，這說明永久代的空間不夠用了，可以通過-XX:PermSize，-XX:MaxPermSize來指定永久代的初始大小和最大大小。Metaspace取代永久代，位置由JVM內存變成系統原生內存，也取消默認的最大空間限制。與此有關的參數主要有下面兩個：
◦-XX:MaxMetaspaceSize指定元空間的最大空間，默認爲容器剩餘的所有空間
◦-XX:MetaspaceSize指定元空間首次擴充的大小，默認爲20.8M
由於MaxMetaspaceSize未指定時，默認無上限，所以需要特別關注內存泄露的問題，如果程序動態的創建了很多類，或出現過
java.lang.OutOfMemoryError:Metaspace，建議明確指定-XX:MaxMetaspaceSize。另外Metaspace實際分配的大小是隨着需要逐步擴大的，每次擴大需要一次FGC，-XX:MetaspaceSize默認的值比較小，需要頻繁GC擴充到需要的大小。通過下面的日誌可以看到Metaspace引起的FGC：
[Full GC (Metadata GC Threshold) ...]
爲減少預熱影響，可以將-XX:MetaspaceSize，-XX:MaxMetaspaceSize指定成相同的值。另外不少應用由JDK7升級到了JDK8，但是啓動參數中仍有-XX:PermSize，-XX:MaxPermSize，這些參數是不生效的，建議修改成-XX:MetaspaceSize，-XX:MaxMetaspaceSize。
3. 應用健康度檢查規則
泰山應用健康度現在已支持掃描JVM相關風險，在應用TAB的JVM配置檢測項下。主要包括以下檢測：
| 檢測指標 | 風險等級 | 巡檢規則 |
|---|---|---|
| JVM版本 | 中危 | 版本不低於1.8.0_191 |
| JVM GC方法 | 中危 | 所有分組GC方法一致 |
| Xmx | 高危 | 明確指定，並且在容器內存的50%~80%範圍內 |
| Xms | 中危 | 明確指定，並且等於Xmx指定的值 |
| 堆外內存 | 中危 | 明確指定，並且 堆內*1.1+堆外+系統預留<=容器內存 |
| ParallelGCThreads | 高危 | ParallelGCThreads在容器CPU核數的50%~100%範圍內 |
| ConcGCThreads | 低危 | ConcGCThreads在ParallelGCThreads的20%~50%範圍內（限CMS，G1） |
| CICompilerCount | 低危 | 指定CICompilerCount在推薦值50%~150%內（限1.8<JRE<1.8.0_131) |
上一篇文章已經說了ParallelGCThreads，這裏再補充一下新支持的兩個檢測，ConcGCThreads，CICompilerCount。
ConcGCThreads一般稱爲併發標記線程數，爲了減少GC的STW的時間，CMS和G1都有併發標記的過程，此時業務線程仍在工作，只是併發標記是CPU密集型任務，業務的吞吐量會下降，RT會變長。ConcGCThreads的默認值不同GC策略略有不同，CMS下是(ParallelGCThreads + 3) / 4 向下取整，G1下是ParallelGCThreads / 4 四捨五入。一般來說採用默認值就可以了，但是還是由於在JRE版本1.8.0_131之前，JVM無法感知Docker的資源限制的問題，ConcGCThreads的默認值會比較大（20左右），對業務會有影響。
CICompilerCount是JIT進行熱點編譯的線程數，和併發標記線程數一樣，熱點編譯也是CPU密集型任務，默認值爲2。在CICompilerCountPerCPU開啓的時候（JDK7默認關閉，JDK8默認開啓），手動指定CICompilerCount是不會生效的，JVM會使用系統CPU核數進行計算。所以當使用JRE8並且版本小於1.8.0_131，採用默認參數時，CICompilerCount會在20左右，對業務性能影響較大，特別是啓動階段。建議升級Java版本，特殊情況要使用老版本Java 8，請加上-XX:CICompilerCount=[n], 同時不能指定-XX:+CICompilerCountPerCPU，下表給出了生產環境下常見規格的推薦值。
| 容器CPU核數 | 1 | 2 | 4 | 8 | 16 |
|---|---|---|---|---|---|
| CICompilerCount手動指定推薦值 | 2 | 2 | 3 | 3 | 8 |
4. 修改建議
1） 再次建議升級JRE版本到1.8.0_191及以上； 2） 建議在Shell腳本中，Export JAVA_OPTS環境變量, 至少包含以下幾項(方括號中的值根據文中推薦選取)：
-server -Xms[8192m] -Xmx[8192m] -XX:MaxDirectMemorySize=[4096m]
如果特殊原因要使用1.8.0_131以下版本， 則同時需要加上以下參數(方括號中的值根據文中推薦選取)：
-XX:ParallelGCThreads=[8] -XX:ConcGCThreads=[2] -XX:CICompilerCount=[2]
下面的項建議測試後使用，需自行確定具體大小（特別是使用JRE8但仍配置-XX:PermSize，-XX:MaxPermSize的應用）：
-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m
環境變量設置如下例子：
export JAVA_OPTS="-Djava.library.path=/usr/local/lib -server -Xms4096m -Xmx4096m -XX:MaxMetaspaceSize=512m -XX:MetaspaceSize=512m -XX:MaxDirectMemorySize=2048m -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:CICompilerCount=2 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/Logs -XX:+UseG1GC [other_options...] -jar jarfile [args...]"
另外，如果應用未接入UMP或PFinder， JAVA_OPTS中儘量不要用Shell函數或者變量，否則健康度有可能會提示解析失敗。
NOTE: Java options 的使用應該按照下面的順序：
◦執行類： java [-options] class [args...]
◦執行包：java [-options] -jar jarfile [args...] 或 java -jar [-options] jarfile [args...]
即options要放到執行對象之前，部分應用使用了以下順序：
java -jar jarfile [-options] [args...] 或者 java -jar jarfile [args...] [-options]
這些Java options都不會生效。