有很多不錯的工具可用來剖析Java應用程序，其中一些是，
1. 您的套件Java Profiler
2. JProfiler
3. Eclipse MAT 4. 可視VM
其中，您的工具包和JProfilers需要許可證，其他則可以免費使用產品。 我們將使用VisualVM。 它是一個簡單但功能強大的工具，并捆綁在JDK中。 它具有可下載和使用的插件功能列表。 要開始使用VisualVM，請轉到<JDK_HOME> \ bin并運行jvisualvm.exe 。 我發現以下文章對繼續學習很有用。
1. 使用VisualVM進行分析
2. VisualVM性能調整工具
3. 如何在不崩潰的情況下獲取VisualVM來配置JBoss
由于我們在這里討論內存，因此請確保按照本文所述，在VisualVM上安裝Visual GC插件。
設置階段– JVM內存結構
JVM內存分為三部分，如下圖所示。 在我們的應用程序中，我們關注堆內存。 我們可以使用參數將此值輸入到JVM，
-Xmx <size> –設置最大Java堆大小
-Xms <size> –設置初始Java堆大小
非堆內存存儲每個類的結構，例如運行時常量池，字段和方法數據，以及方法和構造函數的代碼以及內部字符串。
這是一篇不錯的文章，其中包含有關JVM內存大小的更多詳細信息。 在這里閱讀Javin關于JVM堆空間的文章。
一種常見的混淆是關于堆棧內存和堆內存 。 此處對此進行了很好的解釋。堆棧值僅存在于創建它們的函數范圍內。一旦返回，它們將被丟棄。 Java僅將原語存儲在堆棧中。 這樣可使堆棧變小，并有助于使單個堆棧幀變小，從而允許更多的嵌套調用。 對象是在堆上創建的，并且只有引用（即原語）在堆棧上傳遞。
現在，讓我們變得真實。 在Visual GC的圖像下方給出，這是前面提到的VisualVM內部的一個插件。 我們在這里看到許多圖形輸出的詳細能解密，請點擊這里 。
游戲開始–應用程序運行時會發生什么
創建對象時，它們位于Eden內部。 運行垃圾收集器（GC）時，如果對象已死（意味著它們不是活動引用），則將其清除，否則將其移至S1 （生存空間1）或S2 。 這稱為GC循環。 內部GM算法確定GC循環的頻率。 堆內存的Eden + S1 + S2部分稱為Young generation。 在固定數量的GC循環中幸存下來的對象將移入“ 舊一代”空間。 大多數Java對象死于嬰兒，并且永遠都不會到達OldGen。這通常包括局部變量，這些局部變量在方法執行后會刷新。
老一代內部的GC循環頻率比年輕一代要少得多。老一代對象的典型示例是單例，緩存的對象和其他應用程序廣泛使用的數據。
當事情沒有按照計劃進行時
在典型的應用中，Old Gen空間內部的變化較小。 如果即使在GC周期之后，Old Gen空間也隨著時間線性增長，則將導致OutOfMemoryError。 這可能表明代碼內有內存泄漏。 但是，我們可能需要使用探查器來找出造成這種情況的確切原因。 這是Dzon上有關Java EE企業性能問題的某些原因的文章。
這些是執行應用程序時JVM內存的組織方式和反應的基本構建塊。 從這一點開始，有很多主題，包括調整內存參數和垃圾收集器。 我將添加一些與此相關的有用資源。
1. Java性能調優，性能分析和內存管理
2. InfoQ演示：診斷Web應用程序內存不足錯誤
3. InfoQ演示：我所學到的有關JVM性能調整@twitter的一切 4. InfoQ演示：極限性能Java 5. Java理論與實踐：垃圾收集與性能
參考： Java內存概要分析（由Java的JCG合作伙伴 Manu PK 簡化 ，位于“面向對象的生活”博客中）。
翻譯自: https://www.javacodegeeks.com/2012/09/java-memory-model-simplified.html
)
