java.lang.OutOfMemoryError: Java heap space 表示堆內(nèi)存不足，需檢查大對象處理、內(nèi)存洩漏及堆設(shè)置，通過堆轉(zhuǎn)儲分析工具定位並優(yōu)化代碼；2. Metaspace 錯誤因類元數(shù)據(jù)過多，常見於動態(tài)類生成或熱部署，應(yīng)限制MaxMetaspaceSize 並優(yōu)化類加載；3. Unable to create new native thread 因係統(tǒng)線程資源耗盡，需檢查線程數(shù)限制、使用線程池、調(diào)整棧大?。?. GC overhead limit exceeded 指GC 頻繁但回收少，應(yīng)分析GC 日誌，優(yōu)化對像生命週期，考慮更換G1GC 等回收器；5. Requested array size exceeds VM limit 由數(shù)組長度溢出引起，需校驗長度邏輯，避免整型溢出，採用流式處理大文件；總結(jié)：應(yīng)啟用堆轉(zhuǎn)儲與GC 日誌，結(jié)合分析工具排查，從代碼設(shè)計層面解決資源管理問題，而非僅調(diào)大內(nèi)存，才能根本解決OOM 問題。

Java OutOfMemoryError是運行時常見的嚴重錯誤，通常表明JVM 無法分配對象，因為堆內(nèi)存或其它內(nèi)存區(qū)域已耗盡。雖然錯誤信息看似簡單，但背後的原因多種多樣。以下是幾種常見的OutOfMemoryError場景及其排查與解決方法。

1. java.lang.OutOfMemoryError: Java heap space

這是最常見的類型，表示堆內(nèi)存不足以分配新對象。

常見原因：

• 應(yīng)用程序加載了大量數(shù)據(jù)（如大文件、緩存全量數(shù)據(jù)）。
• 存在內(nèi)存洩漏（如靜態(tài)集合不斷添加對象未清理）。
• 堆內(nèi)存設(shè)置過小，無法滿足正常業(yè)務(wù)需求。

排查步驟：

• 查看錯誤日誌：確認是否在處理大對像或批量數(shù)據(jù)時觸發(fā)。
• 使用JVM 參數(shù)監(jiān)控：

   -Xmx2g -Xms2g -XX: HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps

  這會在OOM 時生成堆轉(zhuǎn)儲文件（heap dump）。

  
• 分析堆轉(zhuǎn)儲：使用工具如Eclipse MAT或VisualVM打開.hprof文件，查找佔用內(nèi)存最多的對象及其引用鏈。
• 檢查代碼：重點關(guān)注：
  • 靜態(tài)Map 、 List是否無限增長。
  • 緩存是否缺少過期機制（建議使用WeakHashMap或Caffeine等帶淘汰策略的緩存）。
  • 是否一次性加載大文件或數(shù)據(jù)庫全表數(shù)據(jù)。

解決方案：

• 增加堆內(nèi)存（臨時方案）：

   -Xmx4g

• 修復(fù)內(nèi)存洩漏代碼。
• 分頁處理大數(shù)據(jù)，避免一次性加載。

2. java.lang.OutOfMemoryError: Metaspace

JDK 8 及以後，永久代（PermGen）被元空間（Metaspace）取代，用於存儲類的元數(shù)據(jù)。

常見原因：

• 應(yīng)用動態(tài)生成大量類（如使用CGLIB、ASM、動態(tài)代理、Groovy 腳本等）。
• 部署大量WAR 應(yīng)用（如Tomcat 熱部署未清理類加載器）。
• 元空間大小未限製或設(shè)置過小。

排查方法：

• 添加JVM 參數(shù)觀察Metaspace 使用情況：

   -XX:MaxMetaspaceSize=512m -verbose:gc -XX: PrintGCDetails

• 使用jstat -gc <pid>查看MCMN , MCMX , MC （Metaspace 容量）等指標。
• 生成並分析堆dump（雖然Metaspace 不在堆中，但可輔助判斷類加載情況）。

解決方案：

