在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
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 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 VM.native_memory baseline
Baseline succeeded
然后，过了一会儿，我们可以将当前的内存使用情况与该基线（baseline）进行比较：
$ jcmd VM.native_memory summary.diff
NMT使用+和 - 符号将告诉我们在此期间内存使用情况如何变化：
Total: reserved=1771487KB +3373KB, committed=491491KB +6873KB
