線上java.lang.OutOfMemoryError問題定位三板斧

everfight 發布于2019-08-15 17:51 / 1541人閱讀

摘要：如果發現某類對象占用內存很大例如幾個，很可能是類對象創建太多，且一直未釋放。

OOM(OutOfMemoryError) 問題歸根結底三點原因：

本身資源不夠

申請的內存太多

資源耗盡

解決思路，換成Java服務分析，三個原因也可以解讀為：

有可能是內存分配確實過小，而正常業務使用了大量內存

某一個對象被頻繁申請，卻沒有釋放，內存不斷泄漏，導致內存耗盡

某一個資源被頻繁申請，系統資源耗盡，例如：不斷創建線程，不斷發起網絡連接

因此，針對解決思路，快速定位OOM問題的三板斧是：

確認是不是內存本身就分配過小

找到最耗內存的對象

確認是否是資源耗盡

以正式線上的tomcat為例，tomcat運行5個ssm架構的java項目，啟動時需要60秒左右，運行一段時間偶爾會有OOM出現，現在逐一排查：

(1) 確認是不是內存本身就分配過小

在服務器（8核16G）上輸入 top 查看 java啟動時內存變化情況，順便找到java的進程ID : 10397

然后，輸入：jmap -heap 10397，觀察堆、新生代、老年代的內存使用情況，發現大概都用了一半，可以確定，不是內存分配過小問題。

wen@S189919:/opt/tomcat8$ jmap -heap 1246
Attaching to process ID 1246, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.65-b04

