如果程序是一輛行駛在道路上的車內(nèi)存就是它腳下的路面。路況好時(shí)你感覺不到它的存在一旦前方出現(xiàn)坑洞、裂縫或者突然收窄的車道車的性能再強(qiáng)也會(huì)瞬間失控。過去幾年里越來越多服務(wù)端應(yīng)用和嵌入式系統(tǒng)面臨的恰恰是這種“路況失控”問題Java 進(jìn)程冷不丁拋出OutOfMemoryError: Java heap spaceC 進(jìn)程在 Windows 上以0xc0000005也就是十進(jìn)制的3221225477退出或者 JVM 直接報(bào)出Native memory allocation (malloc) failed to allocate ... bytes。很多開發(fā)者的第一反應(yīng)是“加內(nèi)存”“重啟試試”“讓運(yùn)維擴(kuò)容”。但真正讓人頭疼的并不是單次崩潰而是這些問題的復(fù)現(xiàn)沒有規(guī)律業(yè)務(wù)高峰期出現(xiàn)、低峰期消失換了機(jī)器就復(fù)現(xiàn)不了升級(jí)一個(gè)小版本后突然頻發(fā)。這個(gè)問題的本質(zhì)是我們只看到了“內(nèi)存不夠”的表象卻沒有建立起一套系統(tǒng)化的內(nèi)存掌控能力。這就是我把這篇文章的主題概括為“Driving on Memory”的原因——不是介紹某一個(gè)具體工具的 API而是要幫你在內(nèi)存這條高速公路上把住方向盤。這篇文章會(huì)從底層概念講起但不做枯燥的教科書式鋪陳接著會(huì)帶你識(shí)別三類最常見的崩潰現(xiàn)場(chǎng)再分別給出 JVM 堆內(nèi)與系統(tǒng)級(jí) native 內(nèi)存的排查方法最后會(huì)聊到車載、嵌入式這類“駕駛”場(chǎng)景里更苛刻的內(nèi)存治理要求并給出一份能直接落地到團(tuán)隊(duì)工程實(shí)踐的檢查清單。如果你已經(jīng)不止一次被 OOM、內(nèi)存泄漏或訪問違例折磨過這篇內(nèi)容會(huì)很適合你。1. 為什么內(nèi)存問題像一顆“延遲炸彈”普通 Bug 的特點(diǎn)是“只要觸發(fā)很快就暴露”。比如接口參數(shù)傳錯(cuò)了跑一次測(cè)試就能發(fā)現(xiàn)數(shù)組越界在大多數(shù)語言里也比較容易定位。內(nèi)存問題卻相反它的爆發(fā)點(diǎn)往往離根因點(diǎn)非常遠(yuǎn)這也是它最難排查的原因。舉個(gè)常見的例子某個(gè)服務(wù)在啟動(dòng)階段申請(qǐng)了一塊緩存正常情況下只占 200MB但緩存中的鍵沒有設(shè)計(jì)過期策略數(shù)據(jù)只增不減。第一天運(yùn)行很正常第二天內(nèi)存漲了 5%第三天又漲了 5%。由于總內(nèi)存還夠用GC 也還“撐得住”服務(wù)并不會(huì)立刻出問題。直到一周后的業(yè)務(wù)高峰期Old Gen被打滿GC 線程接近失控接口延遲從 30ms 變成 3 秒緊接著進(jìn)程 OOM 重啟。等你登錄服務(wù)器排查時(shí)進(jìn)程已經(jīng)重啟現(xiàn)場(chǎng)已經(jīng)沒了大半而根因竟然藏在一周前的某段代碼里。這就是內(nèi)存“延遲炸彈”的典型特征故障現(xiàn)象和故障根源在時(shí)間上被拉得很遠(yuǎn)。更麻煩的是內(nèi)存問題往往不會(huì)孤零零地出現(xiàn)。當(dāng)一個(gè) JVM 進(jìn)程把系統(tǒng)內(nèi)存吃光同機(jī)器上的另一個(gè) Java 進(jìn)程也會(huì)跟著遭殃最后看起來像多個(gè)應(yīng)用同時(shí)出故障很容易誤判成“網(wǎng)絡(luò)問題”或“數(shù)據(jù)庫問題”。要拆掉這顆炸彈靠“重啟”是沒有用的。你需要知道三個(gè)層面的信息第一內(nèi)存到底去哪了第二是誰在哪個(gè)階段申請(qǐng)的第三這種申請(qǐng)是否超出了可控范圍。下面我們從底層概念開始把這三件事講清楚。2. 內(nèi)存管理核心概念先搞懂程序向誰要內(nèi)存我們常說“程序占了多少內(nèi)存”但“內(nèi)存”這個(gè)詞在不同語境下含義完全不同。2.1 物理內(nèi)存與虛擬內(nèi)存CPU 真正直接訪問的是物理內(nèi)存條上的地址但現(xiàn)代操作系統(tǒng)并不會(huì)讓應(yīng)用程序直接接觸物理內(nèi)存而是給每個(gè)進(jìn)程提供一份獨(dú)立的虛擬地址空間。進(jìn)程看到的是從0x0開始的連續(xù)地址實(shí)際上這些地址要通過頁表轉(zhuǎn)換成物理地址。頁表由操作系統(tǒng)和硬件 MMUMemory Management Unit共同維護(hù)因此程序分配了一塊內(nèi)存不代表它立刻占用了同等大小的物理內(nèi)存。這個(gè)設(shè)計(jì)帶來的好處是隔離性A 進(jìn)程寫壞了自己的內(nèi)存不會(huì)直接改寫 B 進(jìn)程的數(shù)據(jù)。代價(jià)是一旦程序訪問了“沒有映射到物理內(nèi)存”的虛擬地址硬件就會(huì)觸發(fā)缺頁異?；蚨五e(cuò)誤在 Windows 上這類錯(cuò)誤通常會(huì)以0xc0000005呈現(xiàn)含義是訪問違例Access Violation。2.2 堆、棧、元數(shù)據(jù)區(qū)、native 內(nèi)存程序運(yùn)行時(shí)并不是只在一個(gè)地方申請(qǐng)內(nèi)存。按主流語言和運(yùn)行時(shí)劃分大致可以分為幾類區(qū)域主要用途典型管理方式溢出時(shí)常見表現(xiàn)棧函數(shù)調(diào)用、局部變量、返回地址編譯器自動(dòng)分配和釋放棧溢出 StackOverflow堆動(dòng)態(tài)創(chuàng)建的對(duì)象、集合、緩存運(yùn)行時(shí) GC 或手動(dòng)分配OOM、內(nèi)存泄漏元數(shù)據(jù)區(qū)/方法區(qū)類信息、常量、JIT 編譯產(chǎn)物GC 按需卸載Metaspace OOMnative 內(nèi)存JIT、GC 數(shù)據(jù)結(jié)構(gòu)、線程棧、DirectBuffer、JNI由運(yùn)行時(shí)向操作系統(tǒng)申請(qǐng)malloc 失敗、進(jìn)程崩潰很多 Java 開發(fā)者以為 OOM 就等于堆不夠大這是誤解。JVM 除了堆還會(huì)向操作系統(tǒng)申請(qǐng)大量 native 內(nèi)存。Metaspace、線程棧、JIT 編譯器代碼緩存以及 Java NIO 的 DirectBuffer 都不在堆內(nèi)。當(dāng)你使用-Xmx設(shè)置了 2GB 堆但 1000 個(gè)線程每個(gè)默認(rèn)棧大小 1MB線程棧就要占約 1GB如果再加上堆外緩存進(jìn)程實(shí)際占用的內(nèi)存可能遠(yuǎn)超-Xmx。因此排查進(jìn)程崩潰時(shí)不能只看堆還要看 RSS常駐內(nèi)存集。2.3 垃圾回收不是萬能的CPP 程序員需要手動(dòng)管理內(nèi)存Java、Go 等語言引入了 GC看起來不用管內(nèi)存了但 GC 只能回收“運(yùn)行時(shí)認(rèn)為不再可達(dá)”的對(duì)象。如果業(yè)務(wù)代碼里某個(gè)集合一直被全局引用持有GC 永遠(yuǎn)不會(huì)回收它。表面上是 GC 不給力實(shí)際上是“內(nèi)存泄漏”在源頭不斷積累。理解這一點(diǎn)才能建立一個(gè)重要判斷內(nèi)存問題不是只有“分配太多”這一種成因還可能來自“該回收的沒有回收”和“運(yùn)行時(shí)申請(qǐng)方式不當(dāng)”。排查的時(shí)候先分清是哪一種再動(dòng)手看代碼和工具。3. 識(shí)別崩潰現(xiàn)場(chǎng)從錯(cuò)誤信息反推故障類型內(nèi)存故障的排查最好從第一現(xiàn)場(chǎng)的報(bào)錯(cuò)信息入手。不要一看到OutOfMemoryError就去看堆大小也不要一看到進(jìn)程退出就懷疑是代碼 Bug。不同類型的信息對(duì)應(yīng)完全不同的排查路徑。3.1 JVM 進(jìn)程內(nèi) OOM第一種是 Java 應(yīng)用打印出的異常堆棧例如Exception in thread main java.lang.OutOfMemoryError: Java heap space at com.example.memory.OomDemo.main(OomDemo.java:12)這個(gè)錯(cuò)誤的直接含義是 JVM 堆無法再分配新對(duì)象?？赡艿挠|發(fā)因素包括堆設(shè)置過小、某個(gè)集合異常增長、存在內(nèi)存泄漏。如果要定位重點(diǎn)看的是“發(fā)生分配的位置”和“堆里占著內(nèi)存不放的對(duì)象是誰”而不是去猜-Xmx該設(shè)多大。此外還有Metaspace、GC overhead limit exceeded、Unable to create new native thread等變體。它們雖然都頂著OutOfMemoryError的名字實(shí)際成因并不相同。比如Unable to create new native thread往往是操作系統(tǒng)線程數(shù)限制或進(jìn)程地址空間不足導(dǎo)致的和 Java 堆幾乎沒有關(guān)系。3.2 Windows 上的 0xc0000005 / 3221225477很多開發(fā)者在 Windows 上跑程序時(shí)會(huì)看到類似提示Process finished with exit code 3221225477或者0xC0000005: Access violation reading location 0x00000000000000003221225477換算成十六進(jìn)制就是0xC0000005它對(duì)應(yīng) Windows 的STATUS_ACCESS_VIOLATION。這類錯(cuò)誤通常不是 Java 堆溢出而是進(jìn)程嘗試訪問了沒有權(quán)限的地址。常見場(chǎng)景包括C/C 里對(duì)空指針或野指針解引用、JNI 調(diào)用的本地庫寫壞了內(nèi)存、JVM 自身在 native 層崩潰。遇到0xC0000005時(shí)首先要找崩潰現(xiàn)場(chǎng)日志。如果是 JVM 崩潰進(jìn)程的工作目錄下會(huì)生成hs_err_pidPID.log里面記錄了觸發(fā)崩潰的指令和線程棧。不要拿著這個(gè)退出碼去調(diào)整 JVM 堆大小那很可能跑偏。3.3 JVM 向操作系統(tǒng)申請(qǐng)內(nèi)存失敗第三種崩潰信息在服務(wù)端更常見它的報(bào)錯(cuò)長這樣There is insufficient memory for the Java Runtime Environment to continue. Native memory allocation (malloc) failed to allocate 2046256 bytes for chunk注意這里的 2MB 左右分配聽起來很小卻失敗了。這說明問題大概率不在“某一次分配的量太大”而是操作系統(tǒng)層面已經(jīng)無法滿足內(nèi)存申請(qǐng)?？赡茉虬ㄟM(jìn)程可用的虛擬地址空間耗盡、系統(tǒng)內(nèi)存被其他進(jìn)程占滿、容器 cgroup 內(nèi)存限制被觸發(fā)或者進(jìn)程間接導(dǎo)致的vm.max_map_count超過上限。這時(shí)候如果還在糾結(jié)“為什么 2MB 都分配不出來”方向就錯(cuò)了。正確做法是先看整個(gè)機(jī)器的內(nèi)存水位再看進(jìn)程的 RSS 大小和線程數(shù)然后檢查是否被容器限制。4. 掌握觀測(cè)手段內(nèi)存排查不是靠猜內(nèi)存分析不能靠“我感覺內(nèi)存漲了”。沒有度量就沒有定位。關(guān)鍵要掌握三層觀察系統(tǒng)層、進(jìn)程層、運(yùn)行時(shí)層。4.1 系統(tǒng)層先看整機(jī)內(nèi)存水位在 Linux 上排查時(shí)我習(xí)慣按下面的順序看數(shù)據(jù)# 查看系統(tǒng)總內(nèi)存、已用內(nèi)存、可用內(nèi)存 free -h # 查看內(nèi)存詳細(xì)指標(biāo) cat /proc/meminfo | grep -E MemTotal|MemAvailable|CommitLimit|Committed_AS # 查看某個(gè)進(jìn)程的常駐內(nèi)存、虛擬內(nèi)存 ps -o pid,rss,vsz,%mem,cmd -p PID # 查看進(jìn)程的地址空間與物理內(nèi)存映射 pmap -x PIDfree -h輸出的available列比free列更接近真實(shí)可用內(nèi)存因?yàn)?Linux 的清緩存機(jī)制讓部分緩存內(nèi)存可以被迅速回收。如果available已經(jīng)很低就要進(jìn)一步找誰在占用。/proc/meminfo里的CommitLimit和Committed_AS值得單獨(dú)理解。它們對(duì)應(yīng)系統(tǒng)承諾給進(jìn)程的虛擬內(nèi)存總量。如果Committed_AS長期逼近CommitLimit即使物理內(nèi)存還有富余操作系統(tǒng)也可能拒絕新的內(nèi)存申請(qǐng)。4.2 JVM 進(jìn)程層堆和 native 都要監(jiān)控查看 Java 進(jìn)程的啟動(dòng)參數(shù)時(shí)可以通過jcmd查看 JVM 實(shí)際生效的配置# 查看指定 JVM 進(jìn)程的基本信息 jcmd PID VM.flags # 查看堆當(dāng)前使用量 jcmd PID GC.heap_info # 查看類加載數(shù)量和元數(shù)據(jù)區(qū)使用量 jcmd PID VM.metadata比較推薦的做法是接入帶 GC 日志的啟動(dòng)參數(shù)。GC 日志能明確告訴你堆是否頻繁 Full GC、每次 GC 后存活對(duì)象是否持續(xù)增長。如果存活對(duì)象一直增長內(nèi)存泄漏的概率非常高。4.3 容器環(huán)境小心只看 host 不看 cgroup容器化部署之后最常見的一個(gè)坑是在宿主機(jī)上執(zhí)行free -h發(fā)現(xiàn)內(nèi)存很充足但容器還是 OOM。原因在于容器使用的內(nèi)存上限由 cgroup 控制宿主機(jī)空閑不代表容器還有配額。排查容器內(nèi)存問題需要看容器自身的內(nèi)存統(tǒng)計(jì)# 在容器內(nèi)查看 cgroup 內(nèi)存限制與當(dāng)前用量 cat /sys/fs/cgroup/memory/memory.limit_in_bytes cat /sys/fs/cgroup/memory/memory.usage_in_bytes # 如果 cgroup v2 cat /sys/fs/cgroup/memory.max cat /sys/fs/cgroup/memory.current在 Kubernetes 中如果 Pod 頻繁被殺死kubectl describe pod的事件里會(huì)出現(xiàn)OOMKilled。這種問題先調(diào)整容器內(nèi)存上限再檢查 JVM 是否能感知到容器限制是常見的排查順序。5. 實(shí)戰(zhàn)從零定位一個(gè) JVM 堆內(nèi)存 OOM理論講完我們做一個(gè)能完整跑通的最小實(shí)驗(yàn)。這個(gè)實(shí)驗(yàn)不需要復(fù)雜業(yè)務(wù)只需要一個(gè)會(huì)不停往集合里塞對(duì)象的 Java 類。5.1 模擬程序文件路徑src/main/java/com/example/memory/OomDemo.javapackage com.example.memory; import java.util.ArrayList; import java.util.List; /** * 最小 OOM 復(fù)現(xiàn)程序。 * 每次分配 1MB 數(shù)組并持有引用避免被 GC 回收。 * 請(qǐng)勿在生產(chǎn)環(huán)境直接運(yùn)行。 */ public class OomDemo { public static void main(String[] args) throws Exception { Listbyte[] cache new ArrayList(); int index 0; while (true) { cache.add(new byte[1024 * 1024]); index; if (index % 50 0) { System.out.println(allocated index MB); Thread.sleep(100); } } } }這段代碼的邏輯非常簡單循環(huán)創(chuàng)建 1MB 大小的字節(jié)數(shù)組并添加到Listbyte[]中。只要List不釋放引用數(shù)組就不會(huì)被 GC 回收。5.2 用有限堆啟動(dòng)并自動(dòng)生成 Heap Dump文件路徑run-oom-demo.sh#!/usr/bin/env bash java -Xms256m -Xmx256m \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/tmp/oom-demo.hprof \ -cp target/classes \ com.example.memory.OomDemo這里的兩個(gè)參數(shù)很關(guān)鍵HeapDumpOnOutOfMemoryError表示在 OOM 時(shí)自動(dòng)導(dǎo)出堆快照HeapDumpPath指定導(dǎo)出路徑。生產(chǎn)環(huán)境建議一開始就加上否則進(jìn)程重啟后很難找回現(xiàn)場(chǎng)。5.3 預(yù)期運(yùn)行結(jié)果程序運(yùn)行一小會(huì)兒后會(huì)看到類似這樣的輸出allocated 50 MB allocated 100 MB Exception in thread main java.lang.OutOfMemoryError: Java heap space at com.example.memory.OomDemo.main(OomDemo.java:14) java.lang.OutOfMemoryError: Java heap space Dumping heap to /tmp/oom-demo.hprof ... Heap dump file created [26572256 bytes in 0.051 secs]看到Heap dump file created說明堆快照已經(jīng)生成。接下來就可以用 MATEclipse Memory Analyzer或 VisualVM 打開/tmp/oom-demo.hprof按照“Dominator Tree”排序查看哪些對(duì)象占用了最大比例的內(nèi)存。最終看到的通常會(huì)是那個(gè)byte[]數(shù)組以及持有它的ArrayList。這個(gè)實(shí)驗(yàn)的價(jià)值在于幫你建立兩條排錯(cuò)直覺第一-Xmx設(shè)多大不解決“引用不釋放”的問題第二堆轉(zhuǎn)儲(chǔ)文件的導(dǎo)出是 OOM 排查里最值得優(yōu)先確保的一步。真實(shí)業(yè)務(wù)中代碼會(huì)比這段復(fù)雜得多但分析思路完全一致先找到一個(gè)明確的根對(duì)象再看是一張表、一個(gè)緩存還是一個(gè)全局集合在“抱住”大量內(nèi)存不放。6. native 內(nèi)存分配失敗的另類排查JVM 的 OOM 通常能拿到異常堆棧native 分配失敗卻常常只有一段 “There is insufficient memory” 的啟動(dòng)日志或崩潰日志。場(chǎng)景更接近“系統(tǒng)路況已經(jīng)堵死車還沒上高速就熄火了”。6.1 先把范圍縮小到三個(gè)方向遇到Native memory allocation (malloc) failed時(shí)第一件事不是加內(nèi)存而是快速判斷問題屬于哪一類。第一系統(tǒng)或容器真正沒有可分配內(nèi)存了。你會(huì)看到free -h中available極低或者 cgroup 的memory.max已經(jīng)被打滿進(jìn)程的 RSS 已經(jīng)接近限制值。此時(shí)要找的是進(jìn)程里誰占用了越多的 native 內(nèi)存。第二地址空間或內(nèi)核參數(shù)受限。有些系統(tǒng)默認(rèn)vm.max_map_count只有 65530如果進(jìn)程創(chuàng)建了大量線程、共享內(nèi)存或 JIT 代碼段可能導(dǎo)致映射數(shù)量超出限制后續(xù)小塊內(nèi)存分配都會(huì)失敗?？梢杂孟旅娴拿畈榭春团R時(shí)調(diào)整# 查看當(dāng)前限制 sysctl vm.max_map_count # 臨時(shí)提高限制生產(chǎn)環(huán)境建議寫入 /etc/sysctl.conf 持久化 sysctl -w vm.max_map_count262144第三JVM 自身某些 region 設(shè)置不合理。比如 Metaspace 無上限但類加載異常、DirectBuffer 被不停申請(qǐng)而沒有釋放、線程數(shù)太多導(dǎo)致線程?？臻g暴漲。這些雖然都以 native 內(nèi)存形式存在但根因在運(yùn)行時(shí)配置和代碼。6.2 一個(gè)典型的容器內(nèi)存踩坑場(chǎng)景假設(shè)一個(gè) Java 應(yīng)用啟動(dòng)命令是java -Xmx1024m -jar app.jar容器配置如下resources: requests: memory: 768Mi limits: memory: 768Mi這個(gè)配置繼續(xù)運(yùn)行的結(jié)局大概率是OOMKilled。原因很簡單JVM 以為可以堆外申請(qǐng)超過容器限制的內(nèi)存把-Xmx設(shè)置成 1GB容量上限卻被固定在 768MB。即使堆沒有打滿JIT、Metaspace、線程棧等額外內(nèi)存也可能讓總數(shù)越過 cgroup 限制。更穩(wěn)妥的做法是讓 JVM 感知容器限制并設(shè)置合理的堆外余量。以 JDK 10 以上的版本為例在容器內(nèi)啟用UseContainerSupport默認(rèn)開啟后JVM 會(huì)自動(dòng)讀取 cgroup 限制團(tuán)隊(duì)實(shí)際部署時(shí)仍然要為堆外內(nèi)存預(yù)留約 25% 的余量不要盲目把-Xmx頂?shù)浇咏萜魃舷?。這個(gè)比例并不是固定公式但“堆外一定要留余量”這條原則是確定的。7. “Driving on Memory”的現(xiàn)實(shí)版車載與嵌入式系統(tǒng)中的內(nèi)存挑戰(zhàn)讀完前面的 JVM 與服務(wù)器場(chǎng)景再回到“Driving on Memory”這個(gè)標(biāo)題。車載智能座艙、自動(dòng)駕駛域控制器這類嵌入式系統(tǒng)才是對(duì)內(nèi)存“駕駛”要求最苛刻的地方。這類系統(tǒng)有兩個(gè)突出特點(diǎn)。第一是資源受限內(nèi)存大小是硬件上早就定死的不可能像云端那樣靠“擴(kuò)容”解決第二是運(yùn)行周期極長車輛啟動(dòng)后系統(tǒng)可能連續(xù)運(yùn)行數(shù)天甚至數(shù)月一個(gè)每天泄漏幾 KB 內(nèi)存的模塊經(jīng)過數(shù)月積累也會(huì)拖垮整個(gè)系統(tǒng)。更關(guān)鍵的是嵌入式系統(tǒng)一旦因?yàn)?OOM 重啟影響的可能不只是用戶體驗(yàn)還涉及功能安全。所以在設(shè)計(jì)階段就對(duì)內(nèi)存治理想得非常嚴(yán)格。具體到工程實(shí)踐嵌入式場(chǎng)景里更看重這幾件事靜態(tài)分配優(yōu)先。在系統(tǒng)啟動(dòng)階段就確定主要內(nèi)存池的大小減少運(yùn)行期動(dòng)態(tài)分配避免長期運(yùn)行后產(chǎn)生內(nèi)存碎片。分模塊設(shè)置內(nèi)存預(yù)算。每個(gè)組件能申請(qǐng)多少內(nèi)存一開始就有量化指標(biāo)超預(yù)算報(bào)警而不是等到系統(tǒng)整體 OOM。重視碎片化。動(dòng)態(tài)分配和釋放頻繁后總剩余內(nèi)存可能還有但連續(xù)大塊內(nèi)存不足導(dǎo)致分配失敗。這和服務(wù)器上的 native malloc 失敗現(xiàn)象本質(zhì)一致。日志和狀態(tài)頁要設(shè)計(jì)好。車載設(shè)備無法隨時(shí)讓工程師連接調(diào)試器因此系統(tǒng)需要有內(nèi)存水位監(jiān)控、異?？煺沼涗浐桶踩导?jí)機(jī)制。服務(wù)器場(chǎng)景里經(jīng)常被忽視的“長期運(yùn)行風(fēng)險(xiǎn)”在嵌入式場(chǎng)景里被放到了最高優(yōu)先級(jí)。這也是“Driving on Memory”的核心含義內(nèi)存管理不是上線前的臨時(shí)檢查而是貫穿整個(gè)產(chǎn)品生命周期的駕駛能力。你以為自己只是在寫業(yè)務(wù)代碼實(shí)際上你每創(chuàng)建一條線程、一個(gè)緩存、一次 IO 緩沖區(qū)都在影響著系統(tǒng)的內(nèi)存軌跡。8. 內(nèi)存異常信息速查表下面用一張表格匯總前文提到的典型報(bào)錯(cuò)方便你實(shí)際排查時(shí)對(duì)照。異常信息或退出碼直接含義常見根因第一排查方向OutOfMemoryError: Java heap spaceJava 堆無法分配對(duì)象堆過小、集合持有大量對(duì)象導(dǎo)出 Heap Dump查看大對(duì)象持有鏈OutOfMemoryError: Metaspace元數(shù)據(jù)區(qū)耗盡類加載器泄漏、動(dòng)態(tài)生成類過多查看類加載數(shù)與 Metaspace 配置OutOfMemoryError: GC overhead limit exceededGC 頻繁但回收效果差堆基本被占滿先看堆容量和 GC 日志再做 Heap DumpProcess exited with code 3221225477Windows 訪問違例0xC0000005野指針、JNI native 崩潰查找hs_err_pid*.log分析崩潰棧Native memory allocation (malloc) failed to allocate ...JVM 無法向系統(tǒng)申請(qǐng)內(nèi)存系統(tǒng)/容器內(nèi)存不足、映射數(shù)超限檢查整機(jī)與 cgroup 內(nèi)存水位容器被OOMKilled進(jìn)程超過容器內(nèi)存限制堆外內(nèi)存占用超預(yù)算檢查 JVM 容器感知與內(nèi)存 limit 設(shè)置這份表格并不能覆蓋所有內(nèi)存問題但可以作為一條快速分類線。先把錯(cuò)誤歸類再?zèng)Q定要不要看堆、看系統(tǒng)內(nèi)存還是看崩潰日志。很多排查卡殼往往是因?yàn)橐婚_始就進(jìn)錯(cuò)了方向。9. 長期可落地的內(nèi)存治理實(shí)踐與其每次都“救火”不如把內(nèi)存治理變成工程日常。結(jié)合服務(wù)端與嵌入式項(xiàng)目的共性建議從下面幾個(gè)方面建立機(jī)制。第一從源頭控制分配。寫代碼時(shí)要明確大對(duì)象的生命周期哪些是短生命周期的局部對(duì)象哪些是全局緩存哪些是運(yùn)行時(shí)決定的動(dòng)態(tài)集合。對(duì)緩存的引用一定要能清理否則遲早會(huì)變成“隱形的內(nèi)存泄漏”。接口返回大批量數(shù)據(jù)時(shí)優(yōu)先使用流式處理而不是一次性集合全量加載。第二建立內(nèi)存監(jiān)控的可觀測(cè)體系。Java 服務(wù)至少要有堆使用率、GC 次數(shù)與耗時(shí)、Metaspace、線程數(shù)、native 內(nèi)存估算和 RSS 指標(biāo)。接入 Prometheus 后可以給關(guān)鍵指標(biāo)配置告警。更重要的是留存歷史曲線否則內(nèi)存漲了 5% 時(shí)沒有人在意等漲到 90% 才發(fā)現(xiàn)排查難度會(huì)成倍上升。第三堅(jiān)持版本發(fā)布前做壓力測(cè)試。內(nèi)存問題有一個(gè)特點(diǎn)它在低負(fù)載下可能完全隱匿。只有在壓測(cè)中把請(qǐng)求量抬高到線上峰值的數(shù)倍才能暴露那些“請(qǐng)求量增長時(shí)內(nèi)存也線性增長”的代碼路徑。壓測(cè)時(shí)如果發(fā)現(xiàn)內(nèi)存曲線沒有回落不要繼續(xù)加負(fù)載先拉 Heap Dump 找根因。第四設(shè)計(jì)可回滾的配置與容量預(yù)案。無論怎么優(yōu)化線上環(huán)境仍可能出現(xiàn)突發(fā)流量或未知 Bug。發(fā)布前要考慮進(jìn)程內(nèi)存告警后能否快速摘流量、能否擴(kuò)容、能否回滾。提前設(shè)計(jì)好這三級(jí)預(yù)案遠(yuǎn)比崩潰后開會(huì)復(fù)盤更有效。第五新成員培訓(xùn)中加入“內(nèi)存基礎(chǔ)”。團(tuán)隊(duì)合作時(shí)代碼評(píng)審不只看業(yè)務(wù)邏輯還要看內(nèi)存邊界。新人最容易踩的坑是把無限增長的集合當(dāng)緩存、在定時(shí)任務(wù)里創(chuàng)建大對(duì)象卻不釋放、以及完全不理解容器內(nèi)存限制對(duì) JVM 的影響。如果團(tuán)隊(duì)里人人都能識(shí)別出一段代碼“可能產(chǎn)生內(nèi)存問題”很多故障在評(píng)審階段就會(huì)被攔下。10. 寫在最后回到開頭那個(gè)比喻程序跑在內(nèi)存上就像車跑在路上。你不能等爆胎了才去補(bǔ)路而應(yīng)該形成一套持續(xù)的駕駛習(xí)慣——知道儀表盤每個(gè)數(shù)字的含義知道前方什么路況容易失控知道剎車方向和避險(xiǎn)順序。Java 的 OOM、Windows 的0xc0000005、native malloc 失敗、容器 OOMKilled其實(shí)都是同一條路上不同的“事故形態(tài)”。真正能幫到你的不是某一個(gè)-Xmx參數(shù)也不是某一個(gè)分析工具而是你看到報(bào)錯(cuò)之后能夠快速判斷這是堆的問題、GC 的問題、操作系統(tǒng)的問題還是代碼設(shè)計(jì)的問題。判斷對(duì)了排查只是時(shí)間問題判斷錯(cuò)了加多少內(nèi)存都只是把事故推遲到下一次。建議你把文章里的速查表和排查步驟存下來下次再遇到內(nèi)存問題時(shí)先別急著改代碼把現(xiàn)場(chǎng)信息盡可能完整地收集起來GC 日志、堆轉(zhuǎn)儲(chǔ)、系統(tǒng)內(nèi)存快照、崩潰日志、最近發(fā)布記錄。掌握了這套方法論你才算真正在“Memory”這條路上穩(wěn)穩(wěn)開過車。