Java内存溢出需精准定位区域并协同调优：堆参数-Xms与-Xmx应设为相同值（如-Xms2g -Xmx2g），Metaspace须显式限制（-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m），GC策略依业务选择G1或Parallel并配套调优，务必开启GC日志与自动堆转储。
Java内存溢出（OutOfMemoryError）本质是JVM某块内存区域耗尽，无法继续分配。解决它不能只靠“加内存”，关键在于精准识别溢出区域、合理配置参数、配合代码与监控协同治理。
堆内存参数：-Xms 与 -Xmx 必须设为相同值
这是最基础也最容易被忽略的调优点。若-Xms=512m而-Xmx=2g，JVM在运行中会动态扩容堆，每次扩容都可能触发Full GC，带来明显停顿和性能抖动。统一设置可避免伸缩开销，提升GC可预测性。
- 推荐写法：-Xms2g -Xmx2g（根据服务物理内存的1/4～1/2起步，如16G机器可先试2g）
- 不要盲目堆大：超过4g后，Parallel GC停顿显著增长；建议超3g堆优先启用G1或ZGC
- 年轻代不是越大越好：-Xmn过大，会压缩老年代空间，反而加剧老年代GC压力；可通过jstat -gc观察Eden区回收频率和Survivor占用率来微调
元空间（Metaspace）必须显式限制
Java 8+已废弃永久代，类元数据改存Metaspace。若不设上限，动态加载大量类（如热部署、反射生成类、Groovy脚本）会无限扩张，最终OOM：Metaspace。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 必加参数：-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m
- 若应用含大量第三方库或频繁类加载，可逐步提高MaxMetaspaceSize至512m，但需配合jstat -gcmetacapacity验证实际使用峰值
- 注意：Metaspace不足时，JVM会先尝试Full GC来卸载无用类；持续增长说明存在类加载器泄漏，需结合jstack + MAT分析ClassLoader实例引用链
GC策略要匹配业务特征，不止选收集器
光加-XX:+UseG1GC不够，还需配套调优目标。不同场景下，同一收集器表现差异巨大。
立即学习“Java免费学习笔记（深入）”；
- 对延迟敏感（如API网关）：-XX:+UseG1GC -XX:MaxGCPauseMillis=200，并配合-XX:G1HeapRegionSize=1M（小堆适用）
- 高吞吐批处理（如定时报表）：-XX:+UseParallelGC -XX:ParallelGCThreads=4，更关注总耗时而非单次停顿
- 务必开启GC日志：-Xlog:gc*:file=gc.log:time,tags,level -Xlog:safepoint（JDK 11+），用于判断是否出现“GC overhead limit exceeded”
自动抓取堆转储，让OOM现场可回溯
等OOM发生再手动dump，往往错过关键现场。应提前配置自动触发机制，把问题“冻结”下来。
- 核心参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/app/logs/heap.hprof
- 建议追加：-XX:ErrorFile=/opt/app/logs/hs_err_%p.log，记录崩溃时的线程栈、寄存器、内存映射等底层信息
- 拿到.hprof文件后，用MAT打开 → Leak Suspects Report → 点击“Details”查看强引用路径，重点关注static字段、缓存Map、未关闭的Connection/Stream等典型泄漏源