using thread-local object allocation.
Parallel GC with 8 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 0
   MaxHeapFreeRatio = 100
   MaxHeapSize      = 4208984064 (4014.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 21757952 (20.75MB)
   MaxPermSize      = 85983232 (82.0MB)
   G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 1172307968 (1118.0MB)
   used     = 679248008 (647.781379699707MB)
   free     = 493059960 (470.21862030029297MB)
   57.94108941857845% used
From Space:
   capacity = 85983232 (82.0MB)
   used     = 0 (0.0MB)
   free     = 85983232 (82.0MB)
   0.0% used
To Space:
   capacity = 115343360 (110.0MB)
   used     = 0 (0.0MB)
   free     = 115343360 (110.0MB)
   0.0% used
PS Old Generation
   capacity = 259522560 (247.5MB)
   used     = 147065016 (140.25212860107422MB)
   free     = 112457544 (107.24787139892578MB)
   56.667526707504734% used
PS Perm Generation
   capacity = 63963136 (61.0MB)
   used     = 32219528 (30.72693634033203MB)
   free     = 31743608 (30.27306365966797MB)
   50.37202678742956% used

16612 interned Strings occupying 2080416 bytes.

(2) 找到最耗內存的對象

jmap -histo:live 1246| more

輸入命令后，會以表格的形式顯示存活對象的信息，并按照所占內存大小排序：

實例數

所占內存大小

類名

通過觀察，雖然我不知道 [B 是什么類，但是最大也只有72M，對內存來說簡直沒有知覺。

如果發現某類對象占用內存很大（例如幾個G），很可能是類對象創建太多，且一直未釋放。例如：

申請完資源后，未調用close()或dispose()釋放資源

消費者消費速度慢（或停止消費了），而生產者不斷往隊列中投遞任務，導致隊列中任務累積過多

wen@S189919:/opt/tomcat8$ jmap -histo:live 1246 | more

 num     #instances         #bytes  class name
----------------------------------------------
   1:         79073       72095344  [B
   2:        103049       13630576  [C
   3:         57516        8155328  
   4:         57516        7373456  
   5:          5413        6128216  
   6:          5413        3861128  
   7:          4455        3264960  
   8:        101128        2427072  java.lang.String
   9:         46704        1868160  java.lang.ref.Finalizer
  10:          5314        1486584  [Ljava.util.HashMap$Entry;
  11:         22264        1419160  [Ljava.lang.Object;
  12:         17286        1382880  java.lang.reflect.Method
  13:         20810        1165360  java.util.zip.ZipFile$ZipFileInputStream
  14:         20389        1141784  java.util.zip.ZipFile$ZipFileInflaterInputStream
  15:         34592        1106944  java.util.HashMap$Entry
  16:          1963        1075048  
  17:          1762         943992  [I
  18:         22136         708352  java.util.concurrent.ConcurrentHashMap$HashEntry
  19:          5866         704008  java.lang.Class
  20:         14549         581960  java.util.LinkedHashMap$Entry
  21:         21158         507792  java.util.ArrayList
  22:          7742         453448  [S
  23:          8839         450464  [[I
  24:          7362         412272  java.util.LinkedHashMap
  25:          3735         328416  [Ljava.util.concurrent.ConcurrentHashMap$HashEntry;
  26:         14544         322536  [Ljava.lang.Class;
  27:          7350         294000  com.sun.org.apache.xerces.internal.dom.DeferredTextImpl
  28:          2973         273488  [Ljava.util.WeakHashMap$Entry;
  29:          6660         266400  com.sun.org.apache.xerces.internal.dom.DeferredAttrImpl
  30:          5394         258912  java.util.HashMap
  31:          6441         257640  javax.servlet.jsp.tagext.TagAttributeInfo
  32:           436         237184  
  33:         14200         227200  java.lang.Object
  34:          2783         222640  sun.net.www.protocol.jar.URLJarFile
  35:          3914         219184  com.sun.org.apache.xerces.internal.dom.DeferredElementImpl
  36:          6016         192512  java.util.concurrent.locks.ReentrantLock$NonfairSync
  37:          4328         173120  java.lang.ref.SoftReference
  38:          2970         166320  java.util.WeakHashMap
  39:          3200         153184  [Ljava.lang.String;
  40:          3735         149400  java.util.concurrent.ConcurrentHashMap$Segment

(3) 確認是否是資源耗盡

通過查看 sshd 進程，得出句柄詳情和線程數

/proc/${PID}/fd

/proc/${PID}/task

最終的結果句柄數和線程數8和4，更不可能引發內存溢出

root@S189919:/home/wen# ps -aux | grep sshd
Warning: bad ps syntax, perhaps a bogus "-"? See http://procps.sf.net/faq.html
root       749  0.0  0.0  50036  2928 ?        Ss   19:01   0:00 /usr/sbin/sshd -D
root      1321  0.0  0.0  73440  3608 ?        Ss   19:15   0:00 sshd: wen [priv]
wen       1464  0.0  0.0  73440  1528 ?        S    19:15   0:00 sshd: wen@pts/0
root      1585  0.0  0.0   9388   940 pts/0    S+   19:20   0:00 grep --color=auto sshd
root@S189919:/home/wen# ll /proc/749/fd
total 0
dr-x------ 2 root root  0 Sep  4 19:01 ./
dr-xr-xr-x 8 root root  0 Sep  4 19:01 ../
lrwx------ 1 root root 64 Sep  4 19:01 0 -> /dev/null
lrwx------ 1 root root 64 Sep  4 19:01 1 -> /dev/null
lrwx------ 1 root root 64 Sep  4 19:01 2 -> /dev/null
lr-x------ 1 root root 64 Sep  4 19:01 3 -> socket:[7330]
lrwx------ 1 root root 64 Sep  4 19:21 4 -> socket:[7332]
root@S189919:/home/wen# ll /proc/749/task
total 0
dr-xr-xr-x 3 root root 0 Sep  4 19:21 ./
dr-xr-xr-x 8 root root 0 Sep  4 19:01 ../
dr-xr-xr-x 6 root root 0 Sep  4 19:21 749/
root@S189919:/home/wen# ll /proc/749/fd | wc -l
8
root@S189919:/home/wen# ll /proc/749/task | wc -l

(4) 合并相同的 jar 包

最后，想來想去，很有可能是項目啟動時加載太多第三方jar包，于是，將5個ssm的jar包合并，覆蓋掉相同的，放在tomcat的shared lib目錄：
修改 ${ TOMCAT_HOME }/conf/catalina.properties文件中shared.loader= ${catalina.base}/shared/lib,${catalina.base}/shared/lib/*.jar 也可以將公用的jar全部放置${ TOMCAT_HOME }/lib包下
1
啟動tomcat，加載完用了37秒，但愿能解決OOM問題，從此不再被領導說。

GPU云服務器云服務器消息隊列線上問題定位問題云服務器問題定位三板斧

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/69485.html

系統優化怎么做-Tomcat優化

摘要：運行模式分種模式一般使用模式效率低對系統配置有一些比較高的要求確認的運行模式配置文件關鍵配置最大線程數默認是最小活躍線程數默認是最大的等待隊列個數，超過則請求拒絕默認值是，一般不改變。前言 Tomcat作為Web應用的服務器，目前絕大多數公司都是用其作為應用服務器的，應用服務器的執行效率會影響系統執行，這里會講Tomcat怎樣進行配置能提高處理性能。另外必須提到對應的JVM參數的優化...

gghyoo 2019-08-19 10:54 評論0 收藏0
【修煉內功】[JVM] 淺談虛擬機內存模型

摘要：也正是因此，一旦出現內存泄漏或溢出問題，如果不了解的內存管理原理，那么將會對問題的排查帶來極大的困難。本文已收錄【修煉內功】躍遷之路 showImg(https://segmentfault.com/img/bVbsP9I?w=1024&h=580); 不論做技術還是做業務，對于Java開發人員來講，理解JVM各種原理的重要性不必再多言對于C/C++而言，可以輕易地操作任意地址的...

sanyang 2019-08-16 17:30 評論0 收藏0
記JVM堆外內存泄漏Bug查找

摘要：服務本身是一個，開起的線程數為，再加上一些其他線程，總的線程數不會超過服務內自己沒有顯示創建線程或者使用線程池。問題解決找到所在后，結局方案很簡單，只需將的通過單例的方式注入到服務中，即可解決堆外內存泄漏的問題。內存泄漏Bug現場一個做BI數據展示的服務在一個晚上重啟了5次，由于是通過k8s容器編排，服務掛了以后會自動重啟，所以服務還能繼續提供服務。第一時間先上日志系統查看錯誤日...

hiYoHoo 2019-08-19 11:18 評論0 收藏0
論JVM爆炸的幾種姿勢及自救方法

摘要：方法區溢出在的方法區中，它主要存放了類的信息，常量，靜態變量等。運行結果簡單解決思路一般來說此類問題多出現在存在遞歸的地方，要從代碼里重新審視遞歸未結束的原因，若遞歸的方法沒問題可以根據實際情況調整參數的大小。前言如今不管是在面試還是在我們的工作中，OOM總是不斷的出現在我們的視野中，所以我們有必要去了解一下導致OOM的原因以及一些基本的調整方法，大家可以通過下面的事例來了解一下什...

hyuan 2019-08-19 11:35 評論0 收藏0