为什么JVM报告的内存比linux进程驻留集大小更多？

Question

当运行启用了本机内存跟踪的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上的应用程序显示：

Native Memory Tracking:

Total: reserved=4023326KB, committed=2762382KB
-                 Java Heap (reserved=1331200KB, committed=1331200KB)
                            (mmap: reserved=1331200KB, committed=1331200KB) 

-                     Class (reserved=1108143KB, committed=64559KB)
                            (classes #8621)
                            (malloc=6319KB #17371) 
                            (mmap: reserved=1101824KB, committed=58240KB) 

-                    Thread (reserved=1190668KB, committed=1190668KB)
                            (thread #1154)
                            (stack: reserved=1185284KB, committed=1185284KB)
                            (malloc=3809KB #5771) 
                            (arena=1575KB #2306)

-                      Code (reserved=255744KB, committed=38384KB)
                            (malloc=6144KB #8858) 
                            (mmap: reserved=249600KB, committed=32240KB) 

-                        GC (reserved=54995KB, committed=54995KB)
                            (malloc=5775KB #217) 
                            (mmap: reserved=49220KB, committed=49220KB) 

-                  Compiler (reserved=267KB, committed=267KB)
                            (malloc=137KB #333) 
                            (arena=131KB #3)

-                  Internal (reserved=65106KB, committed=65106KB)
                            (malloc=65074KB #29652) 
                            (mmap: reserved=32KB, committed=32KB) 

-                    Symbol (reserved=13622KB, committed=13622KB)
                            (malloc=12016KB #128199) 
                            (arena=1606KB #1)

-    Native Memory Tracking (reserved=3361KB, committed=3361KB)
                            (malloc=287KB #3994) 
                            (tracking overhead=3075KB)

-               Arena Chunk (reserved=220KB, committed=220KB)
                            (malloc=220KB) 

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

但是，在运行ps ax -o pid,rss | grep <mypid>或top时，它只显示1.6GB的RES/rss驻留内存。检查交换说没有使用：

free -m
             total       used       free     shared    buffers     cached
Mem:        129180      99348      29831          0       2689      73024
-/+ buffers/cache:      23633     105546
Swap:        15624          0      15624

为什么JVM表示只有1.6GB驻留时会提交2.7GB内存？其余的去哪了？

Answer 1

  

我开始怀疑堆栈内存（与JVM堆不同）似乎是在没有成为常驻的情况下预先提交的，并且随着时间的推移变成仅驻留在实际堆栈使用的高水位线上。

是的，除非另有说明，否则malloc / mmap是懒惰的。一旦他们被访问，页面仅由物理内存支持。

GC堆内存有效地被复制收集器或预置零（-XX:+AlwaysPreTouch）触及，因此它始终是驻留的。线程堆栈otoh不受此影响。

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

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

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

已提交但未备份的存储内存已映射 - 例如 - PROT_READ | PROT_WRITE但访问它仍会导致页面错误。但是，内核通过用实际内存支持并返回执行就好像没有发生任何事情来静默处理该页面错误。
即它是一个实现细节/优化，不会被流程本身注意到。

详细说明概念：

已用堆：根据上一次GC实时对象占用的内存量

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

保留：通过mmap为特定内存池预先映射的总地址范围。
保留 - 已提交区别由PROT_NONE映射组成，保证不会被物理内存支持

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

虚拟：所有虚拟地址映射的总和。涵盖已提交，保留的内存池以及映射文件或共享内存。这个数字很少提供信息，因为JVM可以提前预留非常大的地址范围或mmap大文件。