java堆内存溢出需先排查内存泄漏或不合理使用，通过jstat、jmap分析gc和对象分布，生成heap dump并用mat定位泄漏源，再结合jvm参数调优与代码优化（如分页处理、缓存策略、资源释放）协同解决。
遇到 java.lang.OutOfMemoryError: Java heap space，说明堆内存已无法满足对象分配需求。这不是简单加堆就能解决的问题，关键在识别真实原因并针对性调优。
确认是否真为内存泄漏或不合理使用
堆溢出不等于内存泄漏，但泄漏是最隐蔽也最危险的原因。先看现象：
- Full GC 频繁发生，但每次回收后老年代占用率仍持续上升
- 应用运行时间越长，堆使用量“只增不减”，即使无明显流量增长
- 年轻代 GC（Minor GC）正常，但对象大量晋升到老年代且长期不被回收
此时应立即保留现场：避免重启，用 jstat -gc <pid></pid> 观察 GC 统计，用 jmap -histo <pid></pid> 快速查看对象分布，初步判断是否有异常类实例暴增。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
生成并分析 Heap Dump
生产环境建议提前开启自动转储：
- 启动参数加入：
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps/ - 若未配置，OOM 后进程已退出，可改用
jmap -dump:format=b,file=heap.hprof <pid></pid>（需进程仍在） - 用 MAT（Memory Analyzer Tool）打开 dump 文件，重点关注 “Leak Suspects Report” 和 “Dominator Tree”
- 重点排查：静态集合（
static List/Map）、未清理的ThreadLocal、缓存未设上限、监听器/回调未注销
调整 JVM 参数与代码优化同步进行
参数调优是辅助手段，不能掩盖设计缺陷：
- 堆大小设置要合理：
-Xms与-Xmx建议设为相同值，避免动态扩容开销；上限不宜超过物理内存的 75% - 关注新生代比例：
-XX:NewRatio=2（老:新 = 2:1）适合多数中长生命周期服务；若对象存活久，可适当增大老年代 - 代码层必须配合：大文件/大数据集务必分页或流式处理；缓存加
LRU或过期策略；资源使用严格遵循try-with-resources - 避免
new byte[1024 * 1024 * 100]类型的巨型对象直塞堆中，优先考虑堆外或磁盘临时缓冲
验证与监控闭环
修复后不能只看“不报错”，要建立可观测性：
- 上线后通过
jstat或 Prometheus + JVM Exporter 持续跟踪老年代使用趋势、GC 时间和频率 - 对比修复前后同一业务场景下的堆内存增长速率（如每万次请求新增对象数）
- 压测时模拟高峰流量，观察 Full GC 是否消失、老年代是否平稳，而非仅看平均响应时间
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
