本文將為您提供一個教程，使您可以確定活動應(yīng)用程序Java線程保留Java堆空間的數(shù)量和位置。 將提供來自O(shè)racle Weblogic 10.0生產(chǎn)環(huán)境的真實案例研究，以使您更好地理解分析過程。

我們還將嘗試證明過多的垃圾回收或Java堆空間的內(nèi)存占用問題通常不是由真正的內(nèi)存泄漏引起的，而是由線程執(zhí)行模式和大量的短期對象引起的。

背景

您可能從我過去的JVM概述文章中看到，Java線程是JVM基礎(chǔ)的一部分。 您的Java堆空間內(nèi)存占用量不僅受靜態(tài)對象和壽命長的對象的驅(qū)動，還受壽命短的對象的驅(qū)動。

通常會錯誤地認為OutOfMemoryError問題是由于內(nèi)存泄漏引起的。 我們經(jīng)常忽略錯誤的線程執(zhí)行模式和它們在Java堆上“保留”到執(zhí)行完成的短暫對象。 在這種有問題的情況下：

• 您的“預(yù)期”應(yīng)用程序的短期/無狀態(tài)對象（XML，JSON數(shù)據(jù)有效載荷等）被線程保留的時間過長（線程鎖爭用，巨大的數(shù)據(jù)有效載荷，來自遠程系統(tǒng)的響應(yīng)時間慢等）。
• 最終，這樣的短期對象被垃圾收集器提升為長期對象空間，例如OldGen / tenured空間
• 副作用是，這導(dǎo)致OldGen空間快速填充，從而增加了Full GC（主要集合）的頻率
• 根據(jù)情況的嚴重性，這可能導(dǎo)致過度的GC垃圾收集，JVM暫停時間增加，并最終導(dǎo)致OutOfMemoryError：Java堆空間
• 您的應(yīng)用程序現(xiàn)在關(guān)閉，您現(xiàn)在對正在發(fā)生的事情感到困惑
• 最后，您正在考慮增加Java堆或?qū)ふ覂?nèi)存泄漏……您是否真的走對了？

在上述情況下，您需要查看線程執(zhí)行模式，并確定它們在給定時間保留多少內(nèi)存。

好了，我得到了圖片，但是線程堆棧的大小呢？

避免線程堆棧大小和Java內(nèi)存保留之間的混淆是非常重要的。 線程堆棧大小是JVM用于存儲每個方法調(diào)用的特殊內(nèi)存空間。 當線程調(diào)用方法A時，它將調(diào)用“推”到堆棧上。 如果方法A調(diào)用方法B，它也會被壓入堆棧。 一旦方法執(zhí)行完成，調(diào)用便從堆棧中“彈出”。

由于此類線程方法調(diào)用而創(chuàng)建的Java對象在Java堆空間上分配。 絕對增加線程堆棧大小不會有任何效果。 處理java.lang.stackoverflowerror或OutOfMemoryError：無法創(chuàng)建新的本機線程問題時，通常需要調(diào)整線程堆棧的大小。

案例研究和問題背景

以下分析基于我們最近調(diào)查的真實生產(chǎn)問題。

• 在用戶Web界面進行了一些更改（使用Google Web Toolkit和JSON作為數(shù)據(jù)有效負載）之后，從Weblogic 10.0生產(chǎn)環(huán)境中觀察到嚴重的性能下降。
• 初步分析確實揭示了OutOfMemoryError的幾種情況：Java堆空間錯誤以及過多的垃圾回收。 在發(fā)生OOM事件后，會自動生成Java堆轉(zhuǎn)儲文件（-XX：+ HeapDumpOnOutOfMemoryError）
• 對詳細：gc日志的分析確實確認了32位HotSpot JVM OldGen空間（1 GB容量）的完全耗盡
• 在問題發(fā)生之前和過程中也生成了線程轉(zhuǎn)儲快照
• 當時唯一可以解決的問題是觀察到問題時重新啟動受影響的Weblogic服務(wù)器
• 最終對變更進行了回滾，這確實解決了這種情況

團隊首先從引入的新代碼中懷疑了內(nèi)存泄漏問題。

線程轉(zhuǎn)儲分析：尋找可疑對象…

我們所做的第一步是對生成的線程轉(zhuǎn)儲數(shù)據(jù)進行分析。 線程轉(zhuǎn)儲通常會向您顯示在Java堆上分配內(nèi)存的罪魁禍首線程。 它還將揭示試圖從遠程系統(tǒng)發(fā)送和接收數(shù)據(jù)有效載荷的任何占用線程或阻塞線程。

