Java内存泄漏排查必须嵌入研发全流程：开发阶段用CI拦截静态集合无清理、资源未关闭等风险；测试上线前执行内存基线压测与配置校验；线上通过分级告警自动取证；复盘环节沉淀模式库并强制新人MAT实操训练。
Java内存泄漏排查不能靠个人经验临时发挥，必须形成可执行、可检查、可传承的团队规范。落地关键不是写文档，而是把动作嵌入日常研发流程，让每个环节都有明确输入、输出和责任人。
开发阶段：强制代码守门机制
在编码源头卡住高频泄漏点，避免问题流入测试或生产：
- 静态集合类必须配套清理策略——新增
static Map或List时，PR中需注明生命周期管理方式（如定时清理、LRU淘汰、弱引用包装），否则CI自动拦截 - 所有资源型对象（
Connection、InputStream、ByteBuffer.allocateDirect()）必须用try-with-resources或显式close()，SonarQube规则开启S2095（资源未关闭）和S2275（DirectBuffer未清理）告警 - 禁止在Spring Bean中持有非托管对象引用（如ThreadLocal未remove、监听器未反注册），统一使用
@PreDestroy或DisposableBean做兜底清理
测试与上线前：内存基线校验流程
把“不泄漏”变成可量化的准入条件，而非模糊判断：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 每日构建后自动启动轻量压测（模拟10分钟中等流量），采集
jstat -gc PID 2000 10数据，要求老年代使用率波动幅度≤15%，Full GC次数为0；不达标则阻断发布 - 每个服务上线前必须提交《内存配置说明》：明确
-Xms/-Xmx设置依据、是否启用-XX:+HeapDumpOnOutOfMemoryError、堆外内存预估用量，由架构组复核签字 - 灰度发布时强制开启GC日志（
-Xloggc:/logs/gc.log -XX:+PrintGCDetails），首小时监控FGC频率和O（老年代使用率）趋势，异常立即回滚
线上监控：分级告警与自动取证
让泄漏在影响用户前被发现，并自动生成分析线索：
立即学习“Java免费学习笔记（深入）”；
- 监控平台配置三级阈值：
• 黄色（预警）：老年代使用率连续5分钟＞75%且上升斜率＞2%/min
• 橙色（介入）：jstat显示FGC间隔＜10分钟 或 单次FGCT＞1.5s
• 红色（应急）：触发OOM前自动执行jmap -dump:live,format=b,file=/dump/heap_$(date +%s).hprof PID - 每台应用服务器部署轻量巡检脚本，每30分钟检查
/proc/[pid]/status中VmRSS与JVM堆上限偏差，若超20%则上报堆外内存异常 - 所有Heap Dump文件自动上传至共享存储，命名含环境、时间、PID，并触发MAT自动扫描，生成
Leak Suspects Report邮件同步给负责人
复盘闭环：根因归档与模式沉淀
把每次排查转化为团队能力资产，避免重复踩坑：
- 每次定位到泄漏根因后，48小时内更新《团队内存泄漏模式库》，包含：泄漏代码片段、MAT分析截图、修复前后内存曲线对比、对应Sonar规则ID
- 每月召开15分钟“内存快闪会”，由当月问题解决人分享1个真实案例，重点讲清“为什么当时没在开发阶段发现”，推动规则迭代
- 新成员入职第一周必须完成3个典型泄漏场景的MAT实操练习（静态缓存、ThreadLocal未清理、DirectBuffer泄露），通过后方可提交代码
