『StabilityGuide』| 10+位阿里技術專家共同發起穩定性知識庫開源項目

咱們穿過山和大海，也見過人山人海。
咱們見過各種故障，也排過千雷萬險。
這一次，不如咱們一塊兒，開啓穩定性的探索之旅。
讓沒法解決的問題少一點點，讓世界的肯定性多一點點。

不管是前端業務的開發者，仍是後端架構的開發者，都會遇到業務穩定性的難題。但穩定性的話題涉及之廣、之深，很難經過一兩篇文章道清原委。所以，咱們集結了多位阿里技術工程師，他們來自性能壓測、故障演練、JVM、應用容器、服務框架、流量調度、監控、診斷等不一樣的技術領域，以更結構化的方式來打造穩定性領域的知識庫，該知識庫的目錄將分爲：

• 事前規範：代碼規約、變動管控、性能壓測、故障演練、風險預案、限流降級、業務隔離；
• 事中「止血」：監控、告警、異常巡檢、流量調度；
• 過後診斷：系統診斷、JVM診斷、組件診斷、在線診斷、鏈路追蹤、Root cause；

但咱們也深知，僅憑阿里自身的業務場景和技術積累，很難知足各行業不一樣業務場景下對穩定性知識和經驗獲取的需求，所以，咱們將以開源的方式進行共建，歡迎您將本身或所在企業在穩定性方面的實踐分享給更多的人，讓沒法解決的問題少一點，讓世界的肯定性多一點：

• 開源項目名稱：StabilityGuide
• 參與方式：

1. 提 issue：將您遇到的穩定性難題詳細的描述出來；
2. 寫文章：申領目錄中的某個主題，分享您或所在企業在穩定性方面的實踐；
3. 其餘：您認爲對『StabilityGuide』的建設有幫助的建議；

• 項目地址，點擊這裏！
• 釘釘交流羣：23179349

歡迎在文末，寫下你的留言，隨機抽3位，送出記念衫套裝（ Polo 衫 & T恤，共計兩件）。

如下是來自『StabilityGuide』的第一篇文章：《系統穩定性——OutOfMemoryError 常見緣由及解決方法》。

當 JVM 內存嚴重不足時，就會拋出 java.lang.OutOfMemoryError 錯誤。本文總結了常見的 OOM 緣由及其解決方法，以下圖所示。若有遺漏或錯誤，歡迎補充指正。

若是對 JVM 內存模型和垃圾回收機制不熟悉，推薦閱讀 《我們從頭至尾說一次 Java 垃圾回收》。

Java heap space

當堆內存（Heap Space）沒有足夠空間存放新建立的對象時，就會拋出 java.lang.OutOfMemoryError: Java heap space 錯誤（根據實際生產經驗，能夠對程序日誌中的 OutOfMemoryError 配置關鍵字告警，一經發現，當即處理）。

緣由分析

Java heap space 錯誤產生的常見緣由能夠分爲如下幾類：

• 請求建立一個超大對象，一般是一個大數組。
• 超出預期的訪問量/數據量，一般是上游系統請求流量飆升，常見於各種促銷/秒殺活動，能夠結合業務流量指標排查是否有尖狀峯值。
• 過分使用終結器（Finalizer），該對象沒有當即被 GC。
• 內存泄漏（Memory Leak），大量對象引用沒有釋放，JVM 沒法對其自動回收，常見於使用了 File 等資源沒有回收。

解決方案

針對大部分狀況，一般只須要經過 -Xmx 參數調高 JVM 堆內存空間便可。若是仍然沒有解決，能夠參考如下狀況作進一步處理：

• 若是是超大對象，能夠檢查其合理性，好比是否一次性查詢了數據庫所有結果，而沒有作結果數限制。
• 若是是業務峯值壓力，能夠考慮添加機器資源，或者作限流降級。
• 若是是內存泄漏，須要找到持有的對象，修改代碼設計，好比關閉沒有釋放的鏈接。

GC overhead limit exceeded

