Java进程内存使用情况（jcmd vs pmap）
我在一个docker容器内的Java 8上运行了一个java应用程序。 该过程启动Jetty 9服务器并部署Web应用程序。 传递以下JVM选项： -Xms768m -Xmx768m 。
最近我注意到这个过程耗费了大量的内存：
$ ps aux 1 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND app 1 0.1 48.9 5268992 2989492 ? Ssl Sep23 4:47 java -server ... $ pmap -x 1 Address Kbytes RSS Dirty Mode Mapping ... total kB 5280504 2994384 2980776 $ jcmd 1 VM.native_memory summary 1: Native Memory Tracking: Total: reserved=1378791KB, committed=1049931KB - Java Heap (reserved=786432KB, committed=786432KB) (mmap: reserved=786432KB, committed=786432KB) - Class (reserved=220113KB, committed=101073KB) (classes #17246) (malloc=7121KB #25927) (mmap: reserved=212992KB, committed=93952KB) - Thread (reserved=47684KB, committed=47684KB) (thread #47) (stack: reserved=47288KB, committed=47288KB) (malloc=150KB #236) (arena=246KB #92) - Code (reserved=257980KB, committed=48160KB) (malloc=8380KB #11150) (mmap: reserved=249600KB, committed=39780KB) - GC (reserved=34513KB, committed=34513KB) (malloc=5777KB #280) (mmap: reserved=28736KB, committed=28736KB) - Compiler (reserved=276KB, committed=276KB) (malloc=146KB #398) (arena=131KB #3) - Internal (reserved=8247KB, committed=8247KB) (malloc=8215KB #20172) (mmap: reserved=32KB, committed=32KB) - Symbol (reserved=19338KB, committed=19338KB) (malloc=16805KB #184025) (arena=2533KB #1) - Native Memory Tracking (reserved=4019KB, committed=4019KB) (malloc=186KB #2933) (tracking overhead=3833KB) - Arena Chunk (reserved=187KB, committed=187KB) (malloc=187KB)
正如您所看到的，RSS（2,8GB）与VM本机内存统计实际显示的内容之间存在巨大差异（提交1.0GB，保留1.3GB）。
为什么会有如此巨大的差异？ 我知道RSS也显示了共享库的内存分配，但是在分析了pmap详细输出之后，我意识到它不是共享库的问题，而是内存被某些东西所消耗，称为[anon]结构。 为什么JVM分配了这么多匿名内存块？
我正在搜索并发现以下主题： 为什么JVM报告的内存比linux进程驻留集大小更多？ 然而，描述的情况有所不同，因为RSS显示的内存使用量少于JVM统计数据。 我有相反的情况，无法弄清楚原因。
我在我们的Apache Spark工作中遇到了类似的问题，我们将应用程序作为胖jar提交，在分析了线程转储之后，我们认为Hibernate是罪魁祸首，我们曾经在应用程序的启动时加载hibernate类，这实际上正在使用java.util.zip.Inflater.inflateBytes读取hibernate类文件，这超过了我们的本机驻留内存使用量几乎1.5 gb，这是hibernate为此问题引发的错误https://hibernate.atlassian.net/browse/ HHH-10938？attachmentOrder = desc ，评论中建议的补丁对我们有用 ，希望这有帮助。
根据以下文章进行深入分析后： https ： //gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/ we发现问题与java.util.zip.Inflater的内存分配有关。
仍需要找出调用java.util.zip.Inflater.inflateBytes的内容并寻找可能的解决方案。
NMT仅跟踪由JVM管理的部分内存，它不跟踪本机第三方库或内存映射/直接字节缓冲区使用的内存。