在压力测试中提前发现内存泄漏需三步联动：一是监控老年代使用率持续抬升和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、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
结合线程与资源生命周期做交叉验证
很多泄漏本质是资源没释放，而资源往往绑定在线程或请求上下文里。压测中同步检查：
- 用
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大对象，改用方法参数传递轻量上下文。
这样即使某个任务卡死，作用域关闭时会强制中断并释放其栈上引用，大幅降低泄漏概率。
