如何预测java.lang.OutOfMemoryError发生？多生产线数据采集应用内存求助

老哥，这种黑盒应用的内存预测问题我之前帮不少朋友处理过，给你几个落地的思路，能帮你提前预判OutOfMemoryError：

• 监控内存使用趋势，建立开销模型
  既然是黑盒，咱们就用JDK自带的工具盯紧内存变化。比如用jstat命令实时监控GC和堆内存状态：

  jstat -gcutil <你的应用PID> 1000 30
  

  这个命令会每1秒输出一次，共30次，重点看O（老年代使用率）和YGC/FGC（年轻代/Full GC次数）。每次添加生产线后，记录堆内存的峰值变化——比如第一条生产线占了400MB，第二条加完后冲到1200MB，这样就能算出每条生产线的平均内存增量（甚至可能是非线性的，比如后续生产线共享部分资源，增量会变小）。把这个数据整理成曲线，就能估算出加N条生产线需要的总内存。

  也可以用可视化工具jvisualvm（JDK自带，直接启动就行），连接到应用后看堆内存的实时走势图，更直观。

• 生成并分析堆快照，定位内存大户
  在添加生产线后、还没触发OOM时，用jmap生成堆快照：

  jmap -dump:format=b,file=production_heap.hprof <应用PID>
  

  然后用jvisualvm或者jhat打开这个.hprof文件，看哪些对象占了最多内存——比如是不是每条生产线都会创建一个常驻内存的连接池、缓存队列，或者未清理的日志对象。搞清楚每条生产线对应的内存占用大头，就能精准计算扩容所需的内存。

• 监控GC行为，捕捉OOM前兆
  OOM发生前，GC通常会出现异常：比如Full GC次数突然飙升，每次Full GC后老年代内存回收极少，甚至几乎没变化。用jstat -gc <PID>可以看到这些指标：

  • 如果FGC（Full GC次数）快速增加，FGCT（Full GC总耗时）占比越来越高，说明内存已经吃紧了；
  • 如果老年代使用率（O）持续维持在90%以上，而且每次Full GC后几乎没下降，那大概率是内存泄漏或者内存不足，离OOM不远了。

• 配置JVM预警，提前触发告警
  给JVM加几个参数，既能在OOM时留证据，也能配合脚本做提前预警：

  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/your/dump/path
  

  这样真的OOM时会自动生成堆快照，方便事后复盘。另外，你可以写个简单的shell脚本，定期执行jstat命令，当老年代使用率超过80%（或者你自定义的阈值）时，触发邮件/消息告警，这样在OOM发生前就能及时扩容。

• 模拟压力测试，验证预测模型
  逐步添加生产线，每次添加后稳定运行一段时间，记录内存峰值。比如先加3条，看内存用到多少；再加5条，看增长情况。重复几次后，就能验证你之前建立的内存开销模型是否准确，避免实际扩容时出现偏差。

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