JDK 16通过Stack Watermark Barrier实现并发线程栈扫描，彻底消除此前必须STW扫描线程栈的瓶颈；该机制让线程在方法返回时自主检查水印并进入安全状态，GC线程可并发扫描，使最大暂停时间降至0.5ms以内。
Java中ZGC在JDK 16正式引入并发线程栈扫描，彻底消除了此前必须STW（Stop-The-World）处理线程栈的瓶颈；JDK 17延续并稳定了这一机制，未做结构性变更，但增强了兼容性与运行时健壮性。
为什么JDK 16之前线程栈处理必须STW
在JDK 16以前，ZGC虽已实现大部分阶段并发，但“线程栈扫描”仍需暂停所有应用线程。原因在于：栈帧中可能包含指向堆内对象的引用，GC必须精确识别这些根引用才能保证标记完整性。而当时缺乏安全、低开销的在线读取机制，只能等所有线程到达安全点后统一扫描——线程越多、调用栈越深，停顿时间越长，且呈线性增长。
并发线程栈扫描的核心机制：Stack Watermark Barrier
JDK 16通过JEP 376引入Stack Watermark Barrier，本质是一种轻量级的栈帧访问拦截机制：
- 每个Java线程维护一个或多个“水位标记（watermark）”，标识当前栈中哪些区域可被GC线程安全扫描
- 当线程执行返回操作（如方法返回）时，若栈顶位置超出watermark，会自动触发slow path，将若干栈帧“带入安全状态”（例如插入屏障指令、刷新局部变量表）
- GC线程可随时并发遍历已处于安全状态的栈帧，无需等待全局安全点
- 该机制不依赖传统load barrier，而是嵌入在栈帧返回路径中，开销极低（压测显示平均增加约0.5% CPU）
JDK 17对并发栈扫描的实际影响
JDK 17作为长期支持版本（LTS），主要聚焦于稳定性与生产就绪：
立即学习“Java免费学习笔记（深入）”；
- 修复了JDK 16中偶发的watermark同步偏差问题（尤其在高频率线程创建/销毁场景）
- 优化了多线程竞争下watermark更新的CAS逻辑，降低自旋失败率
- 增强对JNI本地栈帧的兼容处理，避免因本地代码绕过Java栈管理导致漏标
- 日志与诊断工具（如-XX:+PrintGCDetails）新增栈扫描并发进度指标，便于定位延迟毛刺来源
启用与验证并发栈扫描的关键点
该功能默认启用，无需额外参数，但需确保：
- 使用ZGC：启动时指定-XX:+UseZGC
- 堆大小无硬性限制，但建议≥4GB以体现优势（小堆下STW原本就很短，收益不明显）
- 通过GC日志确认是否生效：查找类似“Concurrent stack processing: true”或“Pause reason: No stack processing needed”字样
- 若观察到单次GC pause > 0.5ms且频繁出现，应检查是否存在大量native线程或未正确释放的ThreadLocal对象——它们可能干扰watermark推进