• 設(shè)置合理的MaxMetaspaceSize防止無限增長。
• 檢查是否有頻繁的類加載/卸載，尤其是熱部署場景。
• 使用-XX: UseG1GC和-XX:MetaspaceSize=256m優(yōu)化GC 行為。
• 避免過度使用運行時字節(jié)碼生成。

3. java.lang.OutOfMemoryError: Unable to create new native thread

JVM 試圖創(chuàng)建新線程，但操作系統(tǒng)無法分配native 線程資源。

常見原因：

• 線程數(shù)超過系統(tǒng)限制（ ulimit -u用戶進程數(shù)限制）。
• 系統(tǒng)內(nèi)存不足，每個線程默認佔用1MB 棧空間（ -Xss ）。
• 應(yīng)用創(chuàng)建了過多線程（如未使用線程池、線程洩漏）。

排查方法：

• 檢查當(dāng)前線程數(shù)：

   ps -eLf | grep java | wc -l

• 查看系統(tǒng)限制：

   ulimit -u # max user processes
  cat /proc/sys/kernel/threads-max

• 檢查JVM 線程dump：

   jstack <pid> > thread_dump.txt

  查看是否有大量相似線程或線程未結(jié)束。

解決方案：

• 使用線程池（如ThreadPoolExecutor ）替代手動創(chuàng)建線程。
• 調(diào)整線程棧大?。ㄖ斏鳎?pre class='brush:php;toolbar:false;'> -Xss256k # 減少每個線程棧內(nèi)存
• 提高系統(tǒng)限制（需管理員權(quán)限）：

   ulimit -u 65535

• 檢查是否有線程未正確關(guān)閉（如未調(diào)用executor.shutdown() ）。

4. java.lang.OutOfMemoryError: GC overhead limit exceeded

JVM 花費大量時間進行GC（超過98%），但回收內(nèi)存極少（少於2%），自動拋出此錯誤。

常見原因：

• 堆中存在大量“慢死”對象，GC 頻繁但效果差。
• 內(nèi)存不足或內(nèi)存洩漏導(dǎo)致可用空間緊張。

排查方法：

• 啟用GC 日誌：

   -Xlog:gc*,gc heap=debug:file=gc.log:time

• 分析日誌中GC 頻率與回收量。
• 結(jié)合堆dump 查看對象分佈。

解決方案：

• 增加堆內(nèi)存。
• 優(yōu)化對像生命週期，避免長期持有無用對象。
• 改用G1GC 或ZGC 等更高效的垃圾回收器：

   -XX: UseG1GC

• 檢查是否有大對象頻繁創(chuàng)建（如大字符串、大數(shù)組）。

5. java.lang.OutOfMemoryError: Requested array size exceeds VM limit

嘗試創(chuàng)建超過JVM 限制的數(shù)組（如new int[Integer.MAX_VALUE] ）。

常見原因：

• 計算數(shù)組大小時整型溢出，導(dǎo)致請求負數(shù)或極大值。
• 數(shù)據(jù)處理邏輯錯誤，誤將文件大小當(dāng)作數(shù)組長度。

示例：

 int size = (int) file.length(); // 文件大於2GB 時，強轉(zhuǎn)為負數(shù)byte[] data = new byte[size]; // 可能觸發(fā)OOM

解決方案：

• 使用long判斷數(shù)據(jù)大小，限制最大分配。
• 使用流式處理大文件，避免一次性加載。
• 檢查數(shù)組長度計算邏輯，防止溢出。

總結(jié)建議

遇到OutOfMemoryError時，不要只調(diào)大內(nèi)存了事。關(guān)鍵步驟包括：

• ? 啟用-XX: HeapDumpOnOutOfMemoryError
• ? 添加GC 日誌和線程dump 能力
• ? 使用分析工具（MAT、VisualVM、jstat、jstack）
• ? 審查代碼中的集合、緩存、線程、IO 處理邏輯

大多數(shù)OOM 問題本質(zhì)是代碼設(shè)計或資源管理不當(dāng)，合理配置精細排查才能根治。

基本上就這些，不復(fù)雜但容易忽略細節(jié)。

以上是故障排除常見的java`ofmemoryError`場景''的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！