行時(shí)數(shù)據(jù)區(qū)——棧、堆、方法區(qū)再認(rèn)識(shí))
1. 項(xiàng)目背景業(yè)務(wù)場景某直播平臺(tái)的彈幕服務(wù)在跨年晚會(huì)高峰期間頻繁拋出StackOverflowError導(dǎo)致彈幕推送線程崩潰觀眾看到的彈幕卡頓甚至消失。運(yùn)維通過自動(dòng)擴(kuò)容腳本臨時(shí)加了機(jī)器扛過高峰但事后復(fù)盤發(fā)現(xiàn)——同一個(gè)服務(wù)在壓測環(huán)境從未觸發(fā)過棧溢出。開發(fā)組的解釋是遞歸調(diào)用導(dǎo)致的但 Code Review 后并未發(fā)現(xiàn)任何顯式遞歸代碼。痛點(diǎn)棧幀的隱形膨脹每個(gè)方法調(diào)用都會(huì)在虛擬機(jī)棧中壓入一個(gè)棧幀包含局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法返回地址。當(dāng)調(diào)用鏈較深如復(fù)雜報(bào)表生成、嵌套 JSON 解析、Stream 操作鏈時(shí)即使沒有遞歸棧也可能溢出。線程默認(rèn)棧大小僅 1MB在一些框架層層代理的場景下很容易撐爆。方法區(qū)永久代的認(rèn)知慣性很多開發(fā)仍然認(rèn)為方法區(qū)就是 JDK 7 的永久代在 JDK 8 環(huán)境中看到OutOfMemoryError: Metaspace時(shí)一臉茫然——不知道該調(diào)-XX:MaxMetaspaceSize而反復(fù)加-Xmx。直接內(nèi)存的靜默泄漏NIO 的ByteBuffer.allocateDirect()分配的是堆外內(nèi)存不受-Xmx約束但受物理內(nèi)存限制。一旦泄漏表現(xiàn)是堆使用率正常但系統(tǒng)整體內(nèi)存耗盡令運(yùn)維困惑。本章打破過時(shí)認(rèn)知重新理解現(xiàn)代 HotSpot 的運(yùn)行時(shí)數(shù)據(jù)區(qū)布局——線程私有的 PC、VM Stack、Native Stack 以及線程共享的 Heap、Metaspace、直接內(nèi)存——并手把手復(fù)現(xiàn) Heap OOM、Metaspace OOM、Direct OOM 和 StackOverflowError 四大經(jīng)典問題。2. 項(xiàng)目設(shè)計(jì)小胖正在看一份 OOM 日志上面寫著java.lang.OutOfMemoryError: Metaspace。小胖大師我就納悶了——OOM 不就是堆滿了嘛為什么還有Metaspace OOM這種怪東西我記得以前在 JDK 7 的文檔里看到過叫永久代 OOM這倆是同一個(gè)東西嗎大師搖頭你這個(gè)問題暴露出兩個(gè)關(guān)鍵誤解。第一堆滿了只是 OOM 的一種JVM 規(guī)范定義了多種 OOM 類型第二永久代和Metaspace是 JVM 同一個(gè)邏輯區(qū)域在不同 JDK 版本中的兩種不同實(shí)現(xiàn)。讓我先給你畫一張完整版運(yùn)行時(shí)數(shù)據(jù)區(qū)地圖┌─────────────────────────────────────────────────────┐ │ JVM 進(jìn)程 │ │ │ │ ┌──── 線程私有 ────────────────────────────────┐ │ │ │ 線程1: [PC][虛擬機(jī)棧][本地方法棧] │ │ │ │ 線程2: [PC][虛擬機(jī)棧][本地方法棧] │ │ │ │ 線程3: [PC][虛擬機(jī)棧][本地方法棧] │ │ │ │ ... │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ ┌──── 線程共享 ────────┐ ┌── 堆外 / 本地 ────┐ │ │ │ ┌─────────────────┐ │ │ │ │ │ │ │ 堆 (Heap) │ │ │ Metaspace │ │ │ │ │ - 新生代 │ │ │ (類元數(shù)據(jù)) │ │ │ │ │ - 老年代 │ │ │ │ │ │ │ │ - 字符串常量池 │ │ │ 直接內(nèi)存 │ │ │ │ └─────────────────┘ │ │ (ByteBuffer等) │ │ │ └──────────────────────┘ └─────────────────────┘ │ └─────────────────────────────────────────────────────┘技術(shù)映射堆 ? 公共儲(chǔ)物間誰都能往里放東西、取東西虛擬機(jī)棧 ? 每個(gè)人的私人儲(chǔ)物柜只有自己能訪問線程結(jié)束就清空Metaspace ? 物業(yè)管理處的檔案室存放所有業(yè)主的信息卡片不占儲(chǔ)物間空間但在大樓里。小白等一下你說方法區(qū)和Metaspace不是一回事那方法區(qū)到底是什么大師好這是一個(gè)貫穿三代 JDK 的概念演進(jìn)JDK 版本方法區(qū)的物理實(shí)現(xiàn)內(nèi)存位置大小限制JDK ≤7永久代 (PermGen)JVM 堆中-XX:MaxPermSizeJDK 8Metaspace本地內(nèi)存 (Native)-XX:MaxMetaspaceSize“方法區(qū)是 JVM 規(guī)范中的邏輯概念用來存放類的結(jié)構(gòu)信息字段、方法、常量池、JIT 編譯后的代碼——它是法律條文”。永久代是 JDK 7 的舊版執(zhí)法方式Metaspace 是 JDK 8 的新版執(zhí)法方式。兩種實(shí)現(xiàn)要實(shí)現(xiàn)同一個(gè)法律目標(biāo)。為什么從永久代轉(zhuǎn)為 Metaspace核心原因永久代在堆內(nèi)大小受-Xmx限制且類卸載條件苛刻。一旦用了大量反射、動(dòng)態(tài)代理或 Groovy 腳本類元數(shù)據(jù)可能撐爆永久代→觸發(fā) Full GC→Full GC 也回收不了→最終 OOM。換成 Metaspace 后元數(shù)據(jù)存在本地內(nèi)存大小與堆獨(dú)立默認(rèn)不設(shè)上限OutOfMemory 的條件從堆滿變成了本地內(nèi)存滿。技術(shù)映射永久代 ? 食堂的紙質(zhì)菜譜檔案都擠在廚房里占做菜空間Metaspace ? 電子菜譜云盤在獨(dú)立的服務(wù)器上不擠占廚房面積。小胖那 Java 棧幀到底長啥樣我每次看異常堆棧也就看見類名:行號(hào)感覺很抽象。大師在紙上畫出棧幀結(jié)構(gòu)┌──────────────────────────┐ │ 棧幀 (Stack Frame) │ ├──────────────────────────┤ │ 局部變量表 (Local Vars) │ ← 方法參數(shù) 局部變量 │ [this][arg1][arg2]... │ 按 slot 編號(hào)long/double 占 2 個(gè) slot ├──────────────────────────┤ │ 操作數(shù)棧 (Operand Stack) │ ← 字節(jié)碼指令的暫存區(qū) │ [val1][val2][val3]... │ 先 push 后 pop類似 RPN 計(jì)算器 ├──────────────────────────┤ │ 動(dòng)態(tài)鏈接 (Dynamic Link) │ ← 指向運(yùn)行時(shí)常量池中該方法的引用 │ → Constant Pool #N │ ├──────────────────────────┤ │ 返回地址 (Return Addr) │ ← 方法執(zhí)行完后回到哪條指令 └──────────────────────────┘對(duì)于一個(gè)方法public int add(int a, int b) { return a b; }調(diào)用方把參數(shù)a, b壓入操作數(shù)棧invokevirtual指令創(chuàng)建新棧幀參數(shù)傳遞到新棧幀的局部變量表slot 0 this, slot 1 a, slot 2 biload_1把 a 壓入操作數(shù)棧iload_2把 b 壓入操作數(shù)棧iadd彈出兩個(gè)值相加結(jié)果壓回操作數(shù)棧ireturn彈出結(jié)果棧幀銷毀返回調(diào)用方技術(shù)映射棧幀 ? 廚房的一道工序工單——局部變量表是原料清單操作數(shù)棧是料理臺(tái)返回地址是出菜窗口號(hào)。小白那直接內(nèi)存又是什么最近用了 Netty 做網(wǎng)關(guān)經(jīng)常看到UnpooledByteBufAllocator的文檔里提到堆外內(nèi)存。它不在堆里也不在棧里那從哪來的大師直接內(nèi)存是通過Unsafe.allocateMemory()或ByteBuffer.allocateDirect()從操作系統(tǒng)的本地堆C heap直接分配的內(nèi)存區(qū)域。它的特點(diǎn)不受 GC 管理GC 不會(huì)自動(dòng)回收直接內(nèi)存釋放依賴于Cleaner虛引用機(jī)制或手動(dòng)((DirectBuffer) buf).cleaner().clean()。不受-Xmx限制堆設(shè)成 4G但你可以分配 6G 直接內(nèi)存只要物理內(nèi)存夠。適合 IO 場景避免了堆內(nèi)存 → 直接內(nèi)存的數(shù)據(jù)拷貝NIO 的零拷貝就靠它。但正因?yàn)椴皇?GC 管一旦代碼忘記手動(dòng)釋放或Cleaner延遲觸發(fā)直接內(nèi)存會(huì)悄悄吃掉所有系統(tǒng)可用內(nèi)存直到 OS 的 OOM Killer 把 JVM 進(jìn)程殺掉。技術(shù)映射堆內(nèi)內(nèi)存 ? 食堂大堂的餐盤服務(wù)員會(huì)收走并清洗——GC 管理直接內(nèi)存 ? 外賣的一次性餐盒顧客自己扔扔不扔得看自覺——手動(dòng)管理。3. 項(xiàng)目實(shí)戰(zhàn)3.1 環(huán)境準(zhǔn)備組件版本用途JDKOpenJDK 21運(yùn)行 OOM 復(fù)現(xiàn)程序診斷工具jcmd, jstat, jmap觀察內(nèi)存區(qū)域使用情況腳本Shell / PowerShell一鍵運(yùn)行四種 OOM 復(fù)現(xiàn)3.2 分步實(shí)現(xiàn)步驟一復(fù)現(xiàn) Heap OOM目標(biāo)不斷分配對(duì)象但保持引用直到堆內(nèi)存耗盡。// HeapOOM.java —— 堆內(nèi)存溢出復(fù)現(xiàn)importjava.util.*;publicclassHeapOOM{staticclassOOMObject{privatebyte[]datanewbyte[1024*64];// 64KB per object}publicstaticvoidmain(String[]args){System.out.println(PID: ProcessHandle.current().pid());System.out.println(開始分配 Heap 對(duì)象等待 OOM...);ListOOMObjectlistnewArrayList();try{while(true){list.add(newOOMObject());if(list.size()%10000){System.out.println(已分配: list.size() 個(gè)對(duì)象);}}}catch(OutOfMemoryErrore){System.out.println(OOM 類型: e.getClass().getName());System.out.println(提示: e.getMessage());System.out.println(已分配對(duì)象數(shù): list.size());}}}# 編譯運(yùn)行限制堆為 32MB 以加速觸發(fā)javac HeapOOM.javajava-Xms32m-Xmx32m-XX:HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath./heap_oom.hprof\HeapOOM# 運(yùn)行輸出# 開始分配 Heap 對(duì)象等待 OOM...# 已分配: 1000 個(gè)對(duì)象 (64MB - 超過 32MB 堆限制)# OOM 類型: java.lang.OutOfMemoryError# 提示: Java heap space ← 關(guān)鍵明確表明是 Heap OOM步驟二復(fù)現(xiàn) StackOverflowError目標(biāo)通過深層遞歸調(diào)用耗盡虛擬機(jī)棧空間。// StackOverflowDemo.java —— 棧溢出復(fù)現(xiàn)publicclassStackOverflowDemo{privatestaticintdepth0;publicstaticvoiddeepCall(){// 每個(gè)棧幀約占用局部變量(long x ≈ 200 bytes) 操作數(shù)棧等 ≈ 250-300 byteslonga,b,c,d,e,f,g,h,i,j;longk,l,m,n,o,p,q,r,s,t;longu,v,w,x,y,z;uvwxyzabcdefghij0L;klmnopqrst0L;depth;deepCall();}publicstaticvoidmain(String[]args){System.out.println(線程默認(rèn)棧大小: Runtime.getRuntime().totalMemory()/1024/1024MB heap, 棧約 1MB/線程);try{deepCall();}catch(StackOverflowErrore){System.out.println(StackOverflowError 觸發(fā));System.out.println(遞歸深度: depth);// 粗略估算每幀大小 ≈ 1MB / depthSystem.out.println(估計(jì)每幀大小: (1024*1024/depth) bytes);}// 演示增加棧大小后的效果System.out.println();System.out.println(現(xiàn)在用更大的棧 (-Xss2m) 重新運(yùn)行看深度變化...);System.out.println(請手動(dòng)執(zhí)行: java -Xss2m StackOverflowDemo);}}# 默認(rèn)棧約1MBjavac StackOverflowDemo.javajavaStackOverflowDemo# 輸出遞歸深度約 2500-3500 層# 增加棧大小到 2MBjava-Xss2mStackOverflowDemo# 輸出遞歸深度約 5000-7000 層深度翻倍步驟三復(fù)現(xiàn) Metaspace OOM目標(biāo)用 CGLIB 或動(dòng)態(tài)代理不斷生成類耗盡 Metaspace。// MetaspaceOOM.java —— 元空間溢出復(fù)現(xiàn)importnet.sf.cglib.proxy.*;publicclassMetaspaceOOM{staticclassSampleClass{publicvoiddoSomething(){}}publicstaticvoidmain(String[]args){System.out.println(PID: ProcessHandle.current().pid());System.out.println(開始動(dòng)態(tài)生成類等待 Metaspace OOM...);intcount0;try{while(true){EnhancerenhancernewEnhancer();enhancer.setSuperclass(SampleClass.class);enhancer.setUseCache(false);// 不緩存生成的類enhancer.setCallback(newMethodInterceptor(){publicObjectintercept(Objectobj,java.lang.reflect.Methodmethod,Object[]args,MethodProxyproxy)throwsThrowable{returnproxy.invokeSuper(obj,args);}});enhancer.create();// 每次生成一個(gè)新的子類count;if(count%10000){System.out.println(已生成 count 個(gè)類);}}}catch(Throwablee){System.out.println(異常類型: e);System.out.println(已生成類總數(shù): count);// 可能拋出: OutOfMemoryError: Metaspace}}}# 添加 CGLIB 依賴后運(yùn)行# Maven 依賴: cglib:cglib:3.3.0# 限制 Metaspace 為 32MBjava-XX:MaxMetaspaceSize32m-XX:MetaspaceSize32m\-cp.:cglib-3.3.0.jarMetaspaceOOM# 輸出# 異常類型: java.lang.OutOfMemoryError: Metaspace# 已生成類總數(shù): ~9500如果不想用 CGLIB也可以用純 JDK 方式更簡單// MetaspaceOOM_PureJDK.java —— 無需第三方依賴importjava.io.*;importjava.net.*;importjava.lang.reflect.Method;publicclassMetaspaceOOM_PureJDK{publicstaticvoidmain(String[]args)throwsException{System.out.println(開始用 URLClassLoader 反復(fù)加載類...);intcount0;// 準(zhǔn)備一個(gè)類文件路徑FileclassDirnewFile(./test_classes);classDir.mkdirs();// 復(fù)制一個(gè)存在的 class 文件到測試目錄Files.copy(newFile(./MetaspaceOOM_PureJDK.class).toPath(),newFile(./test_classes/MetaspaceOOM_PureJDK.class).toPath(),java.nio.file.StandardCopyOption.REPLACE_EXISTING);try{while(true){URL[]urls{classDir.toURI().toURL()};URLClassLoaderloadernewURLClassLoader(urls,null);// parentnull 防止委托l(wèi)oader.loadClass(MetaspaceOOM_PureJDK);count;if(count%10000){System.out.println(已創(chuàng)建 ClassLoader 數(shù): count);}}}catch(OutOfMemoryErrore){System.out.println(OOM: e.getMessage());System.out.println(已創(chuàng)建 ClassLoader 數(shù): count);}}}步驟四復(fù)現(xiàn) Direct Buffer OOM目標(biāo)不斷分配直接內(nèi)存而不釋放直到系統(tǒng)內(nèi)存耗盡。// DirectOOM.java —— 直接內(nèi)存溢出復(fù)現(xiàn)importjava.nio.ByteBuffer;importjava.util.*;publicclassDirectOOM{publicstaticvoidmain(String[]args){System.out.println(PID: ProcessHandle.current().pid());System.out.println(開始分配直接內(nèi)存注意不受 -Xmx 限制...);ListByteBufferbuffersnewArrayList();longtotalAllocated0L;intsingleSize10*1024*1024;// 每次分配 10MBtry{for(inti0;;i){ByteBufferbufByteBuffer.allocateDirect(singleSize);buffers.add(buf);// 保持強(qiáng)引用防止被 GC 回收totalAllocatedsingleSize;if(i%100){System.out.println(已分配直接內(nèi)存: (totalAllocated/1024/1024) MB);}}}catch(OutOfMemoryErrore){System.out.println(OOM 類型: e.getMessage());System.out.println(已分配直接內(nèi)存: (totalAllocated/1024/1024) MB);// 注意直接內(nèi)存的 OOM 消息可能是Direct buffer memory// 也可能只是Java heap space如果堆內(nèi) ByteBuffer 對(duì)象過多}}}# 限制堆為 64MB限制直接內(nèi)存為 128MBjavac DirectOOM.javajava-Xms64m-Xmx64m-XX:MaxDirectMemorySize128m DirectOOM# 輸出# 已分配直接內(nèi)存: 100 MB# 已分配直接內(nèi)存: 120 MB# OOM 類型: Direct buffer memory可能遇到的坑Metaspace OOM 未觸發(fā)如果 Metaspace 不設(shè)上限默認(rèn)需要分配海量類才能觸發(fā) OOM。此時(shí)系統(tǒng)可能會(huì)先因本地內(nèi)存耗盡而卡死。務(wù)必設(shè)置-XX:MaxMetaspaceSize32m。Direct Buffer 的 OOM 誤導(dǎo)性ByteBuffer.allocateDirect()如果只能用堆外內(nèi)存但 OOM 消息可能是Java heap space——因?yàn)?JVM 在堆內(nèi)創(chuàng)建的DirectByteBuffer對(duì)象本身在堆上。需要結(jié)合-XX:MaxDirectMemorySize區(qū)分。-Xss設(shè)置不宜過大雖然增加棧大小可容納更深調(diào)用棧但每個(gè)線程都需分配獨(dú)立棧。500 線程 × 2MB 1GB 棧內(nèi)存。業(yè)務(wù)線程數(shù)過多時(shí)可能內(nèi)存不足表現(xiàn)為OutOfMemoryError: unable to create native thread。3.3 綜合測試驗(yàn)證#!/bin/bash# verify_oom.sh —— 一鍵驗(yàn)證四種內(nèi)存區(qū)域echo 1. Heap OOM (堆內(nèi)存溢出) java-Xmx32m-XX:HeapDumpOnOutOfMemoryErrorHeapOOM21|grepOOM 類型echoecho 2. StackOverflow (棧溢出) java-Xss256kStackOverflowDemo21|grepStackOverflowErrorechoecho 3. Metaspace OOM (元空間溢出) java-XX:MaxMetaspaceSize16m-cp.:cglib-3.3.0.jarMetaspaceOOM21|grepMetaspaceechoecho 4. Direct OOM (直接內(nèi)存溢出) java-Xmx64m-XX:MaxDirectMemorySize32m DirectOOM21|grepDirect驗(yàn)證標(biāo)準(zhǔn)四種 OOM 的錯(cuò)誤消息分別包含Java heap space、StackOverflowError、Metaspace、Direct buffer memory。4. 項(xiàng)目總結(jié)4.1 優(yōu)點(diǎn)與缺點(diǎn)維度優(yōu)點(diǎn)缺點(diǎn)內(nèi)存隔離棧私有、堆共享的設(shè)計(jì)天然隔離了線程局部數(shù)據(jù)和全局?jǐn)?shù)據(jù)局部變量表沒有溢出保護(hù)——局部變量過多只會(huì)靜默膨脹棧幀Metaspace與堆解耦類元數(shù)據(jù)膨脹不再引發(fā) Full GC默認(rèn)不設(shè)上限本地內(nèi)存耗盡時(shí)進(jìn)程直接被殺無緩沖直接內(nèi)存零拷貝 IO 路徑適合網(wǎng)關(guān)/中間件等 IO 密集型場景無 GC 管理泄漏影響全局Cleaner虛引用釋放有延遲棧幀模型與字節(jié)碼執(zhí)行模型完美配合指令集天然適應(yīng)棧式架構(gòu)棧內(nèi)存線性分配不支持棧內(nèi)隨機(jī)訪問模式OOM 分類精準(zhǔn)每種 OOM 有獨(dú)立的錯(cuò)誤消息和診斷路徑混合場景下堆 OOM Metaspace OOM 同時(shí)發(fā)生先觸發(fā)的 OOM 可能掩蓋后一個(gè)4.2 適用場景故障分類準(zhǔn)入收到 OOM 告警后根據(jù)錯(cuò)誤消息快速定位是堆/棧/Metaspace/直接內(nèi)存中的哪一類問題。容量規(guī)劃根據(jù)業(yè)務(wù)對(duì)象模型估算堆大小、根據(jù)動(dòng)態(tài)類數(shù)量估算 Metaspace 大小、根據(jù) IO 緩沖區(qū)用量估算直接內(nèi)存大小。遞歸代碼風(fēng)險(xiǎn)評(píng)估在 Code Review 時(shí)對(duì)深層嵌套調(diào)用鏈路做棧深度估算。框架選型選擇動(dòng)態(tài)類生成密集的框架Groovy、CGLIB、動(dòng)態(tài)代理時(shí)評(píng)估 Metaspace 額外開銷。容器化部署K8s 的 memory limits 需要覆蓋堆 Metaspace 直接內(nèi)存 線程棧總合不能只看堆。不適用場景純計(jì)算型服務(wù)沒有復(fù)雜調(diào)用鏈、沒有動(dòng)態(tài)類生成、沒有 NIO——內(nèi)存問題基本聚焦在堆上其他區(qū)域不是瓶頸。堆內(nèi)存充足≥ 16GB的單體應(yīng)用如果無 IO 需求直接內(nèi)存的收益不明顯。4.3 注意事項(xiàng)類型詳細(xì)說明棧大小-Xss在 JDK 各版本默認(rèn)值不同JDK 8 約 1MBJDK 17 在容器中可能降到 512KB遷移時(shí)注意棧大小可能影響遞歸極限Metaspace 壓縮JDK 12 引入 Metaspace 壓縮MetaspaceReclaimPolicy空閑 Chunk 可被回收歸還操作系統(tǒng)但不是所有版本都默認(rèn)開啟直接內(nèi)存的 CleanerDirectByteBuffer的Cleaner在對(duì)象被 GC 時(shí)觸發(fā)釋放但 GC 時(shí)間不可控——高分配率下可能堆積大量待釋放的直接內(nèi)存字符串常量池遷移JDK 7 起字符串常量池從永久代移到堆中JDK 7 時(shí)代用String.intern()節(jié)約永久代的技巧在 JDK 8 已無必要4.4 常見踩坑經(jīng)驗(yàn)案例 1Stream 嵌套操作導(dǎo)致 StackOverflow某報(bào)表系統(tǒng)用鏈?zhǔn)?Stream 操作處理大數(shù)據(jù)集stream.filter().map().flatMap().collect()在 JDK 8 上運(yùn)行正常升級(jí) JDK 11 后偶發(fā)StackOverflowError。根因Stream API 的flatMap內(nèi)部實(shí)現(xiàn)在不同 JDK 版本的惰性求值lazy evaluation嵌套層數(shù)不同JDK 11 的實(shí)現(xiàn)可能比 JDK 8 多 2-3 層遞歸幀。修復(fù)拆分超長 Stream 鏈為多段中間加collect(Collectors.toList())強(qiáng)制求值減小調(diào)用深度。案例 2Groovy 腳本引擎耗盡 Metaspace風(fēng)控規(guī)則引擎用 GroovyShell 解析用戶提交的規(guī)則腳本。每個(gè)腳本生成一個(gè)Script子類總共 8 萬條規(guī)則占用了近 2GB Metaspace。根因GroovyClassLoader 為每個(gè)腳本創(chuàng)建獨(dú)立的ClassLoader且未設(shè)置clearCache()。修復(fù)改為統(tǒng)一使用一個(gè)GroovyShell實(shí)例 每 1000 次執(zhí)行后調(diào)getClassLoader().clearCache()同時(shí)設(shè)置-XX:MaxMetaspaceSize512m。案例 3Netty 網(wǎng)關(guān)的幽靈 OOMNetty 網(wǎng)關(guān)在壓測中表現(xiàn)良好但生產(chǎn)運(yùn)行 72 小時(shí)后進(jìn)程被 OOM Killer 殺掉堆 dump 只顯示 4GB堆上限 8GB但 OS 顯示進(jìn)程 RSS 為 15GB。根因Netty 的PooledByteBufAllocator在堆外維護(hù)了一大片內(nèi)存池用于 IO 緩沖但業(yè)務(wù)代碼中每次請求創(chuàng)建了一個(gè)Unpooled.directBuffer()且沒有調(diào)用release()。修復(fù)使用ReferenceCountUtil.release()規(guī)范釋放模式增加-Dio.netty.leakDetection.levelPARANOID排查泄漏點(diǎn)。4.5 思考題進(jìn)階題JDK 8 中的字符串常量池從永久代移到了堆中。請?jiān)O(shè)計(jì)一個(gè)實(shí)驗(yàn)——在 JDK 7 和 JDK 8 上分別運(yùn)行相同的String.intern()密集程序?qū)Ρ葍烧叩?OOM 行為差異和 GC 表現(xiàn)。提示JDK 7 會(huì)拋出OutOfMemoryError: PermGen spaceJDK 8 則是Java heap space。實(shí)戰(zhàn)題你的微服務(wù)-Xmx設(shè)為 4GB-XX:MaxMetaspaceSize默不作限制-XX:MaxDirectMemorySize也未顯式設(shè)置。Docker 容器的 memory limit 也是 4GB。請問運(yùn)行中可能出現(xiàn)哪些堆沒滿但進(jìn)程被殺的情況請列出至少 3 種并給出參數(shù)層面的修復(fù)方案。答案提示思考題 1 答案見第 1 章 Metaspace vs PermGen 對(duì)照表思考題 2 答案見第 28 章容器感知。下一章預(yù)告第 7 章將深入 Java 并發(fā)世界的第一道門——線程模型與 synchronized從線程生命周期到鎖升級(jí)偏向→輕量→重量手把手實(shí)現(xiàn)一個(gè)線程安全的簡易阻塞隊(duì)列。 第6章：OpenJDK運(yùn)行時(shí)數(shù)據(jù)區(qū)——棧、堆、方法區(qū)再認(rèn)識(shí)
1. 項(xiàng)目背景業(yè)務(wù)場景某直播平臺(tái)的彈幕服務(wù)在跨年晚會(huì)高峰期間頻繁拋出StackOverflowError導(dǎo)致彈幕推送線程崩潰觀眾看到的彈幕卡頓甚至消失。運(yùn)維通過自動(dòng)擴(kuò)容腳本臨時(shí)加了機(jī)器扛過高峰但事后復(fù)盤發(fā)現(xiàn)——同一個(gè)服務(wù)在壓測環(huán)境從未觸發(fā)過棧溢出。開發(fā)組的解釋是遞歸調(diào)用導(dǎo)致的但 Code Review 后并未發(fā)現(xiàn)任何顯式遞歸代碼。痛點(diǎn)棧幀的隱形膨脹每個(gè)方法調(diào)用都會(huì)在虛擬機(jī)棧中壓入一個(gè)棧幀包含局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接、方法返回地址。當(dāng)調(diào)用鏈較深如復(fù)雜報(bào)表生成、嵌套 JSON 解析、Stream 操作鏈時(shí)即使沒有遞歸棧也可能溢出。線程默認(rèn)棧大小僅 1MB在一些框架層層代理的場景下很容易撐爆。方法區(qū)永久代的認(rèn)知慣性很多開發(fā)仍然認(rèn)為方法區(qū)就是 JDK 7 的永久代在 JDK 8 環(huán)境中看到OutOfMemoryError: Metaspace時(shí)一臉茫然——不知道該調(diào)-XX:MaxMetaspaceSize而反復(fù)加-Xmx。直接內(nèi)存的靜默泄漏NIO 的ByteBuffer.allocateDirect()分配的是堆外內(nèi)存不受-Xmx約束但受物理內(nèi)存限制。一旦泄漏表現(xiàn)是堆使用率正常但系統(tǒng)整體內(nèi)存耗盡令運(yùn)維困惑。本章打破過時(shí)認(rèn)知重新理解現(xiàn)代 HotSpot 的運(yùn)行時(shí)數(shù)據(jù)區(qū)布局——線程私有的 PC、VM Stack、Native Stack 以及線程共享的 Heap、Metaspace、直接內(nèi)存——并手把手復(fù)現(xiàn) Heap OOM、Metaspace OOM、Direct OOM 和 StackOverflowError 四大經(jīng)典問題。2. 項(xiàng)目設(shè)計(jì)小胖正在看一份 OOM 日志上面寫著java.lang.OutOfMemoryError: Metaspace。小胖大師我就納悶了——OOM 不就是堆滿了嘛為什么還有Metaspace OOM這種怪東西我記得以前在 JDK 7 的文檔里看到過叫永久代 OOM這倆是同一個(gè)東西嗎大師搖頭你這個(gè)問題暴露出兩個(gè)關(guān)鍵誤解。第一堆滿了只是 OOM 的一種JVM 規(guī)范定義了多種 OOM 類型第二永久代和Metaspace是 JVM 同一個(gè)邏輯區(qū)域在不同 JDK 版本中的兩種不同實(shí)現(xiàn)。讓我先給你畫一張完整版運(yùn)行時(shí)數(shù)據(jù)區(qū)地圖┌─────────────────────────────────────────────────────┐ │ JVM 進(jìn)程 │ │ │ │ ┌──── 線程私有 ────────────────────────────────┐ │ │ │ 線程1: [PC][虛擬機(jī)棧][本地方法棧] │ │ │ │ 線程2: [PC][虛擬機(jī)棧][本地方法棧] │ │ │ │ 線程3: [PC][虛擬機(jī)棧][本地方法棧] │ │ │ │ ... │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ ┌──── 線程共享 ────────┐ ┌── 堆外 / 本地 ────┐ │ │ │ ┌─────────────────┐ │ │ │ │ │ │ │ 堆 (Heap) │ │ │ Metaspace │ │ │ │ │ - 新生代 │ │ │ (類元數(shù)據(jù)) │ │ │ │ │ - 老年代 │ │ │ │ │ │ │ │ - 字符串常量池 │ │ │ 直接內(nèi)存 │ │ │ │ └─────────────────┘ │ │ (ByteBuffer等) │ │ │ └──────────────────────┘ └─────────────────────┘ │ └─────────────────────────────────────────────────────┘技術(shù)映射堆 ? 公共儲(chǔ)物間誰都能往里放東西、取東西虛擬機(jī)棧 ? 每個(gè)人的私人儲(chǔ)物柜只有自己能訪問線程結(jié)束就清空Metaspace ? 物業(yè)管理處的檔案室存放所有業(yè)主的信息卡片不占儲(chǔ)物間空間但在大樓里。小白等一下你說方法區(qū)和Metaspace不是一回事那方法區(qū)到底是什么大師好這是一個(gè)貫穿三代 JDK 的概念演進(jìn)JDK 版本方法區(qū)的物理實(shí)現(xiàn)內(nèi)存位置大小限制JDK ≤7永久代 (PermGen)JVM 堆中-XX:MaxPermSizeJDK 8Metaspace本地內(nèi)存 (Native)-XX:MaxMetaspaceSize“方法區(qū)是 JVM 規(guī)范中的邏輯概念用來存放類的結(jié)構(gòu)信息字段、方法、常量池、JIT 編譯后的代碼——它是法律條文”。永久代是 JDK 7 的舊版執(zhí)法方式Metaspace 是 JDK 8 的新版執(zhí)法方式。兩種實(shí)現(xiàn)要實(shí)現(xiàn)同一個(gè)法律目標(biāo)。為什么從永久代轉(zhuǎn)為 Metaspace核心原因永久代在堆內(nèi)大小受-Xmx限制且類卸載條件苛刻。一旦用了大量反射、動(dòng)態(tài)代理或 Groovy 腳本類元數(shù)據(jù)可能撐爆永久代→觸發(fā) Full GC→Full GC 也回收不了→最終 OOM。換成 Metaspace 后元數(shù)據(jù)存在本地內(nèi)存大小與堆獨(dú)立默認(rèn)不設(shè)上限OutOfMemory 的條件從堆滿變成了本地內(nèi)存滿。技術(shù)映射永久代 ? 食堂的紙質(zhì)菜譜檔案都擠在廚房里占做菜空間Metaspace ? 電子菜譜云盤在獨(dú)立的服務(wù)器上不擠占廚房面積。小胖那 Java 棧幀到底長啥樣我每次看異常堆棧也就看見類名:行號(hào)感覺很抽象。大師在紙上畫出棧幀結(jié)構(gòu)┌──────────────────────────┐ │ 棧幀 (Stack Frame) │ ├──────────────────────────┤ │ 局部變量表 (Local Vars) │ ← 方法參數(shù) 局部變量 │ [this][arg1][arg2]... │ 按 slot 編號(hào)long/double 占 2 個(gè) slot ├──────────────────────────┤ │ 操作數(shù)棧 (Operand Stack) │ ← 字節(jié)碼指令的暫存區(qū) │ [val1][val2][val3]... │ 先 push 后 pop類似 RPN 計(jì)算器 ├──────────────────────────┤ │ 動(dòng)態(tài)鏈接 (Dynamic Link) │ ← 指向運(yùn)行時(shí)常量池中該方法的引用 │ → Constant Pool #N │ ├──────────────────────────┤ │ 返回地址 (Return Addr) │ ← 方法執(zhí)行完后回到哪條指令 └──────────────────────────┘對(duì)于一個(gè)方法public int add(int a, int b) { return a b; }調(diào)用方把參數(shù)a, b壓入操作數(shù)棧invokevirtual指令創(chuàng)建新棧幀參數(shù)傳遞到新棧幀的局部變量表slot 0 this, slot 1 a, slot 2 biload_1把 a 壓入操作數(shù)棧iload_2把 b 壓入操作數(shù)棧iadd彈出兩個(gè)值相加結(jié)果壓回操作數(shù)棧ireturn彈出結(jié)果棧幀銷毀返回調(diào)用方技術(shù)映射棧幀 ? 廚房的一道工序工單——局部變量表是原料清單操作數(shù)棧是料理臺(tái)返回地址是出菜窗口號(hào)。小白那直接內(nèi)存又是什么最近用了 Netty 做網(wǎng)關(guān)經(jīng)常看到UnpooledByteBufAllocator的文檔里提到堆外內(nèi)存。它不在堆里也不在棧里那從哪來的大師直接內(nèi)存是通過Unsafe.allocateMemory()或ByteBuffer.allocateDirect()從操作系統(tǒng)的本地堆C heap直接分配的內(nèi)存區(qū)域。它的特點(diǎn)不受 GC 管理GC 不會(huì)自動(dòng)回收直接內(nèi)存釋放依賴于Cleaner虛引用機(jī)制或手動(dòng)((DirectBuffer) buf).cleaner().clean()。不受-Xmx限制堆設(shè)成 4G但你可以分配 6G 直接內(nèi)存只要物理內(nèi)存夠。適合 IO 場景避免了堆內(nèi)存 → 直接內(nèi)存的數(shù)據(jù)拷貝NIO 的零拷貝就靠它。但正因?yàn)椴皇?GC 管一旦代碼忘記手動(dòng)釋放或Cleaner延遲觸發(fā)直接內(nèi)存會(huì)悄悄吃掉所有系統(tǒng)可用內(nèi)存直到 OS 的 OOM Killer 把 JVM 進(jìn)程殺掉。技術(shù)映射堆內(nèi)內(nèi)存 ? 食堂大堂的餐盤服務(wù)員會(huì)收走并清洗——GC 管理直接內(nèi)存 ? 外賣的一次性餐盒顧客自己扔扔不扔得看自覺——手動(dòng)管理。3. 項(xiàng)目實(shí)戰(zhàn)3.1 環(huán)境準(zhǔn)備組件版本用途JDKOpenJDK 21運(yùn)行 OOM 復(fù)現(xiàn)程序診斷工具jcmd, jstat, jmap觀察內(nèi)存區(qū)域使用情況腳本Shell / PowerShell一鍵運(yùn)行四種 OOM 復(fù)現(xiàn)3.2 分步實(shí)現(xiàn)步驟一復(fù)現(xiàn) Heap OOM目標(biāo)不斷分配對(duì)象但保持引用直到堆內(nèi)存耗盡。// HeapOOM.java —— 堆內(nèi)存溢出復(fù)現(xiàn)importjava.util.*;publicclassHeapOOM{staticclassOOMObject{privatebyte[]datanewbyte[1024*64];// 64KB per object}publicstaticvoidmain(String[]args){System.out.println(PID: ProcessHandle.current().pid());System.out.println(開始分配 Heap 對(duì)象等待 OOM...);ListOOMObjectlistnewArrayList();try{while(true){list.add(newOOMObject());if(list.size()%10000){System.out.println(已分配: list.size() 個(gè)對(duì)象);}}}catch(OutOfMemoryErrore){System.out.println(OOM 類型: e.getClass().getName());System.out.println(提示: e.getMessage());System.out.println(已分配對(duì)象數(shù): list.size());}}}# 編譯運(yùn)行限制堆為 32MB 以加速觸發(fā)javac HeapOOM.javajava-Xms32m-Xmx32m-XX:HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath./heap_oom.hprof\HeapOOM# 運(yùn)行輸出# 開始分配 Heap 對(duì)象等待 OOM...# 已分配: 1000 個(gè)對(duì)象 (64MB - 超過 32MB 堆限制)# OOM 類型: java.lang.OutOfMemoryError# 提示: Java heap space ← 關(guān)鍵明確表明是 Heap OOM步驟二復(fù)現(xiàn) StackOverflowError目標(biāo)通過深層遞歸調(diào)用耗盡虛擬機(jī)棧空間。// StackOverflowDemo.java —— 棧溢出復(fù)現(xiàn)publicclassStackOverflowDemo{privatestaticintdepth0;publicstaticvoiddeepCall(){// 每個(gè)棧幀約占用局部變量(long x ≈ 200 bytes) 操作數(shù)棧等 ≈ 250-300 byteslonga,b,c,d,e,f,g,h,i,j;longk,l,m,n,o,p,q,r,s,t;longu,v,w,x,y,z;uvwxyzabcdefghij0L;klmnopqrst0L;depth;deepCall();}publicstaticvoidmain(String[]args){System.out.println(線程默認(rèn)棧大小: Runtime.getRuntime().totalMemory()/1024/1024MB heap, 棧約 1MB/線程);try{deepCall();}catch(StackOverflowErrore){System.out.println(StackOverflowError 觸發(fā));System.out.println(遞歸深度: depth);// 粗略估算每幀大小 ≈ 1MB / depthSystem.out.println(估計(jì)每幀大小: (1024*1024/depth) bytes);}// 演示增加棧大小后的效果System.out.println();System.out.println(現(xiàn)在用更大的棧 (-Xss2m) 重新運(yùn)行看深度變化...);System.out.println(請手動(dòng)執(zhí)行: java -Xss2m StackOverflowDemo);}}# 默認(rèn)棧約1MBjavac StackOverflowDemo.javajavaStackOverflowDemo# 輸出遞歸深度約 2500-3500 層# 增加棧大小到 2MBjava-Xss2mStackOverflowDemo# 輸出遞歸深度約 5000-7000 層深度翻倍步驟三復(fù)現(xiàn) Metaspace OOM目標(biāo)用 CGLIB 或動(dòng)態(tài)代理不斷生成類耗盡 Metaspace。// MetaspaceOOM.java —— 元空間溢出復(fù)現(xiàn)importnet.sf.cglib.proxy.*;publicclassMetaspaceOOM{staticclassSampleClass{publicvoiddoSomething(){}}publicstaticvoidmain(String[]args){System.out.println(PID: ProcessHandle.current().pid());System.out.println(開始動(dòng)態(tài)生成類等待 Metaspace OOM...);intcount0;try{while(true){EnhancerenhancernewEnhancer();enhancer.setSuperclass(SampleClass.class);enhancer.setUseCache(false);// 不緩存生成的類enhancer.setCallback(newMethodInterceptor(){publicObjectintercept(Objectobj,java.lang.reflect.Methodmethod,Object[]args,MethodProxyproxy)throwsThrowable{returnproxy.invokeSuper(obj,args);}});enhancer.create();// 每次生成一個(gè)新的子類count;if(count%10000){System.out.println(已生成 count 個(gè)類);}}}catch(Throwablee){System.out.println(異常類型: e);System.out.println(已生成類總數(shù): count);// 可能拋出: OutOfMemoryError: Metaspace}}}# 添加 CGLIB 依賴后運(yùn)行# Maven 依賴: cglib:cglib:3.3.0# 限制 Metaspace 為 32MBjava-XX:MaxMetaspaceSize32m-XX:MetaspaceSize32m\-cp.:cglib-3.3.0.jarMetaspaceOOM# 輸出# 異常類型: java.lang.OutOfMemoryError: Metaspace# 已生成類總數(shù): ~9500如果不想用 CGLIB也可以用純 JDK 方式更簡單// MetaspaceOOM_PureJDK.java —— 無需第三方依賴importjava.io.*;importjava.net.*;importjava.lang.reflect.Method;publicclassMetaspaceOOM_PureJDK{publicstaticvoidmain(String[]args)throwsException{System.out.println(開始用 URLClassLoader 反復(fù)加載類...);intcount0;// 準(zhǔn)備一個(gè)類文件路徑FileclassDirnewFile(./test_classes);classDir.mkdirs();// 復(fù)制一個(gè)存在的 class 文件到測試目錄Files.copy(newFile(./MetaspaceOOM_PureJDK.class).toPath(),newFile(./test_classes/MetaspaceOOM_PureJDK.class).toPath(),java.nio.file.StandardCopyOption.REPLACE_EXISTING);try{while(true){URL[]urls{classDir.toURI().toURL()};URLClassLoaderloadernewURLClassLoader(urls,null);// parentnull 防止委托l(wèi)oader.loadClass(MetaspaceOOM_PureJDK);count;if(count%10000){System.out.println(已創(chuàng)建 ClassLoader 數(shù): count);}}}catch(OutOfMemoryErrore){System.out.println(OOM: e.getMessage());System.out.println(已創(chuàng)建 ClassLoader 數(shù): count);}}}步驟四復(fù)現(xiàn) Direct Buffer OOM目標(biāo)不斷分配直接內(nèi)存而不釋放直到系統(tǒng)內(nèi)存耗盡。// DirectOOM.java —— 直接內(nèi)存溢出復(fù)現(xiàn)importjava.nio.ByteBuffer;importjava.util.*;publicclassDirectOOM{publicstaticvoidmain(String[]args){System.out.println(PID: ProcessHandle.current().pid());System.out.println(開始分配直接內(nèi)存注意不受 -Xmx 限制...);ListByteBufferbuffersnewArrayList();longtotalAllocated0L;intsingleSize10*1024*1024;// 每次分配 10MBtry{for(inti0;;i){ByteBufferbufByteBuffer.allocateDirect(singleSize);buffers.add(buf);// 保持強(qiáng)引用防止被 GC 回收totalAllocatedsingleSize;if(i%100){System.out.println(已分配直接內(nèi)存: (totalAllocated/1024/1024) MB);}}}catch(OutOfMemoryErrore){System.out.println(OOM 類型: e.getMessage());System.out.println(已分配直接內(nèi)存: (totalAllocated/1024/1024) MB);// 注意直接內(nèi)存的 OOM 消息可能是Direct buffer memory// 也可能只是Java heap space如果堆內(nèi) ByteBuffer 對(duì)象過多}}}# 限制堆為 64MB限制直接內(nèi)存為 128MBjavac DirectOOM.javajava-Xms64m-Xmx64m-XX:MaxDirectMemorySize128m DirectOOM# 輸出# 已分配直接內(nèi)存: 100 MB# 已分配直接內(nèi)存: 120 MB# OOM 類型: Direct buffer memory可能遇到的坑Metaspace OOM 未觸發(fā)如果 Metaspace 不設(shè)上限默認(rèn)需要分配海量類才能觸發(fā) OOM。此時(shí)系統(tǒng)可能會(huì)先因本地內(nèi)存耗盡而卡死。務(wù)必設(shè)置-XX:MaxMetaspaceSize32m。Direct Buffer 的 OOM 誤導(dǎo)性ByteBuffer.allocateDirect()如果只能用堆外內(nèi)存但 OOM 消息可能是Java heap space——因?yàn)?JVM 在堆內(nèi)創(chuàng)建的DirectByteBuffer對(duì)象本身在堆上。需要結(jié)合-XX:MaxDirectMemorySize區(qū)分。-Xss設(shè)置不宜過大雖然增加棧大小可容納更深調(diào)用棧但每個(gè)線程都需分配獨(dú)立棧。500 線程 × 2MB 1GB 棧內(nèi)存。業(yè)務(wù)線程數(shù)過多時(shí)可能內(nèi)存不足表現(xiàn)為OutOfMemoryError: unable to create native thread。3.3 綜合測試驗(yàn)證#!/bin/bash# verify_oom.sh —— 一鍵驗(yàn)證四種內(nèi)存區(qū)域echo 1. Heap OOM (堆內(nèi)存溢出) java-Xmx32m-XX:HeapDumpOnOutOfMemoryErrorHeapOOM21|grepOOM 類型echoecho 2. StackOverflow (棧溢出) java-Xss256kStackOverflowDemo21|grepStackOverflowErrorechoecho 3. Metaspace OOM (元空間溢出) java-XX:MaxMetaspaceSize16m-cp.:cglib-3.3.0.jarMetaspaceOOM21|grepMetaspaceechoecho 4. Direct OOM (直接內(nèi)存溢出) java-Xmx64m-XX:MaxDirectMemorySize32m DirectOOM21|grepDirect驗(yàn)證標(biāo)準(zhǔn)四種 OOM 的錯(cuò)誤消息分別包含Java heap space、StackOverflowError、Metaspace、Direct buffer memory。4. 項(xiàng)目總結(jié)4.1 優(yōu)點(diǎn)與缺點(diǎn)維度優(yōu)點(diǎn)缺點(diǎn)內(nèi)存隔離棧私有、堆共享的設(shè)計(jì)天然隔離了線程局部數(shù)據(jù)和全局?jǐn)?shù)據(jù)局部變量表沒有溢出保護(hù)——局部變量過多只會(huì)靜默膨脹棧幀Metaspace與堆解耦類元數(shù)據(jù)膨脹不再引發(fā) Full GC默認(rèn)不設(shè)上限本地內(nèi)存耗盡時(shí)進(jìn)程直接被殺無緩沖直接內(nèi)存零拷貝 IO 路徑適合網(wǎng)關(guān)/中間件等 IO 密集型場景無 GC 管理泄漏影響全局Cleaner虛引用釋放有延遲棧幀模型與字節(jié)碼執(zhí)行模型完美配合指令集天然適應(yīng)棧式架構(gòu)棧內(nèi)存線性分配不支持棧內(nèi)隨機(jī)訪問模式OOM 分類精準(zhǔn)每種 OOM 有獨(dú)立的錯(cuò)誤消息和診斷路徑混合場景下堆 OOM Metaspace OOM 同時(shí)發(fā)生先觸發(fā)的 OOM 可能掩蓋后一個(gè)4.2 適用場景故障分類準(zhǔn)入收到 OOM 告警后根據(jù)錯(cuò)誤消息快速定位是堆/棧/Metaspace/直接內(nèi)存中的哪一類問題。容量規(guī)劃根據(jù)業(yè)務(wù)對(duì)象模型估算堆大小、根據(jù)動(dòng)態(tài)類數(shù)量估算 Metaspace 大小、根據(jù) IO 緩沖區(qū)用量估算直接內(nèi)存大小。遞歸代碼風(fēng)險(xiǎn)評(píng)估在 Code Review 時(shí)對(duì)深層嵌套調(diào)用鏈路做棧深度估算。框架選型選擇動(dòng)態(tài)類生成密集的框架Groovy、CGLIB、動(dòng)態(tài)代理時(shí)評(píng)估 Metaspace 額外開銷。容器化部署K8s 的 memory limits 需要覆蓋堆 Metaspace 直接內(nèi)存 線程棧總合不能只看堆。不適用場景純計(jì)算型服務(wù)沒有復(fù)雜調(diào)用鏈、沒有動(dòng)態(tài)類生成、沒有 NIO——內(nèi)存問題基本聚焦在堆上其他區(qū)域不是瓶頸。堆內(nèi)存充足≥ 16GB的單體應(yīng)用如果無 IO 需求直接內(nèi)存的收益不明顯。4.3 注意事項(xiàng)類型詳細(xì)說明棧大小-Xss在 JDK 各版本默認(rèn)值不同JDK 8 約 1MBJDK 17 在容器中可能降到 512KB遷移時(shí)注意棧大小可能影響遞歸極限Metaspace 壓縮JDK 12 引入 Metaspace 壓縮MetaspaceReclaimPolicy空閑 Chunk 可被回收歸還操作系統(tǒng)但不是所有版本都默認(rèn)開啟直接內(nèi)存的 CleanerDirectByteBuffer的Cleaner在對(duì)象被 GC 時(shí)觸發(fā)釋放但 GC 時(shí)間不可控——高分配率下可能堆積大量待釋放的直接內(nèi)存字符串常量池遷移JDK 7 起字符串常量池從永久代移到堆中JDK 7 時(shí)代用String.intern()節(jié)約永久代的技巧在 JDK 8 已無必要4.4 常見踩坑經(jīng)驗(yàn)案例 1Stream 嵌套操作導(dǎo)致 StackOverflow某報(bào)表系統(tǒng)用鏈?zhǔn)?Stream 操作處理大數(shù)據(jù)集stream.filter().map().flatMap().collect()在 JDK 8 上運(yùn)行正常升級(jí) JDK 11 后偶發(fā)StackOverflowError。根因Stream API 的flatMap內(nèi)部實(shí)現(xiàn)在不同 JDK 版本的惰性求值lazy evaluation嵌套層數(shù)不同JDK 11 的實(shí)現(xiàn)可能比 JDK 8 多 2-3 層遞歸幀。修復(fù)拆分超長 Stream 鏈為多段中間加collect(Collectors.toList())強(qiáng)制求值減小調(diào)用深度。案例 2Groovy 腳本引擎耗盡 Metaspace風(fēng)控規(guī)則引擎用 GroovyShell 解析用戶提交的規(guī)則腳本。每個(gè)腳本生成一個(gè)Script子類總共 8 萬條規(guī)則占用了近 2GB Metaspace。根因GroovyClassLoader 為每個(gè)腳本創(chuàng)建獨(dú)立的ClassLoader且未設(shè)置clearCache()。修復(fù)改為統(tǒng)一使用一個(gè)GroovyShell實(shí)例 每 1000 次執(zhí)行后調(diào)getClassLoader().clearCache()同時(shí)設(shè)置-XX:MaxMetaspaceSize512m。案例 3Netty 網(wǎng)關(guān)的幽靈 OOMNetty 網(wǎng)關(guān)在壓測中表現(xiàn)良好但生產(chǎn)運(yùn)行 72 小時(shí)后進(jìn)程被 OOM Killer 殺掉堆 dump 只顯示 4GB堆上限 8GB但 OS 顯示進(jìn)程 RSS 為 15GB。根因Netty 的PooledByteBufAllocator在堆外維護(hù)了一大片內(nèi)存池用于 IO 緩沖但業(yè)務(wù)代碼中每次請求創(chuàng)建了一個(gè)Unpooled.directBuffer()且沒有調(diào)用release()。修復(fù)使用ReferenceCountUtil.release()規(guī)范釋放模式增加-Dio.netty.leakDetection.levelPARANOID排查泄漏點(diǎn)。4.5 思考題進(jìn)階題JDK 8 中的字符串常量池從永久代移到了堆中。請?jiān)O(shè)計(jì)一個(gè)實(shí)驗(yàn)——在 JDK 7 和 JDK 8 上分別運(yùn)行相同的String.intern()密集程序?qū)Ρ葍烧叩?OOM 行為差異和 GC 表現(xiàn)。提示JDK 7 會(huì)拋出OutOfMemoryError: PermGen spaceJDK 8 則是Java heap space。實(shí)戰(zhàn)題你的微服務(wù)-Xmx設(shè)為 4GB-XX:MaxMetaspaceSize默不作限制-XX:MaxDirectMemorySize也未顯式設(shè)置。Docker 容器的 memory limit 也是 4GB。請問運(yùn)行中可能出現(xiàn)哪些堆沒滿但進(jìn)程被殺的情況請列出至少 3 種并給出參數(shù)層面的修復(fù)方案。答案提示思考題 1 答案見第 1 章 Metaspace vs PermGen 對(duì)照表思考題 2 答案見第 28 章容器感知。下一章預(yù)告第 7 章將深入 Java 并發(fā)世界的第一道門——線程模型與 synchronized從線程生命周期到鎖升級(jí)偏向→輕量→重量手把手實(shí)現(xiàn)一個(gè)線程安全的簡易阻塞隊(duì)列。