已完本玄幻小说排行榜,手机推荐排行榜,盗墓笔记txt全集下载

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

如果線上遇到了OOM，該如何解決？

OOM 意味著程序存在著漏洞，可能是代碼或者 JVM 參數(shù)配置引起的。這篇文章和讀者聊聊，Java 進程觸發(fā)了 OOM 后如何排查？

成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供沈陽企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站建設(shè)、成都網(wǎng)站制作、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為沈陽眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站建設(shè)公司優(yōu)惠進行中。

常說對生產(chǎn)環(huán)境保持敬畏之心，快速解決問題也是一種敬畏的表現(xiàn)。

為什么會 OOM

OOM全稱 “Out Of Memory”，表示內(nèi)存耗盡。當(dāng) JVM 因為沒有足夠的內(nèi)存來為對象分配空間，并且垃圾回收器也已經(jīng)沒有空間可回收時，就會拋出這個錯誤。

為什么會出現(xiàn) OOM，一般由這些問題引起。

分配過少：JVM 初始化內(nèi)存小，業(yè)務(wù)使用了大量內(nèi)存;或者不同 JVM 區(qū)域分配內(nèi)存不合理
代碼漏洞：某一個對象被頻繁申請，不用了之后卻沒有被釋放，導(dǎo)致內(nèi)存耗盡
內(nèi)存泄漏：申請使用完的內(nèi)存沒有釋放，導(dǎo)致虛擬機不能再次使用該內(nèi)存，此時這段內(nèi)存就泄露了。因為申請者不用了，而又不能被虛擬機分配給別人用
內(nèi)存溢出：申請的內(nèi)存超出了 JVM 能提供的內(nèi)存大小，此時稱之為溢出

內(nèi)存泄漏持續(xù)存在，最后一定會溢出，兩者是因果關(guān)系

常見的 OOM

比較常見的 OOM 類型有以下幾種：

java.lang.OutOfMemoryError: PermGen space

Java7 永久代(方法區(qū))溢出，它用于存儲已被虛擬機加載的類信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼等數(shù)據(jù)。每當(dāng)一個類初次加載的時候，元數(shù)據(jù)都會存放到永久代

一般出現(xiàn)于大量 Class 對象或者 JSP 頁面，或者采用 CgLib 動態(tài)代理技術(shù)導(dǎo)致

我們可以通過 -XX：PermSize 和 -XX：MaxPermSize 修改方法區(qū)大小

Java8 將永久代變更為元空間，報錯：java.lang.OutOfMemoryError: Metadata space，元空間內(nèi)存不足默認(rèn)進行動態(tài)擴展

java.lang.StackOverflowError

虛擬機棧溢出，一般是由于程序中存在死循環(huán)或者深度遞歸調(diào)用造成的。如果棧大小設(shè)置過小也會出現(xiàn)溢出，可以通過 -Xss 設(shè)置棧的大小

虛擬機拋出棧溢出錯誤，可以在日志中定位到錯誤的類、方法

java.lang.OutOfMemoryError: Java heap space

Java 堆內(nèi)存溢出，溢出的原因一般由于 JVM 堆內(nèi)存設(shè)置不合理或者內(nèi)存泄漏導(dǎo)致

如果是內(nèi)存泄漏，可以通過工具查看泄漏對象到 GC Roots 的引用鏈。掌握了泄漏對象的類型信息以及 GC Roots 引用鏈信息，就可以精準(zhǔn)地定位出泄漏代碼的位置

如果不存在內(nèi)存泄漏，就是內(nèi)存中的對象確實都還必須存活著，那就應(yīng)該檢查虛擬機的堆參數(shù)(-Xmx 與 -Xms)，查看是否可以將虛擬機的內(nèi)存調(diào)大些

小結(jié)：方法區(qū)和虛擬機棧的溢出場景不在本篇過多討論，下面主要講解常見的 Java 堆空間的 OOM 排查思路

查看 JVM 內(nèi)存分布

