通過AppDynamics解決應用程序問題的速度提高了10倍–以最小的開銷在代碼級深度監視生產應用程序。 開始免費試用！

內存，內存，內存...

內存是Java的關鍵部分，尤其是內存管理。 作為開發人員，內存管理不是您要定期執行的操作，也不是您要手動執行的操作。 Java的一大優點是它能夠為您處理內存模型。 當不使用對象時，Java會通過清理來幫助您。

但這也是問題開始的地方。 使用Java，也許您的應用程序不再使用對象，但是如果您不告訴虛擬機您不再使用它，則它不會清除它。 這是內存泄漏 。 我們都看過他們。 對象開始在您的堆中累積，您的應用程序停止運行。

內存泄漏通常是由于編程不當而導致的-通常是在開發人員未釋放對對象的所有引用的情況下。 如您所知，Java中的類似對象被放到集合或映射中，因此如果您不從集合中刪除特定的數據集，問題就會變得更加復雜。 收集的東西越多，您損失的空間就越大。

當Java為您管理內存模型，或者創建/銷毀未使用的對象時，它將它們放入堆中。 該堆始終具有一定的大小，并具有最大可用空間。 如果內存管理不善，堆的空間將用完。 集合加起來，然后JVM崩潰。

診斷泄漏

傳統上，有兩種主要的內存泄漏診斷方法：堆轉儲和分析器。

第一個是堆轉儲，基本上可以讓您查看哪個對象持有對集合的引用。 它可以使您對導致問題的對象有一個很好的了解，但它不會告訴您誰在訪問集合，而誰沒有訪問集合。 它告訴您集合的位置，但不告訴您使用它的人的特征。 堆轉儲通常也非常大，以GB為單位，并且大堆轉儲很繁瑣。 分析和打開堆轉儲，然后閱讀并確定問題，需要大量資源。

第二種方法是堆轉儲和探查器的組合，可以使您更接近一點，但不多。 內存探查器會嘗試幫助您分析堆轉儲。 他們擁有實時數據，現在您知道是誰在創建對象，但是您仍然沒有真正導致泄漏的原因。

假設我有一個雇員對象。 員工對象被放入集合中，探查器將告訴您創建它的人。 探查器沒有告訴您的是誰將其放入集合中以及從集合中將其刪除。 探查器告訴您對象的誕生，而不是泄漏的原因。 無論如何，這可以幫助您縮小范圍，但是您需要應用程序的扎實知識才能使探查器真正地幫助您確定原因，然后仍然需要大量時間和資源來查找泄漏。

我們從很多人那里聽到了。 許多公司嘗試使用這些工具，但是每隔幾天他們的應用就會崩潰。 那他們怎么辦？ 他們重新啟動JVM或CLR。 他們的應用再次崩潰，然后重新啟動。 應用程序管理是一場噩夢，因為他們無法找到或修復其內存泄漏。

堆轉儲和事件探查器都可以在開發和預生產中提供幫助，但是一旦您的應用大量使用，事件探查器就無法使用。 探查器會引入大量開銷，堆轉儲幾乎會停止生產中應用程序的所有處理。 基本上，您需要使該JVM / CLR上的應用程序脫機才能完成所有工作。

隨著當今應用程序的發展，這些繁瑣的過程變得越來越難維護。 隨著應用程序變得越來越復雜，堆越來越大，最終，這些方法并沒有減少它。

AppDynamics和內存泄漏

迄今為止，我們的方法一直是提供全面的事務快照，尤其是明顯的代碼問題，可以使您深入了解問題的根源。 為了有效地隔離和解決內存泄漏，事務和代碼路徑分析至關重要。

這帶給我們AppDynamics的一些有趣的發展。 我們為公司提供了一種直接識別內存泄漏根本原因的方法。 您可以自動檢測泄漏，確定是誰在創建泄漏，以及導致該泄漏的代碼路徑或業務交易。 您可以在此處了解更多信息。

這有好處嗎？ 減少停機時間并降低MTTR。 我們很興奮。 希望你也是。

通過AppDynamics解決應用程序問題的速度提高了10倍–以最小的開銷在代碼級深度監視生產應用程序。 開始免費試用！

翻譯自: https://www.javacodegeeks.com/2016/10/apm-non-java-guru-leak.html

總結

以上是生活随笔為你收集整理的非Java专家的APM：什么泄漏？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。