Java应用响应变慢时，应优先监控STW停顿时长与频次：Full GC＞500ms即明显卡顿，＞1s影响核心链路；Young GC＞100ms高频叠加亦拖慢吞吐；需用jstat算平均停顿、对齐业务日志定位因果、结合top/jstack排除非GC阻塞，并在长停顿后抓堆快照用MAT分析泄漏。
Java 应用响应变慢，如果怀疑是 GC 停顿导致，关键不是等卡顿发生后再翻日志，而是主动盯住停顿本身——特别是每次 STW（Stop-The-World）的时长和频次。停顿时间直接决定用户是否“感知卡顿”，它比 GC 次数更贴近真实体验。
看单次停顿是否超标
GC 停顿超过阈值，就大概率成为性能瓶颈：
- Full GC 单次停顿 > 500ms：用户明显卡顿，需立即介入
- Full GC 单次停顿 > 1s：已影响核心链路，可能触发超时或熔断
- Young GC 单次停顿 > 100ms：虽短但高频，叠加后仍会拖慢吞吐
用 jstat -gc
对齐业务日志找停顿发生时刻
GC 停顿不是孤立事件，要和接口响应时间、错误日志、发布动作对齐：
javascript-typescript-typescript-scaffold
下载
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
立即学习“Java免费学习笔记（深入）”；
- 开启带时间戳和 STW 标记的 GC 日志：-Xlog:gc*,gc+heap=debug:time,uptime,tags -XX:+PrintGCApplicationStoppedTime
- 当某次请求 RT 突增到 800ms，去查同一秒的 GC 日志，若出现 Stopped: 0.642s，基本可锁定因果关系
- 特别注意 Pause Full 或 Pause Young 后紧跟着业务异常，这种时间耦合是强线索
区分停顿来源是 GC 还是其他线程阻塞
不是所有“响应慢”都等于“GC 停顿”，得排除干扰：
- 用 top -Hp
查高 CPU 线程，再 jstack 搜 VM Thread 或 GC task thread —— 若它们占用高，说明 GC 正在密集工作 - 若大量业务线程处于 WAITING 或 TIMED_WAITING，且堆内存稳定、GC 频次不高，那可能是锁或 I/O 阻塞，不是 GC 问题
- 对比 CPU 使用率：GC 导致的卡顿常伴随 CPU 升高（GC 线程吃资源）；纯等待型卡顿则 CPU 可能偏低
抓准时机做堆快照验证泄漏假设
频繁长停顿往往不是配置问题，而是对象无法释放：
- 在一次明显长停顿（如 >800ms Full GC）刚结束后，立刻执行：jmap -dump:live,format=b,file=heap.hprof
- 用 MAT 打开快照，重点看 Dominator Tree：是否存在单个对象占几百 MB？比如未清理的缓存 Map、堆积的日志 List
- 运行 Leak Suspects Report：MAT 会自动标出疑似泄漏路径，例如 static HashMap → ThreadLocal → 未 remove 的上下文对象
