Java内存泄漏预防规范需建立可执行、可检查、可融入流程的约束机制，聚焦5类高频OOM问题，配套编译期拦截、CI/CD卡点、IDE提示及运行期防御措施。
制定 Java 内存泄漏预防编码规范，核心不是罗列“禁止做什么”，而是建立可执行、可检查、可融入开发流程的约束机制。重点在于把常见泄漏场景转化为具体代码规则，并配套验证手段。
聚焦高频泄漏点，定义明确禁令与替代方案
规范需直击生产环境最常引发 OOM 的 5 类问题，每条都包含“风险操作 + 原因简述 + 推荐写法”：
-
静态集合滥用：禁止
static List/Map直接缓存业务对象；改用WeakHashMap或带过期策略的Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES) -
监听器未解绑：所有
addXXXListener必须配对removeXXXListener，且注册/反注册逻辑必须在同一生命周期钩子中（如 Android 的onResume/onPause） -
内部类强引用外部实例：非静态内部类禁止直接访问外部类字段或方法；优先用
static class+ 回调接口，或显式使用WeakReference<outer></outer>持有 -
资源未关闭：所有实现
AutoCloseable的类型（InputStream、Connection、ExecutorService等）必须用try-with-resources，禁止finally中手动close() -
虚拟线程阻塞调用：禁止在虚拟线程中调用
Thread.sleep()、Object.wait()或同步 IO；改用Timeout.withTimeout()或异步 NIO 封装
嵌入开发流程，让规范自动生效
规范不能只贴在 Wiki 上。必须通过工具链强制落地：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
-
编译期拦截：用 ErrorProne 或 Google Java Format 配置自定义检查规则，例如检测到
static Map, ?>声明时直接报错 -
CI/CD 卡点：在流水线中加入字节码扫描（如 JArchitect），发现
Outer$Inner类含this$0字段且被static或线程池持有，即阻断发布 -
本地 IDE 提示：为团队统一配置 IntelliJ Inspection，对未关闭资源、匿名内部类捕获
this、ThreadLocal未remove()等场景实时标黄并给出修复建议
配套运行期防御，弥补编码疏漏
再严格的规范也无法覆盖所有边界情况，需叠加运行时兜底措施：
立即学习“Java免费学习笔记（深入）”；
-
启动参数强制防护：JVM 启动时统一加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dump/，确保泄漏发生时有分析依据 -
关键组件内置清理逻辑：自研的缓存工具类、事件总线、线程池封装层，必须内置
clearOnShutdown()或destroy()方法，并在 Spring@PreDestroy中调用 -
定期堆快照巡检：对核心服务，每日凌晨自动触发
jcmd <pid> VM.native_memory summary</pid>和HeapDump，用脚本比对VirtualThread、ThreadLocal、Finalizer实例数趋势
规范的生命力在于持续反馈。每次线上内存问题复盘后，必须更新对应条款，并同步到所有开发者的 IDE 和 CI 检查中。不靠人盯，而靠机制闭环。
