1.概述
是否曾经想过为什么Java应用程序通过众所周知的-Xms和-Xmx调整标志消耗的内存比指定的数量大得多 ？由于各种原因和可能的优化，JVM可能会分配额外的本机内存。这些额外的分配最终可能使消耗的内存超出-Xmx 限制。
在本教程中，我们将枚举JVM中本机内存分配的一些常见来源，以及它们的大小调整标志，然后学习如何使用本机内存跟踪来监视它们。
2.本机分配
通常，堆是Java应用程序中最大的内存消耗者，但是还有其他一些。除了堆之外，JVM从本地内存中分配了相当大的块来维护其类元数据，应用程序代码，由JIT生成的代码，内部数据结构等。在以下各节中，我们将探讨其中的一些分配。
2.1 元空间
为了维护有关已加载类的某些元数据，JVM使用了称为Metaspace*****的专用非堆区域。在Java 8之前，等效项称为PermGen或Permanent Generation*。Metaspace或PermGen包含有关已加载类的元数据，而不是包含在堆中的有关它们的实例的元数据。
这里重要的是，由于元空间是堆外数据区域，因此堆大小调整配置不会影响元空间的大小。为了限制元空间的大小，我们使用其他调整标志：
- -XX：MetaspaceSize和-XX：MaxMetaspaceSize*设置最小和最大元空间大小
- 在Java 8之前，使用-XX：PermSize和-XX：MaxPermSize来设置最小和最大PermGen大小
2.2 线程数
JVM中最消耗内存的数据区域之一是堆栈，它与每个线程同时创建。堆栈存储局部变量和部分结果，在方法调用中起着重要作用。
默认的线程堆栈大小取决于平台，但是在大多数现代的64位操作系统中，大约为1 MB。此大小可通过*-Xss *调整标志进行配置。
与其他数据区域相比，当对线程数没有限制时，分配给堆栈的总内存实际上是不受限制的。 还值得一提的是，JVM本身需要一些线程来执行其内部操作，例如GC或即时编译。
2.3 代码缓存
为了在不同平台上运行JVM字节码，需要将其转换为机器指令。在执行程序时，JIT编译器负责此编译。
*JVM将字节码编译为汇编指令时，会将这些指令存储在称为代码缓存*****的特殊非堆数据区域中 *****。 ***可以像JVM中的其他数据区域一样管理代码缓存。的 *-XX：InitialCodeCacheSize *和 *-XX：ReservedCodeCacheSize *调谐标志确定用于代码高速缓存中的初始和最大可能大小。
2.4 垃圾收集
JVM附带了几种GC算法，每种算法都适合不同的用例。所有这些GC算法都有一个共同的特征：它们需要使用一些堆外数据结构来执行任务。这些内部数据结构消耗更多的本机内存。
2.5 Symbols
让我们从字符串开始 *， *它是应用程序和库代码中最常用的数据类型之一。由于它们无处不在，因此它们通常占据堆的很大一部分。如果大量的这些字符串包含相同的内容，那么堆的很大一部分将被浪费。
为了节省一些堆空间，我们可以存储每个*String的 *一个版本， 并让其他版本引用存储的版本。 此过程称为字符串实习。 **由于JVM只能内生 *编译时间字符串常量，因此 我们可以对要内生的字符串手动调用intern（） *方法。
JVM将内联的字符串存储在特殊的本机固定大小的哈希*****表中，*****该哈希表称为*****String Table，*****也称为String Pool*****。* 我们可以通过*-XX：StringTableSize *调整标志来配置表的大小（即桶数） 。
除了字符串表外，还有另一个本机数据区域，称为*运行时常量池。 *JVM使用此池存储必须在运行时解析的常量，例如编译时数字文字，方法和字段引用。
2.6 本机字节缓冲区 Native Byte Buffers
JVM通常是大量本机分配的可疑对象，但有时开发人员也可以直接分配本机内存。最常见的方法是通过JNI和NIO的直接ByteBuffers进行*malloc *调用 。
2.7 Additional Tuning Flags
在本节中，我们针对不同的优化方案使用了少数JVM调整标志。使用以下技巧，我们几乎可以找到与特定概念相关的所有调整标志：
$ java -XX:+PrintFlagsFinal -version | grep <concept>
该PrintFlagsFinal打印所有- *XX *在JVM选项。例如，要查找所有与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
在这里，我们使用G1作为GC算法，在分配300 MB堆空间的同时启用NMT。
3.1 即时快照
启用NMT后，我们可以随时使用*jcmd *命令获取本机内存信息 ：
$ jcmd <pid> VM.native_memory
为了找到JVM应用程序的PID，我们可以使用 jps命令：
$ jps -l 7858 app.jar // This is our app7899 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
保留的内存代表我们的应用程序可能使用的内存总量。相反，已提交的内存等于我们的应用程序当前正在使用的内存量。
尽管分配了300 MB的堆，但我们的应用程序的总保留内存几乎为1.7 GB，远不止于此。同样，已提交的内存大约为440 MB，这又远远超过了300 MB。
在合计部分之后，NMT报告每个分配源的内存分配。因此，让我们深入探讨每个来源。
3.3 堆
NMT按预期报告了我们的堆分配：
Java Heap (reserved=307200KB, committed=307200KB) (mmap: reserved=307200KB, committed=307200KB)
300 MB的保留和提交内存，与我们的堆大小设置匹配。
3.4 元空间
NMT关于已加载类的类元数据的说明如下：
Class (reserved=1091407KB, committed=45815KB) (classes #6566) (malloc=10063KB #8519) (mmap: reserved=1081344KB, committed=35752KB)
保留了将近1 GB的空间，并有45 MB的空间用于加载6566类。
3.5 线程
这是关于线程分配的NMT报告：
Thread (reserved=37018KB, committed=37018KB) (thread #37) (stack: reserved=36864KB, committed=36864KB) (malloc=112KB #190) (arena=42KB #72)
总共为37个线程的堆栈分配了36 MB的内存–每个堆栈几乎1 MB。JVM在创建时将内存分配给线程，因此保留和提交的分配是相等的。
3.6 代码缓存
让我们看看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（例如串行GC）的内存使用情况：
$ java -XX:NativeMemoryTracking=summary -Xms300m -Xmx300m -XX:+UseSerialGC -jar app.jar
串行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 baselineBaseline succeeded
然后，过一会儿，我们可以将当前内存使用量与该基准进行比较：
$ 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中本机内存分配的不同贡献者。然后，我们学习了如何检查正在运行的应用程序以监视其本机分配。借助这些见解，我们可以更有效地调整应用程序并调整运行时环境的大小。
