追蹤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中本機內存分配的不同使用者。然后，我們學習了如何檢查正在運行的應用程序以監視其本機分配。借助以上這些，我們可以更有效地調整應用程序以及運行時環境的大小。
  
  > 原文：<https://www.baeldung.com/native-memory-tracking-in-jvm>
  >
  > 作者：[Ali Dehghani](https://www.baeldung.com/author/ali-dehghani/)
  >
  > 譯者：Emma