您现在的位置：程式碼之家 >> 編程語言 > >> Java 程式設計 >> Java 相關知識

Tomcat 內存溢出三大類型深度分析與精準調優指南

編輯：Java 相關知識

生產環境 Tomcat 內存溢出（OOM）是 Java 運維高頻痛點。本文系統梳理三大核心 OOM 類型——Heap Space、PermGen/Metaspace、Unable to create new native thread——的成因、診斷路徑與差異化調優策略，助你從根因解決而非盲目加大內存。

一、三大 OOM 類型速識別

異常信息	內存區域	核心成因	典型場景
`OutOfMemoryError: Java heap space`	堆	對象分配速率 > GC 回收速率，或存在內存洩漏	大數據查詢、集合無限增長、緩存無淘汰
`OutOfMemoryError: PermGen space` (JDK<8) `OutOfMemoryError: Metaspace` (JDK≥8)	永久代/元空間	類加載量過大，GC 不回收（PermGen）或元空間上限未設	JSP 預編譯、熱部署頻繁、框架動態生成類、大量第三方庫
`OutOfMemoryError: unable to create new native thread`	本機內存（非堆）	進程虛擬地址空間耗盡，無法分配線程棧	高併發線程池、線程洩漏、堆設過大擠佔本機內存

二、 Heap Space：堆內存耗盡

觸發機制

JVM 判斷：若 98% 時間花在 GC 且可用堆 < 2%，拋出此異常。非洩漏場景下調整 -Xms -Xmx 可緩解。

關鍵參數

-Xms：初始堆大小
-Xmx：最大堆大小
建議設為相同值：避免動態擴縮容觸發 Full GC，如 -Xms2g -Xmx2g

堆大小硬性限制三因素

作業系統數據模型：32 位進程限制 1.5G~2G（Windows 通常 1.5G，Linux 3G）；64 位無實際限制。
系統可用虛擬內存：ulimit -v、swap 空間。
物理內存：堆過大導致頻繁 Swap，性能崩潰。

驗證最大可分配堆

java -Xmx2048m -version  # 能輸出版本號說明支援，報錯則超過上限

三、 PermGen / Metaspace：類元數據區溢出

本質區別

特性	PermGen (JDK 7及之前)	Metaspace (JDK 8+)
存儲位置	堆內連續空間	本機內存（Native Memory）
默認大小	固定較小（~82MB）	無上限（受限於本機內存）
GC 行為	運行期極少清理	類卸載觸發條件嚴格，但可回收
調優參數	`-XX:PermSize -XX:MaxPermSize`	`-XX:MetaspaceSize -XX:MaxMetaspaceSize`

常見誘因

JSP 預編譯產生大量類
Spring/Hibernate/MyBatis 等框架動態代理、CGLIB 生成類
熱部署/熱加載類卸載不徹底（類加載器洩漏）
大量第三方庫、依賴衝突導致重複類加載

調優策略

# JDK 7-
-XX:PermSize=128m -XX:MaxPermSize=256m

# JDK 8+
-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m

關鍵提醒：java -Xmx 測試的最大值實為 -Xmx + -XX:MaxPermSize/MaxMetaspaceSize 之和。若系統支援 1.5G 總計，則 -Xmx1g -XX:MaxMetaspaceSize=768m 會啟動失敗。

四、 Unable to create new native thread：本機線程創建失敗

反直覺現象

分配給 JVM 的堆越大，反而越容易發生此錯誤。

根因模型（32 位進程為例）

進程虛擬地址空間：2GB（用戶態），2GB 保留給內核
JVM 佔用：-Xmx + MaxPermSize + Code Cache + 直接內存 + JNI 內存
剩餘空間 = 2GB - JVM 佔用 - 系統 DLL 載入（~120MB）
每個 Java 線程需在本機內存分配棧空間：JDK 1.4 默認 256KB，JDK 1.5+ 默認 1MB
最大線程數 ≈ 剩餘空間 / 棧大小

估算公式

(MaxProcessMemory - JVMMemory - ReservedOsMemory) / ThreadStackSize = MaxThreads

實測對比（假設 OS 保留 120MB，棧 1MB）

JVM 堆配置	理論最大線程數
-Xmx1.5g	~380
-Xmx1.0g	~880

解決路徑

減小堆內存：在滿足業務前提下，適當降低 -Xmx 騰出本機內存。
縮減線程棧：-Xss256k 或 -Xss512k（需測試避免 StackOverflowError）。
優化線程模型：採用 NIO/Netty 事件驅動、虛擬線程、線程池複用，降低併發線程數。
32 位系統擴展地址空間：Windows boot.ini 加 /3GB /PAE 使用戶態達 3GB（需應用支援 Large Address Aware）。
遷移 64 位 JDK：徹底解決地址空間瓶頸，現代標準配置。

五、綜合診斷與調優流程

識別 OOM 類型：日誌關鍵字、堆轉儲檔分析
排查內存洩漏：MAT/JVisualVM 分析 heap dump，定位 GC Root 引用鏈
基線配置：-Xms -Xmx 同值，-XX:MaxMetaspaceSize 設上限，-Xss 按併發需求調整
啟用 GC 日誌：-Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags:filecount=5,filesize=20m (JDK 9+) 或舊版 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/logs/gc.log
壓測驗證：模擬生產流量觀察 GC 頻率、停頓、內存佔用曲線
持續監控：Prometheus + JMX Exporter + Grafana 看板預警

六、生產環境推薦基線模板（JDK 11+，4C8G 容器）

-Xms3g -Xmx3g \
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m \
-XX:+UseG1GC -XX:MaxGCPauseMillis=200 \
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/ \
-XX:+UseContainerSupport -XX:InitialRAMPercentage=75.0 -XX:MaxRAMPercentage=75.0 \
-Xss512k \
-Dfile.encoding=UTF-8 -Duser.timezone=Asia/Shanghai