內存出現故障 如何檢修

前沿拓展：

1、問題背景

我的博客網站https://blog.verysu.com，有興趣的可以訪問下。

最近服務器到期等因素，進行了遷移。租了其它的外國廠商，但是由于資費問題，購買了1.5G 內存的服務器（現）。因為原本用慣了4G內存的服務器（原），現在壓縮成這樣，似乎不太能支持我的使用，囧！

現在就來說下blog服務分配的內存情況：

原：4G 內存，分配給blog，1.5G。

現：1.5G內存，分配給blog，500M。

由于此次調整，原本以為資源需求壓力會更大。實際上應該不會，仔細想想，blog也沒多少內容的。那么根據此次調整之后，已經出現了2次OutOfMemoryError了。

由于JVM參數配置有加上XX:+HeapDumpOnOutOfMemoryError，所以出現OutOfMemoryError時會將堆棧輸出到指定的文件，這樣可以方便以后排查問題。

OS：CentOS7

Web容器：Tomcat 8

ORM：Hibernate3

數據庫：MySQL5

2、問題解決過程

2.1 診斷排查出現內存泄漏對象

這個文件占用了差不多535M，說明里面的對象占用空間很大。這里我使用了MAT工具來排查。

1）Histogram （可以查看每個類的實例（即對象）的數量和大?。?/p>

通過Histogram圖，我們初步看出，實際上跟我們自己的代碼好像是沒有關系，因為這里沒找到我們對應的包名和類名。不過可以看到一些疑惑就是Tomcat和mysql相關的類占用了很大內存。

2）Dominator Tree（列出Heap Dump中處于活躍狀態中的最大的幾個對象，默認按 retained size進行排序）

從這里可以更加明確是哪些對象占用了大部分資源了，似乎也是跟Tomcat和mysql有關。

3）Top Consumer（按類、類加載器和包分別進行查詢，并以餅圖的方式列出最大的幾個對象）

通過上面這個餅圖，我們更加明確的是哪些對象占用了大部分資源。其它一些視圖這里就不展開了。

小結：上面MAT的各種視圖表明，并不是說占用資源大的對象是就是內存泄漏的罪魁禍首，它這里只是做了個統計，方便你觀察和發現問題，只是提示你可能這些對象存在泄漏的可能性。

2.2 診斷排查占用大資源內因

由上面的圖中，我從TaskThread這個類入手：

發現主要占用的資源在StatefulPersistenceContext這個類，很明顯這個是Hibernate持久化相關的。

查看下類的注釋，大致意思是：

PersistenceContext表示Hibernate正在跟蹤的持久化“內容”的狀態。這包括持久實體、集合以及生成的代理。

SessionImpl和PersistentContext之間應該是一對一的對應關系。SessionImpl使用PersistentContext來跟蹤其上下文的當前狀態。事件監聽器使用PersistentContext來執行處理。

因為Hibernate的一級緩存就是在Session層面上，所以StatefulPersistenceContext跟一級緩存有關系，網上有些資料也有說StatefulPersistenceContext存在問題可能造成內存泄漏等原因。

可以在使用完Session時進行clear清除。這樣就能防止占用過大資源，但是，使用一級緩存是能夠大大的增強性能，如果這么做的話，似乎有違背Hibernate的設計初衷，因此，這里我們不能采取這種做法。

繼續往下挖，看這里面存放的是具體什么對象吧！

從這里可以看出，持久化的主要對象實體是ShareArticle，并且有1706個實體之多！~，這里只是TaskThread這個線程所持有這么多的實體，要知道下面還有幾個大對象TaskThread，里面也是有包含這些的，所以不僅僅1千個多實體。

2.3 找出問題根源（“真兇”）

看到這個實體的每個字段，才知道問題出現在哪！這張表有一個content字段，類型是mediumtext，存放文章內容。所以一旦加載到內存里，自然的需要占用大部分資源了。

找到問題的點在哪了，接下來就得看怎么優化，畢竟在資源急缺的我，需要優化下當前的服務了。

2.4 解決問題，優化！優化！

2.4.1 優化之一：查詢不返回content字段

特別是哪些查詢列表相關的。這能大大的減少占用內存。因為有些查詢List結果實際上是沒有使用到content字段，再次查詢出來也是一種浪費。

說下這個過程吧，由于使用的是Hibernate，雖說有其優點，但是使用起來極其不靈活！在公司用慣了Mybatis，才知道Mybatis的好，哈哈！

2.4.2 優化之二：只查詢需要的字段

在查詢當前文章的上下文時，基本上也是不用用到content字段，這里只需要返回id和title，即可。其實跟上面2.4.1的類似。

2.4.3 優化之三：延遲加載指定字段

我們知道，Hibernate在一對多、多對多等關系中，是支持延遲加載的。查資料發現Hibernate3也能支持指定字段進行延遲加載，在需要的時候再次去查詢數據庫指定的字段再返回。

所以就動手干！但是也遇到使用時出現不生效，資料表明需要再次使用字節碼進行增強才能正常使用。具體操作可以看下下面這篇文字：https://blog.verysu.com/article/414

小結：經過上面的優化，服務再也不會出現OutOfMemeryError了，而且資源占用也大幅度降低。

3、總結（經驗與優化）

1）針對占用資源多的，是否能夠不存在數據庫，比如生成靜態HTML文件，訪問的時候直接包含在頁面直接返回，這樣能快速返回，占用內存少，提升性能。

2）針對大字段（占用資源大），沒用到時不返回。

3）只返回需要的字段，在SQL優化的上必有，這樣也能提升mysql的吞吐量，也不會浪費資源。

4）如果追求靈活性，ORM建議使用mybatis，畢竟互聯網公司基本用它。Hibernate更適合在企業系統里面使用。

5）如果已經使用了Hibernate了，可以增加字段延遲加載機制，進而在需要的時候再去查詢。

好了，為了寫這篇文章，花了兩個多小時，覺得不錯的話，點個贊唄^_^！

推薦工具1：

MAT：Eclipse Memory Analyzer 下載地址：

http://www.eclipse.org/mat/

推薦工具2：

IBM HeapAnalyzer 下載地址：

https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=4544bafec7a2455f9d43eb866ea60091

參考資料：

Java程序內存分析：使用mat工具分析內存占用

https://www.cnblogs.com/AloneSword/p/3821569.html

Shallow Heap 和 Retained Heap的區別

https://blog.csdn.net/a740169405/article/details/53610689

Shallow heap & Retained heap

https://www.jianshu.com/p/0deac3af0f45

Java堆：Shallow Size和Retained Size

https://blog.csdn.net/iteye_18480/article/details/82514130

Hibernate 一級緩存導致某保險公司核心系統Weblogic中間件內存溢出的故障診斷https://blog.csdn.net/zhouleiblog/article/details/82834331

Hibernate 一級緩存的陷阱

https://www.cnblogs.com/hyl8218/p/5076338.html

PS：如果上面的鏈接點擊不了，可以點擊閱讀原文進行查看。

歡迎關注Wx公眾hao：搬運工來架構。更多干貨等你來~

拓展知識：