为什么Java进程使用的RAM比Heap Size大？

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/jstackmem）来统计有多少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 命令观察当前进程使用的实际大小：

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 + ...

---

本号（javaadu）专注于后端技术、jvm问题排查和优化、java面试题、个人成长和自我管理等主题，为读者提供一线开发者的工作和成长经验，期待你能在这里有所收获。