为什么 JVM 报告的已提交内存比 Linux 进程常驻集大小多？

问题描述：

当运行启用了本机内存跟踪的 Java 应用程序（在 YARN 中）时（-XX:NativeMemoryTracking=detail请参阅https://docs.oracle.com/javase/8/docs/technotes/guides/vm/nmt-8.html和https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html），我可以看到 JVM 在不同类别中使用了多少内存。

我在 jdk 1.8.0_45 上的应用程序显示：

本机内存跟踪：

总计：保留=4023326KB，已提交=2762382KB
- Java 堆（保留=1331200KB，提交=1331200KB）
                            （mmap：保留=1331200KB，已提交=1331200KB）

- 类别（保留=1108143KB，提交=64559KB）
                            （课程编号 #8621）
                            （malloc=6319KB#17371）
                            （mmap：保留=1101824KB，已提交=58240KB）

- 线程（保留=1190668KB，提交=1190668KB）
                            （主题 #1154）
                            （堆栈：保留=1185284KB，已提交=1185284KB）
                            （malloc=3809KB#5771）
                            （竞技场=1575KB #2306）

- 代码（保留=255744KB，提交=38384KB）
                            （malloc=6144KB#8858）
                            （mmap：保留=249600KB，已提交=32240KB）

- GC（保留=54995KB，已提交=54995KB）
                            （malloc=5775KB#217）
                            （mmap：保留=49220KB，已提交=49220KB）

- 编译器（保留=267KB，提交=267KB）
                            （malloc=137KB#333）
                            （竞技场=131KB #3）

- 内部（保留=65106KB，已提交=65106KB）
                            （malloc=65074KB#29652）
                            （mmap：保留=32KB，提交=32KB）

- 符号（保留=13622KB，提交=13622KB）
                            （malloc=12016KB#128199）
                            （竞技场=1606KB #1）

- 本机内存跟踪（保留=3361KB，提交=3361KB）
                            （malloc=287KB#3994）
                            （跟踪开销=3075KB）

- Arena Chunk（保留=220KB，已提交=220KB）
                            （内存分配=220KB）

这显示了已提交的内存为 2.7GB，其中包括已分配的堆 1.3GB 和已分配的线程堆栈近 1.2GB（使用许多线程）。

但是，运行时ps ax -o pid,rss | grep <mypid>，top它仅显示 1.6GB 的RES/rss常驻内存。检查交换时显示未使用任何内存：

免费-m
             已使用的、可用的、缓存的共享缓冲区总数
内存：129180 99348 29831 0 2689 73024
-/+ 缓冲区/缓存：23633 105546
交换：15624 0 15624

为什么 JVM 指示已提交 2.7GB 内存，但实际实际只有 1.6GB？其余内存到哪里去了？

解决方案 1：

我开始怀疑堆栈内存（与 JVM 堆不同）似乎是预先承诺的而没有成为常驻内存，并且随着时间的推移，只会在实际堆栈使用率达到高水位之前成为常驻内存。

是的，至少在 Linux 上，除非另有说明，否则 mmap 是惰性的。匿名页面只有在写入后才会由物理内存支持（由于零页优化，读取不够）

GC 堆内存实际上会受到复制收集器或预清零 ( -XX:+AlwaysPreTouch) 的影响，因此它将始终驻留。另一方面，线程堆栈不受此影响。

为了进一步确认，您可以使用pmap -x <java pid>并交叉引用各种地址范围的 RSS 与 NMT 的虚拟内存映射的输出。

保留的内存已使用 mmap 进行映射PROT_NONE。这意味着虚拟地址空间范围在内核的 vma 结构中有条目，因此不会被其他 mmap/malloc 调用使用。但它们仍会导致页面错误作为 SIGSEGV 转发到进程，即访问它们是错误的。

这对于拥有可供将来使用的连续地址范围非常重要，这反过来又简化了指针算法。

例如，已提交但未被存储支持的内存已被映射PROT_READ | PROT_WRITE，但访问它仍会导致页面错误。但该页面错误由内核默默处理，方法是用实际内存支持它并返回执行，就像什么都没发生一样。

也就是说，这是一个实现细节/优化，进程本身不会注意到。

对这些概念进行分解：

已用堆：根据上次 GC，活动对象占用的内存量

已提交：已使用 PROT_NONE 以外的其他内容映射的地址范围。由于延迟分配和分页，它们可能由物理或交换支持，也可能不支持。

保留：已mmap为特定内存池预映射的总地址范围。

保留- 已提交的差异由映射组成PROT_NONE，保证不会由物理内存支持

常驻：当前位于物理 RAM 中的页面。这意味着代码、堆栈、已提交内存池的一部分，以及最近访问过的 mmaped 文件的部分和 JVM 控制范围之外的分配。

虚拟：所有虚拟地址映射的总和。涵盖已提交、保留的内存池，也包括映射文件或共享内存。由于 JVM 可以提前保留非常大的地址范围或 mmap 大文件，因此此数字很少有参考价值。