我們注意到的第一個模式是從Weblogic托管服務(wù)器（JVM進程）觀察到的OOM事件和STUCK線程之間具有良好的相關(guān)性。 在找到的主線程模式下面找到：

<10-Dec-2012 1:27:59 o'clock PM EST> <Error> <BEA-000337><[STUCK] ExecuteThread: '22' for queue:'weblogic.kernel.Default (self-tuning)'has been busy for '672' seconds working on the requestwhich is more than the configured time of '600' seconds.

如您所見，以上線程似乎是STUCK或花費很長時間讀取和接收來自遠程服務(wù)器的JSON響應(yīng)。 一旦找到該模式，下一步就是將該發(fā)現(xiàn)與JVM堆轉(zhuǎn)儲分析相關(guān)聯(lián)，并確定這些卡住的線程從Java堆中占用了多少內(nèi)存。

堆轉(zhuǎn)儲分析：保留的對象暴露在外！

Java堆轉(zhuǎn)儲分析是使用MAT執(zhí)行的。 現(xiàn)在，我們將列出不同的分析步驟，這些步驟確實使我們可以查明保留的內(nèi)存大小和源。

1.加載HotSpot JVM堆轉(zhuǎn)儲

2.選擇HISTOGRAM視圖并按“ ExecuteThread”進行過濾

* ExecuteThread是Weblogic內(nèi)核用于線程創(chuàng)建和執(zhí)行的Java類*

如您所見，這種觀點非常明顯。 我們可以看到總共創(chuàng)建了210個Weblogic線程。 這些線程保留的內(nèi)存總量為806 MB。 這對于具有1 GB OldGen空間的32位JVM進程而言非常重要。 僅此觀點就告訴我們問題的核心和內(nèi)存保留源于線程本身。

3.深入研究線程內(nèi)存占用量分析

下一步是深入研究線程內(nèi)存保留。 為此，只需右鍵單擊ExecuteThread類，然后選擇：列表對象>帶有傳出引用。

如您所見，我們能夠?qū)⒕€程轉(zhuǎn)儲分析中的STUCK線程與堆轉(zhuǎn)儲分析中的高內(nèi)存保留量相關(guān)聯(lián)。 這個發(fā)現(xiàn)非常令人驚訝。

4.線程Java局部變量識別

最后的分析步驟確實需要我們擴展一些線程示例并了解內(nèi)存保留的主要來源。

如您所見，這最后一個分析步驟確實從根本原因上揭示了巨大的JSON響應(yīng)數(shù)據(jù)有效載荷。 該模式還通過線程轉(zhuǎn)儲分析在早期公開，我們發(fā)現(xiàn)一些線程需要很長時間才能讀取和接收JSON響應(yīng)。 數(shù)據(jù)有效負載占用量巨大的明顯癥狀。

至關(guān)重要的是要注意，通過局部方法變量創(chuàng)建的短期對象將顯示在堆轉(zhuǎn)儲分析中。 但是，其中一些將僅在其父線程中可見，因為這種情況下其他對象未引用它們。 您還需要分析線程堆棧跟蹤以識別真正的調(diào)用者，然后進行代碼檢查以確認根本原因。

根據(jù)這一發(fā)現(xiàn)，在某些情況下，我們的交付團隊能夠確定最近的JSON錯誤代碼更改正在生成高達45 MB +的巨大JSON數(shù)據(jù)有效負載。 考慮到該環(huán)境使用的是只有1 GB OldGen空間的32位JVM，您可以理解，只有幾個線程足以觸發(fā)嚴重的性能下降。

該案例研究清楚地表明了適當?shù)娜萘恳?guī)劃和Java堆分析的重要性，包括從活動應(yīng)用程序和Java EE容器線程中保留的內(nèi)存。

其他一切都只是信息

我希望本文能幫助您了解如何通過結(jié)合線程轉(zhuǎn)儲和堆轉(zhuǎn)儲分析來確定活動線程保留的Java堆內(nèi)存占用量。 現(xiàn)在，如果您不嘗試的話，本文將僅停留在文字上，因此，我強烈建議您花一些時間自己學(xué)習(xí)針對您的應(yīng)用程序進行的分析過程。

參考： Java Thread：保留了我們的JCG合作伙伴 Pierre-Hugues Charbonneau在Java EE支持模式和Java教程博客上進行的內(nèi)存分析 。

翻譯自: https://www.javacodegeeks.com/2012/12/java-thread-retained-memory-analysis.html

總結(jié)

以上是生活随笔為你收集整理的Java线程：保留的内存分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。