當 Java 進程花費 98% 以上的時間執行 GC，但只恢復了不到 2% 的內存，且該動做連續重複了 5 次，就會拋出 java.lang.OutOfMemoryError:GC overhead limit exceeded 錯誤。簡單地說，就是應用程序已經基本耗盡了全部可用內存， GC 也沒法回收。

此類問題的緣由與解決方案跟 Java heap space 很是相似，能夠參考上文。

Permgen space

該錯誤表示永久代（Permanent Generation）已用滿，一般是由於加載的 class 數目太多或體積太大。

緣由分析

永久代存儲對象主要包括如下幾類：

• 加載/緩存到內存中的 class 定義，包括類的名稱，字段，方法和字節碼；
• 常量池；
• 對象數組/類型數組所關聯的 class；
• JIT 編譯器優化後的 class 信息。

PermGen 的使用量與加載到內存的 class 的數量/大小正相關。

解決方案

根據 Permgen space 報錯的時機，能夠採用不一樣的解決方案，以下所示：

• 程序啓動報錯，修改 -XX:MaxPermSize 啓動參數，調大永久代空間。
• 應用從新部署時報錯，極可能是沒有應用沒有重啓，致使加載了多份 class 信息，只需重啓 JVM 便可解決。
• 運行時報錯，應用程序可能會動態建立大量 class，而這些 class 的生命週期很短暫，可是 JVM 默認不會卸載 class，能夠設置 -XX:+CMSClassUnloadingEnabled 和 -XX:+UseConcMarkSweepGC 這兩個參數容許 JVM 卸載 class。

若是上述方法沒法解決，能夠經過 jmap 命令 dump 內存對象 jmap -dump:format=b,file=dump.hprof ，而後利用 Eclipse MAT 功能逐一分析開銷最大的 classloader 和重複 class。

Metaspace

JDK 1.8 使用 Metaspace 替換了永久代（Permanent Generation），該錯誤表示 Metaspace 已被用滿，一般是由於加載的 class 數目太多或體積太大。

此類問題的緣由與解決方法跟 Permgen space 很是相似，能夠參考上文。須要特別注意的是調整 Metaspace 空間大小的啓動參數爲 -XX:MaxMetaspaceSize。

Unable to create new native thread

每一個 Java 線程都須要佔用必定的內存空間，當 JVM 向底層操做系統請求建立一個新的 native 線程時，若是沒有足夠的資源分配就會報此類錯誤。

緣由分析
JVM 向 OS 請求建立 native 線程失敗，就會拋出 Unable to create new native thread，常見的緣由包括如下幾類：

• 線程數超過操做系統最大線程數 ulimit 限制。
• 線程數超過 kernel.pid_max（只能重啓）。
• native 內存不足。

該問題發生的常見過程主要包括如下幾步：

1. JVM 內部的應用程序請求建立一個新的 Java 線程；
2. JVM native 方法代理了該次請求，並向操做系統請求建立一個 native 線程；
3. 操做系統嘗試建立一個新的 native 線程，併爲其分配內存；
4. 若是操做系統的虛擬內存已耗盡，或是受到 32 位進程的地址空間限制，操做系統就會拒絕本次 native 內存分配；
5. JVM 將拋出 java.lang.OutOfMemoryError: Unable to create new native thread 錯誤。

解決方案

• 升級配置，爲機器提供更多的內存；
• 下降 Java Heap Space 大小；
• 修復應用程序的線程泄漏問題；
• 限制線程池大小；
• 使用 -Xss 參數減小線程棧的大小；
• 調高 OS 層面的線程最大數：執行 ulimia -a 查看最大線程數限制，使用 ulimit -u xxx 調整最大線程數限制。

ulimit -a
.... 省略部份內容 .....
max user processes         (-u) 16384

Out of swap space？

該錯誤表示全部可用的虛擬內存已被耗盡。虛擬內存（Virtual Memory）由物理內存（Physical Memory）和交換空間（Swap Space）兩部分組成。當運行時程序請求的虛擬內存溢出時就會報 Out of swap space? 錯誤。

