Java应用堆内存设为256MB但实际内存占用过高，求排查思路

碰到这种Java进程实际内存占用远大于堆配置的情况很常见，毕竟JVM的内存开销可不只是堆这一块。我给你梳理几个实用的排查方向，一步步来定位问题：

JVM本身提供了一堆工具，能帮你快速区分堆、非堆和本地内存的占用情况，比直接上gdb高效多了：

• Native Memory Tracking (NMT)：这是首选工具！启动应用时加上-XX:NativeMemoryTracking=summary（如果要更详细的信息用detail），运行一段时间后执行jcmd <pid> VM.native_memory summary。它会把JVM的所有本地内存开销拆分成线程栈、Metaspace、Code Cache、JNI内存、直接内存等类别，一目了然哪块占了大头。你说没显式分配直接缓冲区，但有些NIO操作或者第三方库可能隐式用了，NMT能查出来。
• jmap -heap ：能看到堆的各个区域（Eden、Survivor、Old）的实际使用，以及非堆的Metaspace、Compressed Class Space的大小。确认这些非堆区域是不是超了预期——比如Metaspace如果加载了大量类，或者Code Cache因为JIT编译了太多代码，都会占用不少内存。
• jstat -gc 1000：持续观察堆的GC情况，确认堆的实际峰值（比如Old区的最大使用）是不是真的在256M以内，排除堆内存碎片导致的虚拟内存膨胀（不过VmHWM是进程的物理内存峰值，堆碎片更多是虚拟内存的问题）。

线程栈是很容易被忽略的内存大户：

• 用jstack <pid>统计线程数量，如果你的应用有几百上千个线程，每个线程栈默认在64位HotSpot里是1M，那光线程栈就占了几百M，直接加到RSS里。你是处理文件系统事件，会不会线程池配置不合理，或者每个事件都新开线程？
• 另外，线程的本地存储（比如JNI调用时分配的内存）也可能占用，这部分NMT会统计在JNI内存类别里。

如果JVM工具没找到问题，就去看进程的内存映射：

• 用pmap -x <pid>查看进程的所有内存区域，重点看匿名映射（通常是JVM的堆、非堆、线程栈）和共享库的占用。大的匿名块对应JVM的内存区域，你可以对比NMT的结果来对应。
• 用smem -t -k -p -u <pid>查看PSS（按比例共享的内存），能区分进程独占的内存和与其他进程共享的内存（比如系统库），更准确地看到进程实际占用的物理内存。

如果确实需要用gdb分析，先做这些准备：

• 先用jmap -dump:format=b,file=heap_dump.hprof <pid>生成堆转储，用MAT（Memory Analyzer Tool）或者VisualVM分析堆内对象，确认堆内内存是不是真的在256M左右。
• 用gdb attach到进程后，执行info proc mappings可以看到整个进程的地址空间，其中：
  • 堆区域通常是大的匿名映射，大小接近你的Xmx配置；
  • Metaspace和Code Cache也会对应到匿名或文件映射区域（Linux上Metaspace可能映射到/dev/zero）。
• 生成core dump的话，执行gdb -p <pid> -ex "gcore core.<pid>" -ex quit，但core dump是整个进程的内存，体积很大，优先用JVM专用的堆转储工具。

你用NIO处理文件系统事件，比如WatchService，本身开销不大，但要注意：

• 有没有用第三方文件处理库？有些库可能隐式使用JNI或直接内存；
• 事件处理逻辑里会不会创建大量临时对象？虽然堆内存限制了256M，但频繁GC可能导致堆内存碎片，不过这通常影响虚拟内存，而不是RSS的高水位。

先从NMT开始排查，几乎能覆盖90%的这类问题，确定了内存开销的类别再深入就容易多了。

内容的提问来源于stack exchange，提问作者St.Antario