JVM中的本地内存追踪NMT（Native Memory Tracking）

JVM中的本地内存追踪NMT（Native Memory Tracking）

1 概述

每当想起为什么Java应用程序会消耗比设置-Xms和-Xmx多的内存的时候，心中总是会有个问号。因为一些理由和优化，JVM可能会额外分配本地内存。这些额外分配的内存最终会消耗超过Xmx的限制。

在本文中，我们将列举一些在JVM中常见的本地内存资源，以及设置它们大小的标志，然后我们学习怎么运用Native Memory Tracking去监视它们。

2. 本地分配

堆通常是在Java应用程序中消耗内存最大的部分，但是也有例外。**除了堆，JVM也会从本地内存中分配相当大的一块以维护其元数据（metadata），应用代码，JIT生成的代码，以及内部数据结构等等。**在接下来的章节，我们将探索这些内容。

2.1. 元空间（Metaspace）

为了维护加载类的元数据，JVM使用了一个专门的非堆区域，该区域称为元空间。在Java8之前，此区域等效于永久代。元空间或者永久代包含了加载类的元数据而非其实例，实例都保存在堆中。

这里值得强调的是：堆大小的配置不会影响元空间。因为元数据是非堆区域。为了限制元空间的大小，我们使用如下的标志：

• -XX:MetaspaceSize和*-XX:MaxMetaspaceSize*以设置最小和最大的元空间大小。
• 在Java8之前，-XX:PermSize和*-XX:MaxPermSize*是设置最小和最大的永久代大小。

2.2. 线程

最重要的内存数据区域之一是JVM的栈，每一条线程都有一个独立维护的栈。栈保存本地变量和部分的结果，扮演方法调用的重要角色。

默认的线程栈的大小是平台无关的，但是在大多数64位操作系统中，它的大小大约是1MB。该大小是通过*-Xss*标志设置。

相比于其他的数据区域，**只要线程的数量没限制，栈的内存分配通常是不受约束的。**同样值得说明的是JVM自身需要一些线程去执行一些内部操作如GC和即时编译。

2.3. 代码缓存

为了在不同的平台上运行JVM字节码，它需要将其转换为机器码。JIT编译器负责其编译操作。

**当JVM编译字节码到汇编指令时，它保存这些指令在一个特殊的非堆区域，该区域称为CodeCache。*JVM可以像管理其他区域一样管理CodeCache。-XX:InitialCodeCacheSize和-XX:ReservedCodeCacheSize*标记决定了CodeCache的初始值和可能的最大值。

2.4. 垃圾回收

JVM有很多GC算法以针对不同的情形。所有的这些GC都有一个共同的特点：那就是它们需要一些非堆的结构来运行它们的任务。这些内部结构会消耗更多的本地内存。

2.5. 符号（Symbols）

让我们从String开始，这是在应用和库代码中使用最多的一种数据类型。因为它们的特殊性，它们通常会占据堆的很大一部分。如果很多的字符串共享同样的内容，则堆内存中的很大一部分都浪费了。

为了解决堆空间，我们保存每一个String的唯一版本然后让其它的变量引用这个版本。该过程称为*String Interning***。因为JVM只能intern编译时间字符串常量，我们能够手动调用intern()方法在我们想去intern的字符串上。

JVM stores interned strings in a special native fixed-sized hashtable called the String Table, also known as the *String Pool*. We can configure the table size (i.e. the number of buckets) via the -XX:StringTableSize tuning flag.

**JVM有一个本地固定大小的哈希表（该表称为String Table）来保存内部字符串，这个表也称为String Pool。**我们能够通过-XX:StringTableSize标志配置表的大小（例如桶的数量）。

除了String table，还有另外一个称为运行时常量池的内部区域。JVM使用该区域保存常量，例如编译时的数字字面量或者必须在运行时保存的方法和字段引用。

2.6. 本地字节缓存

JVM通常是自己做本地分配，到有时开发者想直接分配本地内存。通常使用的方法是通过JNI调用malloc或者NIO的直接ByteBuffers.

2.7. 其他标志

在本节，我们为不同的优化场景使用了一些JVM标志。用如下的命令可以找到所有相关的概念：

$ java -XX:+PrintFlagsFinal -version | grep <concept>

The PrintFlagsFinal prints all the –XX options in JVM. For example, to find all Metaspace related flags:

