在压力测试中提前发现内存泄漏需三步联动：一是监控老年代使用率持续抬升和GC效率断崖下降；二是压测各阶段主动抓取堆转储并用MAT对比Retained Heap增长；三是结合线程与资源生命周期交叉验证，Java 21+推荐用StructuredTaskScope约束虚拟线程。

在压力测试中提前发现内存泄漏，关键不是等 OOM 出现，而是通过“趋势观察 + 主动采样 + 引用追踪”三步联动，在问题显性化前就捕获苗头。

监控堆内存与 GC 行为的异常趋势

内存泄漏不会突然爆发，而是表现为可测量的渐进式恶化。压测时重点盯住两个指标：

• 老年代（Old Gen）使用率持续抬升：用 jstat -gcutil <pid> 2000</pid> 每两秒看一次，如果 OU（Old Usage）从 40% → 60% → 85% 单向爬升，且每次 Full GC 后回落幅度越来越小（比如只降 2%～3%），基本可判定存在泄漏。
• GC 效率断崖下降：压测中观察 GC 日志，若出现“Full GC 后老年代仅回收几十 KB”，或“GC overhead 超过 98%”，说明大量对象长期存活且无法释放。

在压测周期内主动抓取多份堆转储对比

不要只等 OOM 才 dump。建议在压测不同阶段（如第 1 分钟、第 5 分钟、第 10 分钟）各执行一次：

• jmap -dump:live,format=b,file=heap_1m.hprof <pid></pid>
• jmap -dump:live,format=b,file=heap_5m.hprof <pid></pid>
• jmap -dump:live,format=b,file=heap_10m.hprof <pid></pid>

用 MAT 打开后，对比三份文件的 Dominator Tree，重点关注：
哪些类的 Retained Heap 增长最快？
哪些对象的 Shallow Heap × 实例数 在持续放大？
它们是否都指向同一个静态容器、未关闭的连接、或监听器注册表？

sc-java-to-ts-interface

将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。

下载

结合线程与资源生命周期做交叉验证

很多泄漏本质是资源没释放，而资源往往绑定在线程或请求上下文里。压测中同步检查：

• 用 jcmd <pid> VM.native_memory summary</pid> 看直接内存是否同步上涨（提示 NIO 或 JNI 泄漏）；
• 用 jstack <pid> | grep -A5 -B5 "BLOCKED\|WAITING"</pid> 查看是否有大量线程卡在 close()、await() 或数据库 fetch 上；
• Spring Boot 应用可打开 /actuator/metrics/jvm.memory.used?tag=area:heap 和 /actuator/threaddump 接口，把指标和线程快照一起纳入压测报告。

用结构化任务作用域约束虚拟线程生命周期（Java 21+）

若压测中启用了虚拟线程，需特别防范“任务未完成却无感知”的隐性泄漏。推荐写法：

• 不用 newVirtualThreadPerTaskExecutor() 无限提交，改用 StructuredTaskScope；
• 所有 I/O 操作必须设超时：Timeout.withTimeout(Duration.ofSeconds(5), () -> blockingCall())；
• 避免在虚拟线程中持有 ThreadLocal 大对象，改用方法参数传递轻量上下文。

这样即使某个任务卡死，作用域关闭时会强制中断并释放其栈上引用，大幅降低泄漏概率。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南