是極致魅惑、灑脫自由的Java heap space？是知性柔情、溫婉大氣的GC overhead limit exceeded？是純真無邪、活潑可愛的Metaspace？如果以上不是你的菜，那還有……刁蠻任性，無跡可尋的CodeCache！性感火辣、心思細膩的Direct Memory高貴冷艷，獨... ...
-
是極致魅惑、灑脫自由的
Java heap space？ -
是知性柔情、溫婉大氣的
GC overhead limit exceeded？ -
是純真無邪、活潑可愛的
Metaspace？ -
如果以上不是你的菜，那還有……
-
***蠻任性，無跡可尋的
CodeCache！ -
性感火辣、心思細膩的
Direct Memory -
高貴冷艷，獨愛你一人的
OOM Killer！ -
總有一款，能讓你鐘情！BUG 選擇權，現在交由你手！
Java heap space
這是最常見的一個 OOM 問題了，誰還沒經歷過一個 Heap OOM呢？
當堆記憶體被塞滿之後，一邊 GC 無法及時回收，一邊又在繼續創建新對象，Allocator 無法分配新的記憶體之後，就會送一個 OOM 的錯誤：
java.lang.OutOfMemoryError: Java heap space
分析解決起來無非是那幾步：
-
dump 堆記憶體
-
通過 MAT、YourKit、JProfiler 、IDEA Profiler 等一系列工具分析dump文件
-
找到占用記憶體最多、最大的對象，看看是哪個小可愛乾的
-
分析代碼，嘗試優化代碼、減少對象創建
-
增加 JVM 堆記憶體、限制請求數、線程數、增加節點數量等
常見類庫使用誤區
尤其是一些工具庫，儘可能的避免每次新建對象，從而節省記憶體提升性能。
大多數主流的類庫，入口類都保證了單例線程安全，全局維護一份即可
舉一些常見的錯誤使用例子：
Apache HttpClient
CloseableHttpClient ，這玩意相當於一個“瀏覽器進程”了，背後有連接池連接復用，一堆機制的輔助類，如果每次都 new 一個，不僅速度慢，而且浪費了大量資源。
比較正常的做法是，全局維護一個（或者根據業務場景分組，每組一個）實例，服務啟動時創建，服務關閉時銷毀：
CloseableHttpClient httpClient = HttpClients.custom()
.setMaxConnPerRoute(maxConnPerRoute)
.setMaxConnTotal(maxConnTotal)
/// ...
.build();
Gson
畢竟是 Google 的項目，入口類自然也是實現了線程安全，全局維護一份 Gson 實例即可
Jackson
Jackson 作為 Spring MVC 預設的 JSON 處理庫，功能強大、用戶眾多，xml/json/yaml/properties/csv 各種主流格式都支持，單例線程安全自然也是 ok 的，全局維護一份 ObjectMapper 即可。
GC overhead limit exceeded
這個錯誤比較有意思，上面的 Java heap space 是記憶體徹底滿了之後，還在持續的創建新對象，此時服務會徹底假死，無法處理新的請求。
而這個錯誤，只是表示 GC 開銷過大，Collector 花了大量的時間回收記憶體，但釋放的堆記憶體卻很小，並不代表服務死了
此時程式處於一種很微妙的狀態：堆記憶體滿了（或者達到回收閾值），不停的觸發 GC 回收，但大多數對象都是可達的無法回收，同時 Mutator 還在低頻率的創建新對象。
出現這個錯誤，一般都是流量較低的場景，有太多常駐的可達對象無法回收，但是吧，GC 後空閑的記憶體還可以滿足服務的基本使用
不過此時，已經在頻繁的老年代GC了，老年代又大對象又多、在現有的回收演算法下，GC 效率非常低並切資源占用巨大，甚至會出現把 CPU 打滿的情況。
出現這個錯誤的時候，從監控角度看起來可能是這個樣子：
-
請求量可能並不大
-
不停 GC，並切暫停時間很長
-
時不時的還有新的請求，但響應時間很高
-
CPU 利用率很高
畢竟還是堆記憶體的問題，排查思路和上面的Java heap space沒什麼區別。
Metaspace/PermGen
Metaspace 區域里，最主要的就是 Class 的元數據了，ClassLoader 加在的數據，都會存儲在這裡。
MetaSpace 初始值很小，預設是沒有上限的。當利用率超過40%（預設值 MinMetaspaceFreeRatio）會進行擴容，每次擴容一點點，擴容也不會直接 FullGC。
比較推薦的做法，是不給初始值，但限制最大值：
-XX:MaxMetaspaceSize=
不過還是得小心，這玩意滿了後果很嚴重，輕則 Full GC，重則 OOM：
java.lang.OutOfMemoryError: Metaspace
排查 MetaSpace 的問題，主要思路還是追蹤 Class Load數據，比較主流的做法是：
-
通過 Arthas 之類的工具，查看 ClassLoader、loadClassess 的數據，分析數量較多的 ClassLoader 或者 Class
-
列印每個 class 的載入日誌：
-XX:+TraceClassLoading -XX:+TraceClassUnloading
下麵介紹幾個常見的，可能導致 MetaSpace 增長的場景：
反射使用不當
JAVA 里的反射，性能是非常低的，以反射的對象必須得緩存起來。尤其是這個Method對象，如果在併發的場景下，每次都獲取新的 Method，然後 invoke 的話，用不了多久 MetaSpace 就給你打爆！
簡單的說，併發場景下，Method.invoke 會重覆的動態創建 class，從而導致 MetaSpace 區域增長，具體分析可以參考笨神的文章《從一起GC血案談到反射原理》。
用反射時，儘可能的用成熟的工具類，Spring的、Apache的都可以。它們都內置了reflection相關對象的緩存，功能又全性能又好，足以解決日常的使用需求。
一些 Agent 的 bug
一些 Java Agent，靜態的和運行時註入的都算。基於 Instrumentation 這套 API 做了各種增強，一會 load 一會 redefine 一會remove的，如果不小心出現 BUG，也很容易生成大量動態的 class，從而導致 metaspace 打滿。
動態代理問題
像 Spring 的 AOP ，也是基於動態代理實現的，不管是 CgLib 還是 JDK Proxy，不管是 ASM 還是 ByteBuddy。最終的結果都逃不開動態創建、載入 Class，有這兩個操作，那 Metaspace 必定受影響。
Spring 的 Bean 預設是singleton的，如果配置為prototype，那麼每次 getBean 就會創建新的代理對象，重新生成動態的 class、重新 define，MetaSpace 自然越來越大。
Code Cache
Code Cache 區域，存儲的是 JIT 編譯後的熱點代碼緩存（註意，編譯過程中使用的記憶體不屬於 Code cache），也屬於 non heap 。
如果 Code cache 滿了，你可能會看到這麼一條日誌：
Server VM warning: CodeCache is full. Compiler has been disabled.
此時 JVM 會禁用 JIT 編譯，你的服務也會開始變慢。
Code Cache 的上限預設比較低，一般是240MB/128MB，不同平臺可能有所區別。
可以通過參數來調整 Code Cache 的上限：
-XX:ReservedCodeCacheSize=
只要儘量避免過大的Class、Method ，一般也不太會出現這個區域被打滿的問題，預設的 240MB/128MB 也足夠了
Direct Memory
Direct Memory 區域，一般稱之為直接記憶體，很多涉及到 磁碟I/O ，Socket I/O 的場景，為了“Zero Copy”提升性能都會使用 Direct Memory。
就比如 Netty ，它真的是把 Direct Memory 玩出了花（有空寫一篇 Netty 記憶體管理分析）……
使用 Direct Memory時，相當於直接繞過 JVM 記憶體管理，調用 malloc() 函數，體驗手動管理記憶體的樂趣～
不過吧，這玩意使用比較危險，一般都配合 Unsafe 操作，一個不小心地址讀寫的地址錯誤，就能得到一個 JVM 給你的驚喜：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffdbd5d19b4, pid=1208, tid=0x0000000000002ee0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_301-b09) (build 1.8.0_301-b09)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.301-b09 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C [msvcr100.dll+0x119b4]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
更多的解釋，可以參考我這篇《Java中的Heap Buffer與Direct Buffer》
這個 Direct Memory 區域，預設是無上限的，但為了防止被 OS Kill，還是會限制一下，給個256MB或者更小的值，防止記憶體無限增長：
-XX:MaxDirectMemorySize=
如果 Direct Memory 達到 MaxDirectMemorySize 並且無法釋放時，就會得到一個 OOM錯誤：
java.lang.OutOfMemoryError: Direct buffer memory
Linux OOM Killer
跳出 JVM 記憶體管理之後，當 OS 記憶體耗盡時，Linux 會選擇記憶體占用最多，優先順序最低或者最不重要的進程殺死。
一般在容器里，主要的進程就是肯定是我們的 JVM ，一旦記憶體滿，第一個殺的就是它，而且還是 kill -TERM (-9)信號，打你一個猝不及防。
如果 JVM 記憶體參數配置合理，遠低於容器記憶體限制，還是出現了 OOM Killer 的話，那麼恭喜你，大概率是有什麼 Native 記憶體泄漏。
這部分記憶體，JVM 它還管不了。
除了 JVM 內部的 Native 泄漏 BUG 這種小概率事件外，大概率是你引用的第三方庫導致的。
這類問題排查起來非常麻煩，畢竟在 JVM 之外，只能靠一些原生的工具去分析。
而且吧，這種動不動就要 root 許可權的工具，可是得領導審批申請許可權的……排查成本真的很高
排查 Native 記憶體的基本的思路是：
-
pmap 查看記憶體地址映射，定位可疑記憶體塊、分析記憶體塊數據
-
strace 手動追蹤進程系統調用，分析記憶體分配的系統調用鏈路
-
更換jemalloc/tcmalloc之類的記憶體分配器（或者 async-profiler有個支持native 分析的分支）追蹤malloc的調用鏈路
目前最常見的 Native 記憶體泄漏場景，是 JDK 的 Inflater/Deflater 這倆卧龍鳳雛，功能是提供 GZIP 的壓縮、解壓，在預設 glibc 的 malloc 實現下，很容易出現“記憶體泄漏”。如果出現 Native 記憶體泄漏，可以先看看應用里有沒有 GZIP 相關操作，說不定有驚喜。
好了，各類風格的 OOM 都感受完了，到底哪一個更能打動你呢？
作者：京東保險 蔣信
來源：京東雲開發者社區 轉載請註明來源