$ java -XX:+PrintFlagsFinal -version | grep Metaspace
      // truncated
      uintx MaxMetaspaceSize                          = 18446744073709547520                    {product}
      uintx MetaspaceSize                             = 21807104                                {pd product}
      // truncated

3. Native Memory Tracking (NMT)

现在我们知道在JVM中本地内存分配的一些常见的源，现在是找出如何监视它们的时候了。首先，我们应该通过使用其他的JVM标志是使得可以本地内存追踪：-XX:NativeMemoryTracking=off|summary|detail。默认地，NMT是关闭的，但是我们能够开启它。

假设我们想要跟踪一个典型的SpringBoot应用的本地分配：

$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseG1GC -jar app.jar

Here, we’re enabling the NMT while allocating 300 MB of heap space, with G1 as our GC algorithm.

在这里，当分配300MB的堆大小的时候，我们正在启动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.7GB，远远大于堆内存。类似，使用内存大约400MB，也大于300MB。

After the total section, NMT reports memory allocations per allocation source. So, let’s explore each source in depth.

在本节后，NMT打印了每个源的内存分配。让我们更深一步了解一下。

3.3. 堆

NMT打印我们的堆内存，确实像我们前面设置的一样：

Java Heap (reserved=307200KB, committed=307200KB)
          (mmap: reserved=307200KB, committed=307200KB)

300MB的保留和使用内存，符合我们设置的情况。

3.4. 元数据区（Metaspace）

下面是加载的类的类元数据的NMT信息：

Class (reserved=1091407KB, committed=45815KB)
      (classes #6566)
      (malloc=10063KB #8519) 
      (mmap: reserved=1081344KB, committed=35752KB)

大约1GB的保留和45MB的使用空间区加载6566个类。

3.5. 线程

下面是线程的内存分配信息：

Thread (reserved=37018KB, committed=37018KB)
       (thread #37)
       (stack: reserved=36864KB, committed=36864KB)
       (malloc=112KB #190) 
       (arena=42KB #72)

总共，36MB的内存被分配到了37个线程——大约每个栈有1MB的内存。JVM分配内存到线程是在JVM创建之初，所以保留内存和使用内存是相等的。

3.6. Code Cache

让我们看看JIT产生的汇编指令所占的空间：

Code (reserved=251549KB, committed=14169KB)
     (malloc=1949KB #3424) 
     (mmap: reserved=249600KB, committed=12220KB)

当前，大约13MB的空间被会缓存了，并且能使用的空间大约在245MB。

3.7. GC

下面是NMT报告的G1GC的内存使用情况：

GC (reserved=61771KB, committed=61771KB)
   (malloc=17603KB #4501) 
   (mmap: reserved=44168KB, committed=44168KB)

我们能看到，大约60MB的空间是G1可以保留和使用的。

让我们看看更简单的一种GC，SerialGC：

$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseSerialGC -jar app.jar

SerialGC仅仅使用1MB：

GC (reserved=1034KB, committed=1034KB)
   (malloc=26KB #158) 
   (mmap: reserved=1008KB, committed=1008KB)

明显地，我们不应该挑选一个GC算法仅仅是因为内存使用，作为SerialGC的STW（stop-the-world）属性可能导致性能下降。然而，有其他几种GC可供选择，并且它们在不同情况下能够平衡内存和性能。

3.8. 符号（Symbol）

下面是NMT打印有关符号的分配，如同String table和常量池：

Symbol (reserved=10148KB, committed=10148KB)
       (malloc=7295KB #66194) 
       (arena=2853KB #1)

大约10MB被分配给符号使用。

3.9. NMT 监控时间段

**NMT允许我们追踪在一段时间内的内存改变情况。**首先我们应该标记当前我们应用程序的状态作为基线：

$ jcmd <pid> VM.native_memory baseline
Baseline succeeded

然后，过一段时间，我们就能够比较出当前内存与基线之间的差别：

$ jcmd <pid> VM.native_memory summary.diff

现在，使用+和-标记，就能够告诉我们在这段时间内内存的使用情况：

4. 结论

本文，我们列举了在JVM中本地内存分配的使用方法。然后，我们学习了怎么监控一个运行中的应用程序。有了这些内容，我们就能更加有效地调整我们的应用并且规划我们的运行时环境。