Java应用测试服务器每日内存不足宕机，Jprofiler未检出泄漏求排查方案

• 优先在故障服务器采集真实运行数据，不要仅依赖本地模拟：给Java进程添加JVM启动参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/your/path/heapdump.hprof -XX:+PrintGCDetails -Xloggc:/your/path/gc.log，下次OOM时会自动生成堆转储文件和GC日志，数据精准度远高于本地测试环境。
• 分析堆转储文件：使用MAT（Eclipse Memory Analyzer）或者Jprofiler打开dump文件，重点排查占比最高的大对象、持续增长未被回收的存活对象、静态集合类持有的未释放对象、未清理的ThreadLocal实例、未设置过期策略的第三方缓存组件，尤其注意非业务代码引入的中间件、依赖包的内存占用。
• 多时间点堆快照对比：如果不想等OOM触发，可以在服务运行6小时、12小时、24小时三个时间点，分别执行jmap -dump:format=b,file=dump_$(date +%Y%m%d%H%M).hprof <Java进程PID>手动生成堆快照，对比不同快照中同类型对象的数量变化，只增不减的对象即为泄漏嫌疑点。
• 排除JVM配置问题：检查-Xmx（最大堆内存）、-Xms（初始堆内存）、新生代老年代比例、元空间上限等参数是否合理，过小的堆内存配置会导致频繁GC甚至OOM，容易和内存泄漏混淆。

• 非Java进程挤占内存：服务器上运行的数据库、缓存、定时任务、监控Agent等其他进程未做内存限制，会持续占用系统内存，最终触发系统OOM Killer杀掉优先级较低的Java进程。可执行dmesg | grep -i oom查看系统日志，确认是否为OOM Killer主动杀掉的进程。
• 堆外内存泄漏：如果Java应用使用了Netty、JNI调用、DirectByteBuffer，或是依赖的中间件用到了堆外内存，这部分内存不受-Xmx限制，默认的性能剖析工具也不会主动监控，很容易被遗漏。可添加JVM参数-XX:MaxDirectMemorySize限制堆外内存上限，或是开启NMT（Native Memory Tracking）监控堆外内存变化。
• 系统缓存占用过高：Linux系统会自动用空闲内存做文件页缓存、缓冲区缓存，如果应用有大文件读写、超大量日志打印的场景，会导致系统缓存占用过高，可用内存不足触发OOM。
• 物理内存碎片化：服务器长期未重启，大量小内存块的申请和释放会导致物理内存碎片化，即使总可用内存足够，也无法分配出连续的大块内存供进程使用，最终引发内存申请失败崩溃。

内容的提问来源于stack exchange，提问作者Bittu Kumar