详解Native Memory Tracking之追踪区域分析

摘要：本篇图文将介绍追踪区域的内存类型以及 NMT 无法追踪的内存。

Compiler

Compiler 就是 JIT 编译器线程在编译 code 时本身所使用的内存。查看 NMT 详情：

跟踪调用链路：InitializeJVM ->
Threads::create_vm ->
CompileBroker::compilation_init ->
CompileBroker::init_compiler_threads ->
CompileBroker::make_compiler_thread

发现最后 make_compiler_thread 的线程的个数是在 compilation_init() 中计算的：

追溯 c1_count、c2_count 的计算逻辑，首先在 JVM 初始化的时候（Threads::create_vm -> init_globals -> compilationPolicy_init）要设置编译的策略 CompilationPolicy：

此时我们默认开启了分层编译，所以 CompilationPolicyChoice 为 3 ，编译策略选用的是 AdvancedThresholdPolicy，查看相关源码（compilationPolicy_init -> AdvancedThresholdPolicy::initialize）：

我们可以发现，在未手动设置 -XX:CICompilerCountPerCPU 和 -XX:CICompilerCount 这两个参数的时候，JVM 会启动 CICompilerCountPerCPU ，启动编译线程的数目会根据 CPU 数重新计算而不再使用默认的 CICompilerCount 的值（3），计算公式通常情况下为 log n * log log n * 1.5（log 以 2 为底），此时笔者使用的机器有 64 个 CPU，经过计算得出编译线程的数目为 18。计算出编译线程的总数目之后，再按 1:2 的比例分别分配给 C1、C2，即我们上文所求的 c1_count、c2_count。

使用 jinfo -flag CICompilerCount 来验证此时 JVM 进程的编译线程数目：

所以我们可以通过显式的设置 -XX:CICompilerCount 来控制 JVM 开启编译线程的数目，从而限制 Compiler 部分所使用的内存（当然这部分内存比较小）。

编译线程也是线程，所以我们还可以通过 -XX:VMThreadStackSize 设置一个更小的值来节省此部分内存，但是削减虚拟机线程的堆栈大小是危险的操作，并不建议去因为此设置这个参数。

Internal

Internal 包含命令行解析器使用的内存、JVMTI、PerfData 以及 Unsafe 分配的内存等等。

其中命令行解释器就是在初始化创建虚拟机时对 JVM 的命令行参数加以解析并执行相应的操作，如对参数 -XX:NativeMemoryTracking=detail 进行解析。

JVMTI（JVM Tool Interface）是开发和监视 JVM 所使用的编程接口。它提供了一些方法去检查 JVM 状态和控制 JVM 的运行，详情可以查看 JVMTI官方文档 [1]。

PerfData 是 JVM 中用来记录一些指标数据的文件，如果开启 -XX:+UsePerfData（默认开启），JVM 会通过 mmap 的方式（即使用上文中提到的 os::reserve_memory 和 os::commit_memory）去映射到 {tmpdir}/hsperfdata_/pid 文件中，jstat 通过读取 PerfData 中的数据来展示 JVM 进程中的各种指标信息.

需要注意的是， {tmpdir}/hsperfdata/pid_ 与{tmpdir}/.java_pid 并不是一个东西，后者是在 Attach 机制中用来通讯的，类似一种 Unix Domain Socket 的思想，不过真正的 Unix Domain Socket（JEP380 [2]）在 JDK16 中才支持。

我们在操作 nio 时经常使用 ByteBuffer ，其中 ByteBuffer.allocateDirect / DirectByteBuffer 会通过 unsafe.allocateMemory 的方式来 malloc 分配 naive memory，虽然 DirectByteBuffer 本身还是存放于 Heap 堆中，但是它对应的 address 映射的却是分配在堆外内存的 native memory，NMT 会将 Unsafe_AllocateMemory 方式分配的内存记录在 Internal 之中（jstat 也是通过 ByteBuffer 的方式来使用 PerfData）。

