在本文裏小編給大家整理了一篇關於JVM中的本機內存跟蹤的相關知識點內容，有興趣的朋友們參考學習下。
1.概述
有沒有想過爲什麼Java應用程序通過衆所周知的-Xms和-Xmx調優標誌消耗的內存比指定數量多得多？出於各種原因和可能的優化，JVM可以分配額外的本機內存。這些額外的分配最終會使消耗的內存超出-Xmx限制。
在本教程中，我們將列舉JVM中的一些常見內存分配源，以及它們的大小調整標誌，然後學習如何使用本機內存跟蹤監視它們。
2.原生分配
堆通常是Java應用程序中最大的內存使用者，但還有其他人。除了堆之外，JVM還從本機內存中分配出一個相當大的塊來維護類的元數據，應用程序代碼，JIT生成的代碼，內部數據結構等。在下面的部分中，我們將探討其中的一些分配。
2.1. Metaspace(元空間)
爲了維護有關已加載類的一些元數據，JVM使用名爲Metaspace的專用非堆區域。在Java 8之前，被稱爲PermGen或Permanent Generation。 Metaspace或PermGen包含有關已加載類的元數據，而不是它們的實例，它們保存在堆中。
這裏重要的是堆大小配置不會影響元空間大小，因爲Metaspace是一個堆外數據區。爲了限制Metaspace大小，我們使用其他調優標誌：
-XX：MetaspaceSize和-XX：MaxMetaspaceSize設置最小和最大元空間大小
在Java 8之前，-XX：PermSize和-XX：MaxPermSize設置最小和最大PermGen大小
2.2. Threads(線程)
JVM中最耗費內存的數據區之一是堆棧，與每個線程同時創建。堆棧存儲局部變量和部分結果，在方法調用中起着重要作用。
默認的線程堆棧大小取決於平臺，但在大多數現代64位操作系統中，它大約爲1 MB。此大小可通過-Xss調整標誌進行配置。
與其他數據區域相比，當對線程數沒有限制時，分配給堆棧的總內存實際上是無限制的。值得一提的是，JVM本身需要一些線程來執行其內部操作，如GC或即時編譯。
2.3. Code Cache(代碼緩存)
爲了在不同平臺上運行JVM字節碼，需要將其轉換爲機器指令。執行程序時，JIT編譯器負責此編譯。
當JVM將字節碼編譯爲彙編指令時，它會將這些指令存儲在稱爲代碼緩存的特殊非堆數據區中。可以像管理JVM中的其他數據區一樣管理代碼緩存。 -XX：InitialCodeCacheSize和-XX：ReservedCodeCacheSize調整標誌確定代碼緩存的初始值和可能最大值。
2.4. Garbage Collection(垃圾回收)
JVM附帶了一些GC算法，每個算法適用於不同的用例。所有這些GC算法都有一個共同的特點：他們需要使用一些堆外數據結構來執行他們的任務。這些內部數據結構消耗更多本機內存。
2.5. Symbols(符號)
讓我們從 Strings 開始，這是應用程序和庫代碼中最常用的數據類型之一。由於它們無處不在，它們通常佔據堆的很大一部分。如果大量的這些字符串包含相同的內容，那麼堆的很大一部分將被浪費。
爲了節省一些堆空間，我們可以存儲每個 String 的一個版本，並讓其他版本引用存儲的版本。此過程稱爲 String Interning 。由於JVM只能內部編譯時間字符串常量，我們可以手動調用字符串的intern方法來獲取內部編譯字符串。
JVM將實際存儲的字符串存儲在本機特殊固定大小並稱爲字符串表的哈希表中，也稱爲字符串池。我們可以通過-XX：StringTableSize調整標誌配置表大小（即桶的數量）。
除了字符串表之外，還有另一個稱爲運行時常量池的本機數據區域。 JVM使用此池來存儲常量，如編譯時數字文字或必須在運行時解析的方法和字段引用。
2.6. Native Byte Buffers(本地字節緩衝區)
JVM通常有大量分配本機內存的嫌疑，但有時開發人員也可以直接分配本機內存。最常見的方法是被JNI調用的malloc和NIO中可直接調用的ByteBuffers。
2.7. Additional Tuning Flags(額外的調整標誌)
在本節中，我們針對不同的優化方案使用了少量JVM調優標誌。使用以下提示，我們幾乎可以找到與特定概念相關的所有調優標誌：
$ java -XX:+PrintFlagsFinal -version | grep <concept>
PrintFlagsFinal打印JVM中的所有-XX選項。例如，要查找所有與Metaspace相關的標誌：
$ java -XX:+PrintFlagsFinal -version | grep Metaspace
// truncated
uintx MaxMetaspaceSize = 18446744073709547520 {product}
uintx MetaspaceSize = 21807104 {pd product}
// truncated
3. 本機內存跟蹤 (NMT)
現在我們已經瞭解了JVM中本機內存分配的常見來源，現在是時候找出如何監視它們了。首先，我們應該使用另一個JVM調優標誌啓用本機內存跟蹤：-XX：NativeMemoryTracking = off | sumary | detail。默認情況下，NMT處於關閉狀態，但我們可以使其查看其觀察的摘要或詳細視圖。
假設我們想要跟蹤典型Spring Boot應用程序的本機分配：
$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseG1GC -jar app.jar
在這裏，我們在分配300 MB堆空間的同時啓用NMT，G1作爲我們的GC算法。
3.1. 實例快照
啓用NMT後，我們可以使用jcmd命令隨時獲取本機內存信息：
$ jcmd <pid> VM.native_memory
爲了找到JVM應用程序的PID，我們可以使用jps命令：
$ jps -l 7858 app.jar // This is our app 7899 sun.tools.jps.Jps
現在，如果我們將jcmd與適當的pid一起使用，VM.native_memory會使JVM打印出有關本機分配的信息：
$ jcmd 7858 VM.native_memory
讓我們逐節分析NMT輸出。
3.2. 總分配
NMT報告全部保留和提交的內存如下：
Native Memory Tracking:
Total: reserved=1731124KB, committed=448152KB
保留內存表示我們的應用程序可能使用的內存總量。相反，提交的內存表示我們的應用程序現在使用的內存量。
儘管分配了300MB的堆，我們的應用程序的總預留內存幾乎是1.7 GB，遠遠超過它。類似地，提交的內存大約爲440 MB，這再次遠遠超過300 MB。
在整體瞭解之後，NMT報告每個分配源的內存分配。所以，讓我們深入探討每個來源。
3.3. Heap(堆)
NMT按我們的預期報告堆分配：
Java Heap (reserved=307200KB, committed=307200KB)
(mmap: reserved=307200KB, committed=307200KB)
300 MB的保留和已提交內存，與我們的堆大小設置相匹配。
3.4. Metaspace（元空間）
這是NMT關於加載類的元數據的報告：
Class (reserved=1091407KB, committed=45815KB) (classes #6566) (malloc=10063KB #8519) (mmap: reserved=1081344KB, committed=35752KB)
幾乎保留了1 GB，45 MB保留加載6566個類。
3.5. Thread(線程)
這是關於線程分配的NMT報告：
Thread (reserved=37018KB, committed=37018KB) (thread #37) (stack: reserved=36864KB, committed=36864KB) (malloc=112KB #190) (arena=42KB #72)
總共有36 MB的內存被分配給37個線程的堆棧 - 每個堆棧大約1 MB。 JVM在創建時將內存分配給線程，因此保留和提交的分配是相等的。
3.6. Code Cache(代碼緩衝區)
讓我們看看NMT對JIT生成和緩存的彙編指令的報告：
Code (reserved=251549KB, committed=14169KB) (malloc=1949KB #3424) (mmap: reserved=249600KB, committed=12220KB)
目前，正在緩存大約13 MB的代碼，這個數量可能會達到245 MB。
3.7. GC
以下是有關G1 GC內存使用情況的NMT報告：
GC (reserved=61771KB, committed=61771KB) (malloc=17603KB #4501) (mmap: reserved=44168KB, committed=44168KB)
我們可以看到，保留和已提交都接近60 MB，致力於幫助G1。
讓我們來看看更簡單的GC的內存使用情況，比如Serial GC：
$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseSerialGC -jar app.jar
Serial GC 幾乎使用不到1 MB：
GC (reserved=1034KB, committed=1034KB) (malloc=26KB #158) (mmap: reserved=1008KB, committed=1008KB)
顯然，我們不能僅僅因爲其內存使用而選擇GC算法，因爲串行GC的暫停回收本質可能會導致性能下降。但是，還有幾個GC可供選擇，它們各自平衡內存和性能。
3.8. Symbol(符號)
以下是有關符號分配的NMT報告，例如字符串表和常量池：
Symbol (reserved=10148KB, committed=10148KB) (malloc=7295KB #66194) (arena=2853KB #1)
將近10 MB分配給符號。
3.9. 隨着時間的推移的NMT
NMT允許我們跟蹤內存分配如何隨時間變化。首先，我們應該將應用程序的當前狀態標記爲基線：
$ jcmd <pid> VM.native_memory baseline
Baseline succeeded
然後，過了一會兒，我們可以將當前的內存使用情況與該基線（baseline）進行比較：
$ jcmd <pid> VM.native_memory summary.diff
NMT使用+和 - 符號將告訴我們在此期間內存使用情況如何變化：
Total: reserved=1771487KB +3373KB, committed=491491KB +6873KB - Java Heap (reserved=307200KB, committed=307200KB) (mmap: reserved=307200KB, committed=307200KB) - Class (reserved=1084300KB +2103KB, committed=39356KB +2871KB) // Truncated
保留和提交的總內存分別增加了3 MB和6 MB。可以很容易地發現內存分配的其他波動。
3.10. 詳細的NMT
NMT可以提供非常詳細的有關整個存儲空間映射的信息。要啓用此詳細報告，我們應使用 -XX：NativeMemoryTracking =detail 信息調整標誌。
4. 結束語
在本文中，我們列舉了JVM中本機內存分配的不同使用者。然後，我們學習瞭如何檢查正在運行的應用程序以監視其本機分配。藉助以上這些，我們可以更有效地調整應用程序以及運行時環境的大小。