緣由分析
該錯誤出現的常見緣由包括如下幾類：

• 地址空間不足；
• 物理內存已耗光；
• 應用程序的本地內存泄漏（native leak），例如不斷申請本地內存，卻不釋放。
• 執行 jmap -histo:live 命令，強制執行 Full GC；若是幾回執行後內存明顯降低，則基本確認爲 Direct ByteBuffer 問題。

解決方案
根據錯誤緣由能夠採起以下解決方案：

• 升級地址空間爲 64 bit；
• 使用 Arthas 檢查是否爲 Inflater/Deflater 解壓縮問題，若是是，則顯式調用 end 方法。
• Direct ByteBuffer 問題能夠經過啓動參數 -XX:MaxDirectMemorySize 調低閾值。
• 升級服務器配置/隔離部署，避免爭用。

Kill process or sacrifice child

有一種內核做業（Kernel Job）名爲 Out of Memory Killer，它會在可用內存極低的狀況下「殺死」（kill）某些進程。OOM Killer 會對全部進程進行打分，而後將評分較低的進程「殺死」，具體的評分規則能夠參考 Surviving the Linux OOM Killer，詳情點擊這裏。

不一樣於其餘的 OOM 錯誤，Kill process or sacrifice child 錯誤不是由 JVM 層面觸發的，而是由操做系統層面觸發的。

緣由分析
默認狀況下，Linux 內核容許進程申請的內存總量大於系統可用內存，經過這種「錯峯複用」的方式能夠更有效的利用系統資源。

然而，這種方式也會無可避免地帶來必定的「超賣」風險。例如某些進程持續佔用系統內存，而後致使其餘進程沒有可用內存。此時，系統將自動激活 OOM Killer，尋找評分低的進程，並將其「殺死」，釋放內存資源。

解決方案

• 升級服務器配置/隔離部署，避免爭用。
• OOM Killer 調優，詳情點擊這裏。

Requested array size exceeds VM limit

JVM 限制了數組的最大長度，該錯誤表示程序請求建立的數組超過最大長度限制。
JVM 在爲數組分配內存前，會檢查要分配的數據結構在系統中是否可尋址，一般爲 Integer.MAX_VALUE - 2。

此類問題比較罕見，一般須要檢查代碼，確認業務是否須要建立如此大的數組，是否能夠拆分爲多個塊，分批執行。

Direct buffer memory

Java 容許應用程序經過 Direct ByteBuffer 直接訪問堆外內存，許多高性能程序經過 Direct ByteBuffer 結合內存映射文件（Memory Mapped File）實現高速 IO。

緣由分析
Direct ByteBuffer 的默認大小爲 64 MB，一旦使用超出限制，就會拋出 Direct buffer memory 錯誤。

解決方案

• Java 只能經過 ByteBuffer.allocateDirect 方法使用 Direct ByteBuffer，所以，能夠經過 Arthas 等在線診斷工具攔截該方法進行排查。
• 檢查是否直接或間接使用了 NIO，如 netty，jetty 等。
• 經過啓動參數 -XX:MaxDirectMemorySize 調整 Direct ByteBuffer 的上限值。
• 檢查 JVM 參數是否有 -XX:+DisableExplicitGC 選項，若是有就去掉，由於該參數會使 System.gc() 失效。
• 檢查堆外內存使用代碼，確認是否存在內存泄漏；或者經過反射調用 sun.misc.Cleaner 的 clean() 方法來主動釋放被 Direct ByteBuffer 持有的內存空間。
• 內存容量確實不足，升級配置。

推薦工具&產品

1. Eclipse Memory Analyzer —— JVM 內存分析工具
   詳情點擊這裏！
2. Arthas - Java 在線診斷工具，詳情點擊這裏！
3. 應用實時監控 ARMS，支持 OOM 異常關鍵字告警，瞭解更多，點擊這裏。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。