需要注意的是，Unsafe_AllocateMemory 分配的内存在 JDK11之前，在 NMT 中都属于 Internal，但是在 JDK11 之后被 NMT 归属到 Other 中。例如相同 ByteBuffer.allocateDirect 在 JDK11 中进行追踪：[0x0000ffff8c0b4a60] Unsafe_AllocateMemory0+0x60[0x0000ffff6b822fbc] (malloc=393218KB type=Other #3)

简单查看下相关源码：

一般情况下，命令行解释器、JVMTI等方式不会申请太大的内存，我们需要注意的是通过 Unsafe_AllocateMemory 方式申请的堆外内存（如业务使用了 Netty ），可以通过一个简单的示例来进行验证，这个示例的 JVM 启动参数为：-Xmx1G -Xms1G -XX:+UseG1GC -XX:MaxMetaspaceSize=256M -XX:ReservedCodeCacheSize=256M -XX:NativeMemoryTracking=detail（去除了 -XX:MaxDirectMemorySize=256M 的限制）：

查看输出：

查看 NMT 详情：

可以发现，我们在代码中使用 ByteBuffer.allocateDirect（内部也是使用 new DirectByteBuffer(capacity)）的方式，即 Unsafe_AllocateMemory 申请的堆外内存被 NMT 以 Internal 的方式记录了下来：（128 M + 256 M）= 384 M = 393216 KB = 402653184 Bytes。

当然我们可以使用参数 -XX:MaxDirectMemorySize 来限制 Direct Buffer 申请的最大内存。

Symbol

Symbol 为 JVM 中的符号表所使用的内存，HotSpot中符号表主要有两种： SymbolTable 与 StringTable。

大家都知道 Java 的类在编译之后会生成 Constant pool 常量池，常量池中会有很多的字符串常量，HotSpot 出于节省内存的考虑，往往会将这些字符串常量作为一个 Symbol 对象存入一个 HashTable 的表结构中即 SymbolTable，如果该字符串可以在 SymbolTable 中 lookup（SymbolTable::lookup）到，那么就会重用该字符串，如果找不到才会创建新的 Symbol（SymbolTable::new_symbol）。

当然除了 SymbolTable，还有它的双胞胎兄弟 StringTable（StringTable 结构与 SymbolTable 基本是一致的，都是 HashTable 的结构），即我们常说的字符串常量池。平时做业务开发和 StringTable 打交道会更多一些，HotSpot 也是基于节省内存的考虑为我们提供了 StringTable，我们可以通过 String.intern 的方式将字符串放入 StringTable 中来重用字符串。

编写一个简单的示例：

启动程序后我们可以使用 jcmd VM.native_memory baseline 来创建一个基线方便对比，稍作等待后再使用 jcmd VM.native_memory summary.diff/detail.diff 与创建的基线作对比，对比后我们可以发现：

JVM 进程这段时间内存一共增长了 20095KB，其中绝大部分都是 Symbol 申请的内存（17144KB），查看具体的申请信息正是 StringTable::intern 在不断的申请内存。

如果我们的程序错误的使用 String.intern() 或者 JDK intern 相关 BUG 导致了内存异常，可以通过这种方式轻松协助定位出来。

需要注意的是，虚拟机提供的参数 -XX:StringTableSize 并不是来限制 StringTable 最大申请的内存大小的，而是用来限制 StringTable 的表的长度的，我们加上 -XX:StringTableSize=10M 来重新启动 JVM 进程，一段时间后查看 NMT 追踪情况：

可以发现 StringTable 的大小是超过 10M 的，查看该参数的作用：

因为 StringTable 在 HotSpot 中是以 HashTable 的形式存储的，所以 -XX:StringTableSize 参数设置的其实是 HashTable 的长度，如果该值设置的过小的话，即使 HashTable 进行 rehash，hash 冲突也会十分频繁，会造成性能劣化并有可能导致进入 SafePoint 的时间增长。如果发生这种情况，可以调大该值。

• -XX:StringTableSize 在 32 位系统默认为 1009、64 位默认为 60013 ：const int defaultStringTableSize = NOT_LP64(1009) LP64_ONLY(60013); 。
• G1中可以使用 -XX:+UseStringDeduplication 参数来开启字符串自动去重功能（默认关闭），并使用 -XX:StringDeduplicationAgeThreshold 来控制字符串参与去重的 GC 年龄阈值。
• 与 -XX:StringTableSize 同理，我们可以通过 -XX:SymbolTableSize 来控制 SymbolTable 表的长度。

如果我们使用的是 JDK11 之后的 NMT，我们可以直接通过命令 jcmd VM.stringtable 与 jcmd VM.symboltable 来查看两者的使用情况：

Native Memory Tracking

Native Memory Tracking 使用的内存就是 JVM 进程开启 NMT 功能后，NMT 功能自身所申请的内存。

查看源码会发现，JVM 会在 MemTracker::init() 初始化的时候，使用 tracking_level() -> init_tracking_level() 获取我们设定的 tracking_level 追踪等级（如：summary、detail），然后将获取到的 level 分别传入 MallocTracker::initialize(level) 与 VirtualMemoryTracker::initialize(level) 进行判断，只有 level >= summary 的情况下，虚拟机才会分配 NMT 自身所用到的内存，如：VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable（detail 时才会创建） 等来记录 NMT 追踪的各种数据。

我们执行的 jcmd VM.native_memory summary/detail 命令，就会使用 NMTDCmd::report 方法来根据等级的不同获取不同的数据：

• summary 时使用 MemSummaryReporter::report() 获取 VirtualMemoryTracker、MallocMemorySummary 等储存的数据；
• detail 时使用 MemDetailReporter::report() 获取 VirtualMemoryTracker、MallocMemorySummary、MallocSiteTable 等储存的数据。

一般 NMT 自身占用的内存是比较小的，不需要太过关心。

Arena Chunk

Arena 是 JVM 分配的一些 Chunk（内存块），当退出作用域或离开代码区域时，内存将从这些 Chunk 中释放出来。然后这些 Chunk 就可以在其他子系统中重用. 需要注意的是，此时统计的 Arena 与 Chunk ，是 HotSpot 自己定义的 Arena、Chunk，而不是 Glibc 中相关的 Arena 与 Chunk 的概念。

我们会发现 NMT 详情中会有很多关于 Arena Chunk 的分配信息都是：

JVM 中通过 ChunkPool 来管理重用这些 Chunk，比如我们在创建线程时：

其中 ResourceArea 属于给线程分配的一个资源空间，一般 ResourceObj 都存放于此（如 C1/C2 优化时需要访问的运行时信息）；HandleArea 则用来存放线程所持有的句柄（handle），使用句柄来关联使用的对象。这两者都会去申请 Arena，而 Arena 则会通过 ChunkPool::allocate 来申请一个新的 Chunk 内存块。除此之外，JVM 进程用到 Arena 的地方还有非常多，比如 JMX、OopMap 等等一些相关的操作都会用到 ChunkPool。

眼尖的读者可能会注意到上文中提到，通常情况下会通过 ChunkPool::allocate 的方式来申请 Chunk 内存块。是的，其实除了 ChunkPool::allocate 的方式， JVM 中还存在另外一种申请 Arena Chunk 的方式，即直接借助 Glibc 的 malloc 来申请内存，JVM 为我们提供了相关的控制参数 UseMallocOnly：

我们可以发现这个参数是一个 develop 的参数，一般情况下我们是使用不到的，因为 VM option ‘UseMallocOnly’ is develop and is available only in debug version of VM，即我们只能在 debug 版本的 JVM 中才能开启该参数。

这里有的读者可能会有一个疑问，即是不是可以通过使用参数 -XX:+IgnoreUnrecognizedVMOptions（该参数开启之后可以允许 JVM 使用一些在 release 版本中不被允许使用的参数）的方式，在正常 release 版本的 JVM 中使用 UseMallocOnly 参数，很遗憾虽然我们可以通过这种方式开启 UseMallocOnly，但是实际上 UseMallocOnly 却不会生效，因为在源码中其逻辑如下：

可以发现，即使我们成功开启了 UseMallocOnly，也只有在 debug 版本（debug_only）的 JVM 中才能使用 malloc 的方式分配内存。

我们可以对比下，使用正常版本（release）的 JVM 添加 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseMallocOnly 启动参数的 NMT 相关日志与使用 debug（fastdebug/slowdebug）版本的 JVM 添加 -XX:+UseMallocOnly 启动参数的 NMT 相关日志：

我们可以清晰地观察到调用链的不同，即前者还是使用 ChunkPool::allocate 的方式来申请内存，而后者则使用 Arena::malloc 的方式来申请内存，查看 Arena::malloc 代码：

可以发现代码中通过 os::malloc 的方式来分配内存，同理释放内存时直接通过 os::free 即可，如 UseMallocOnly 中释放内存的相关代码：

虽然 JVM 为我们提供了两种方式来管理 Arena Chunk 的内存：

但是通常意义下我们只会用到第一种方式，并且一般 ChunkPool 管理的对象都比较小，整体来看 Arena Chunk 这块内存的使用不会很多。

Unknown

Unknown 则是下面几种情况

• 当内存类别无法确定时；
• 当 Arena 用作堆栈或值对象时；
• 当类型信息尚未到达时。

NMT 无法追踪的内存

需要注意的是，NMT 只能跟踪 JVM 代码的内存分配情况，对于非 JVM 的内存分配是无法追踪到的。

• 使用 JNI 调用的一些第三方 native code 申请的内存，比如使用 System.Loadlibrary 加载的一些库。
• 标准的 Java Class Library，典型的，如文件流等相关操作（如：Files.list、ZipInputStream 和 DirectoryStream 等）。

可以使用操作系统的内存工具等协助排查，或者使用 LD_PRELOAD malloc 函数的 hook/jemalloc/google-perftools(tcmalloc) 来代替 Glibc 的 malloc，协助追踪内存的分配。

由于篇幅有限，将在下篇文章给大家分享”使用 NMT 协助排查内存问题的案例”，敬请期待！

欢迎加入Compiler SIG交流群与大家共同交流学习编译技术相关内容，扫码添加小助手微信邀请你进入Compiler SIG交流群。

Original: https://www.cnblogs.com/huaweiyun/p/16902534.html
Author: 华为云开发者联盟
Title: 详解Native Memory Tracking之追踪区域分析