共计 2561 个字符，预计需要花费 7 分钟才能阅读完成。
Java 进程使用的虚拟内存确实比 Java Heap 要大很多。JVM 包括很多子系统：垃圾收集器、类加载系统、JIT 编译器等等，这些子系统各自都需要一定数量的 RAM 才能正常工作。
当一个 Java 进程运行时，也不仅仅是 JVM 在消耗 RAM，很多本地库（Java 类库中引用的本地库）可能需要分配原生内存，这些内存无法被 JVM 的 Native Memory Tracking 机制监控到。Java 应用自身也可能通过 DirectByteBuffers 等类来使用堆外内存。
那么，当一个 Java 进程运行时，有哪些部分在消耗内存呢？这里我们只展示哪些可以被 Native Memory Tracking 监控到的部分。
一、JVM 部分
Java Heap： 最明显的部分，Java 对象在这个区域分配和回收，Heap 的最大值由 -Xmx 决定。
Garbage Collector：GC 的数据结构和算法需要额外的内存对堆内存进行管理。这些数据结构包括：Mark Bitmap、Mark Stack（用于跟踪存活的对象）、Remembered Sets（用于记录 region 之间的引用）等等。这些数据结构中的一些是可以直接调整的，例如：-XX:MarkStackSizeMax，其他的则依赖于堆的分布，例如：分区大小，-XX:G1HeapRegionSize，这个值越大 Remembered Sets 的值越小。不同的 GC 算法需要的额外内存是不同的，-XX:+UseSerialGC 和 -XX:+UseShenandoahGC 需要较小的额外内存，G1 和 CMS 则需要 Heap size 的 10% 作为额外内存。
Code Cache： 用于存放动态生成的代码：JIT 编译的方法、拦截器和运行时存根。这个区域的大小由 -XX:ReservedCodeCacheSize 确定（默认是 240M）。使用 -XX-TieredCompilation 关掉多层编译，可以减少需要编译的代码，从而减少 Code Cache 的使用。
Compiler：JIT 编译器需要一些内存来才能工作。这个值可以通过关闭多层编译或减少执行编译的线程数（-XX:CICompilerCount）来调整.
Class loading： 类的元数据（方法的字节码、符号表、常量池、注解等）被存放在 off-heap 区域，也叫 Metaspace。当前 JVM 进程加载了越多的类，就会使用越多的 metaspace。通过设置 -XX:MaxMetaspaceSize（默认是无限）或 -XX:CompressedClassSpaceSize（默认是 1G）可以限制元空间的大小
Symbol tables：JVM 中维护了两个重要的哈希表：Symbol 表包括类、方法、接口等语言元素的名称、签名、ID 等，String table 记录了被 interned 过的字符串的引用。如果 Native Tracking 表明 String table 使用了很大的内存，那么说明该 Java 应用存在对 String.intern 方法的滥用。
Threads： 线程栈也会使用 RAM，栈的大小由 -Xss 确定。默认是 1 个线程最大有 1M 的线程栈，幸运得失事情并没有这么糟糕——OS 使用惰性策略分配内存页，实际上每个 Java 线程使用的 RAM 很小（一般 80~200K），作者使用这个脚本（https://github.com/apangin/js…）来统计有多少 RSS 空间是属于 Java 线程的。
二、堆外内存（Direct buffers）
Java 应用可以通过 ByteBuffer.allocateDirect 显式申请堆外内存；默认的堆外内存大小是 -Xmx，但是这个值可被 -XX:MaxDirectMemorySize 覆盖。在 JDK11 之前，Direct ByteBuffers 被 NMT（Native Memory Tracking）列举在 other 部分，可以通过 JMC 观察到堆外内存的使用情况。
除了 DirectByteBuffers，MappedByteBuffers 也会使用本地内存，MappedByteBuffers 的作用是将文件内容映射到进程的虚拟内存中，NMT 没有跟踪它们，想要限制这部分的大小并不容易，可以通过 pmap -x <pid> 命令观察当前进程使用的实际大小：
Address Kbytes RSS Dirty Mode Mapping
...
00007f2b3e557000 39592 32956 0 r--s- some-file-17405-Index.db
00007f2b40c01000 39600 33092 0 r--s- some-file-17404-Index.db三、本地库（Native libraries）
由 System.loadLibrary 加载的 JNI 代码也会按需分配 RAM，并且这部分内存不受 JVM 管理。在这里需要关注的是 Java 类库，未关闭的 Java 资源会导致本地内存泄漏，典型的例子是：ZipInputStream 或 DirectoryStream。
JVMTI agent，特别是 jdwp 调试 agent，也可能导致内存的过量使用（PS：去年写 memory agent 代码造成的内存泄漏记忆犹新）。
四、Allocator issues
一个 Java 进程可以通过系统调用（mmap）或标准库（malloc）方法来向 OS 申请内存。malloc 自己又通过 mmap 来向 OS 申请比较大的内存，并通过自己的算法来管理这些内存，这可能会导致内存碎片，从而导致过量使用虚拟内存。jemalloc 是另外一个内存分配器，它比常规的 malloc 分配器需要更少的 footprint，因此可以在自己的 C ++ 代码中尝试使用 jemalloc 方法。
结论
无法准确统计一个 Java 进程使用的虚拟内存，因为有太多因素需要考虑，列举如下：
Total memory = Heap + Code Cache + Metaspace + Symbol tables +
Other JVM structures + Thread stacks +
Direct buffers + Mapped files +
Native Libraries + Malloc overhead + ...本号专注于后端技术、JVM 问题排查和优化、Java 面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。
