OOM本质是内存分配与回收失衡，需分层控制堆内对象、堆外资源及运行时结构，优化配比、淘汰策略、大对象处理、堆外内存管理及监控节拍器。
Java内存溢出（OOM）本质不是“内存不够”，而是内存分配节奏与回收效率失衡——需求涨得快、释放跟不上、空间用得糙。真正要解决的，不是一味加堆，而是让内存“够用、好用、不卡顿”。
关键在于分层控制：堆内对象、堆外资源、运行时结构
堆内存不是越大越好
-Xmx设到8G，若新生代只占1G，大量短生命周期对象挤在Eden区反复触发Minor GC，反而拖慢吞吐；若老年代长期堆积未清理的对象，Full GC频发，STW时间飙升。建议按业务特征配比：
- 高吞吐后台服务：年轻代占堆30%~40%，Survivor比例调高（如-XX:SurvivorRatio=6），减少晋升
- 响应敏感型应用：适当增大年轻代，启用G1或ZGC，开启-XX:+UseStringDeduplication（JDK8u20+）减少重复字符串
缓存必须带边界和淘汰策略
无限制的HashMap或静态List缓存是泄漏高发区。
- 用
Caffeine替代手写Map，配置maximumSize + expireAfterWrite - 若必须用WeakReference/SoftReference，注意：SoftReference在内存压力大时才回收，不能当“自动清空开关”；WeakReference适合监听器、代理等临时强引用场景
- 大对象（如图片、报表）避免长期驻留堆内，优先落地到磁盘或对象存储，内存中只存ID或轻量元数据
别忽略堆外内存和线程栈
-
ByteBuffer.allocateDirect()分配的直接内存不受-Xmx控制，需配合-XX:MaxDirectMemorySize（默认≈-Xmx），并确保显式调用cleaner.clean()或使用try-with-resources - 每个线程默认栈大小（-Xss，默认1M），高并发下线程数×栈大小可能压垮系统。若业务逻辑浅，可降至256K～512K；更优解是用虚拟线程（JDK21+）替代传统线程池
监控不是事后补救，而是日常节拍器
- 开启JVM基础指标：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log - 用Prometheus + JMX Exporter采集
java.lang:type=MemoryPool各区域使用率，设置告警阈值（如老年代持续>75%） - 每周抽样一次堆转储（jmap -dump:format=b,file=heap.hprof
），用MAT查“Leak Suspects”和“dominator tree”，重点看HashMap、ConcurrentHashMap、ThreadLocalMap里的value是否异常滞留
不复杂但容易忽略：多数OOM不是突发，而是缓慢爬升——从GC频率增加、老年代使用率月均上升0.5%开始，到崩溃往往有2～3周窗口期。定期看一眼，比重启十次更省事。
立即学习“Java免费学习笔记（深入）”；