假設(shè)我們 Java 應(yīng)用 PID 為 15162，輸入命令查看 JVM 內(nèi)存分布 jmap -heap 15162

 
 
 
   
  
  
  [xxx@xxx ~]# jmap -heap 15162   
  
  
  Attaching to process ID 15162, please wait...   
  
  
  Debugger attached successfully.   
  
  
  Server compiler detected.   
  
  
  JVM version is 25.161-b12   
  
  
     
  
  
  using thread-local object allocation.   
  
  
  Mark Sweep Compact GC   
  
  
     
  
  
  Heap Configuration:   
  
  
     MinHeapFreeRatio         = 40 # 最小堆使用比例   
  
  
     MaxHeapFreeRatio         = 70 # 最大堆可用比例   
  
  
     MaxHeapSize              = 482344960 (460.0MB) # 最大堆空間大小   
  
  
     NewSize                  = 10485760 (10.0MB) # 新生代分配大小   
  
  
     MaxNewSize               = 160759808 (153.3125MB) # 最大新生代可分配大小   
  
  
     OldSize                  = 20971520 (20.0MB) # 老年代大小   
  
  
     NewRatio                 = 2 # 新生代比例   
  
  
     SurvivorRatio            = 8 # 新生代與 Survivor 比例   
  
  
     MetaspaceSize            = 21807104 (20.796875MB) # 元空間大小   
  
  
     CompressedClassSpaceSize = 1073741824 (1024.0MB) # Compressed Class Space 空間大小限制   
  
  
     MaxMetaspaceSize         = 17592186044415 MB # 最大元空間大小   
  
  
     G1HeapRegionSize         = 0 (0.0MB) # G1 單個 Region 大小   
  
  
     
  
  
  Heap Usage:  # 堆使用情況   
  
  
  New Generation (Eden + 1 Survivor Space): # 新生代   
  
  
     capacity = 9502720 (9.0625MB) # 新生代總?cè)萘?nbsp;  
  
  
     used     = 4995320 (4.763908386230469MB) # 新生代已使用   
  
  
     free     = 4507400 (4.298591613769531MB) # 新生代剩余容量   
  
  
     52.56726495150862% used # 新生代使用占比   
  
  
  Eden Space:     
  
  
     capacity = 8454144 (8.0625MB) # Eden 區(qū)總?cè)萘?nbsp;  
  
  
     used     = 4029752 (3.8430709838867188MB) # Eden 區(qū)已使用   
  
  
     free     = 4424392 (4.219429016113281MB) # Eden 區(qū)剩余容量   
  
  
     47.665996699370154% used  # Eden 區(qū)使用占比   
  
  
  From Space: # 其中一個 Survivor 區(qū)的內(nèi)存分布   
  
  
     capacity = 1048576 (1.0MB)   
  
  
     used     = 965568 (0.92083740234375MB)   
  
  
     free     = 83008 (0.07916259765625MB)   
  
  
     92.083740234375% used   
  
  
  To Space: # 另一個 Survivor 區(qū)的內(nèi)存分布   
  
  
     capacity = 1048576 (1.0MB)   
  
  
     used     = 0 (0.0MB)   
  
  
     free     = 1048576 (1.0MB)   
  
  
     0.0% used   
  
  
  tenured generation: # 老年代   
  
  
     capacity = 20971520 (20.0MB)   
  
  
     used     = 10611384 (10.119804382324219MB)   
  
  
     free     = 10360136 (9.880195617675781MB)   
  
  
     50.599021911621094% used   
  
  
     
  
  
  10730 interned Strings occupying 906232 bytes.

通過查看 JVM 內(nèi)存分配以及運行時使用情況，可以判斷內(nèi)存分配是否合理

另外，可以在 JVM 運行時查看最耗費資源的對象，jmap -histo:live 15162 | more

JVM 內(nèi)存對象列表按照對象所占內(nèi)存大小排序

instances：實例數(shù)
bytes：單位 byte
class name：類名

明顯看到 CustomObjTest 對象實例以及占用內(nèi)存過多

可惜的是，方案存在局限性，因為它只能排查對象占用內(nèi)存過高問題

其中 "[" 代表數(shù)組，例如 "[C" 代表 Char 數(shù)組，"[B" 代表 Byte 數(shù)組。如果數(shù)組內(nèi)存占用過多，我們不知道哪些對象持有它，所以就需要 Dump 內(nèi)存進行離線分析

jmap -histo:live 執(zhí)行此命令，JVM 會先觸發(fā) GC，再統(tǒng)計信息

Dump 文件分析

Dump 文件是 Java 進程的內(nèi)存鏡像，其中主要包括系統(tǒng)信息、虛擬機屬性、完整的線程 Dump、所有類和對象的狀態(tài) 等信息

當(dāng)程序發(fā)生內(nèi)存溢出或 GC 異常情況時，懷疑 JVM 發(fā)生了內(nèi)存泄漏，這時我們就可以導(dǎo)出 Dump 文件分析

JVM 啟動參數(shù)配置添加以下參數(shù)

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./(參數(shù)為 Dump 文件生成路徑)

當(dāng) JVM 發(fā)生 OOM 異常自動導(dǎo)出 Dump 文件，文件名稱默認(rèn)格式：java_pid{pid}.hprof

上面配置是在應(yīng)用拋出 OOM 后自動導(dǎo)出 Dump，或者可以在 JVM 運行時導(dǎo)出 Dump 文件

 
 
 
   
  
  
  jmap -dump:file=[文件路徑] [pid]   
  
  
     
  
  
  # 示例   
  
  
  jmap -dump:file=./jvmdump.hprof 15162

在本地寫一個測試代碼，驗證下 OOM 以及分析 Dump 文件

 
 
 
   
  
  
  設(shè)置 VM 參數(shù)：-Xms3m -Xmx3m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./   
  
  
     
  
  
  public static void main(String[] args) {   
  
  
      List

新聞中心

為什么會 OOM

常見的 OOM

查看 JVM 內(nèi)存分布

Dump 文件分析

JvisualVM 分析

總結(jié)回顧

其他資訊