安全点对阻塞线程完全失效，仅作用于运行中线程；安全区域则允许阻塞线程主动标记“已就绪”，GC无需唤醒即可基于其冻结引用快照工作，退出时轻量协同检查确保一致性。
安全点和安全区域在线程阻塞时的行为差异，本质是“能否主动响应中断”带来的质变：安全点依赖线程主动走到指定位置才能停，而安全区域允许线程在无法执行的状态下被直接视为“已就绪”，无需唤醒或移动。
安全点对阻塞线程完全失效
安全点只对正在运行的线程起作用。当线程处于 sleep、wait、park、blocked on monitor 等状态时，它不执行任何字节码，自然不会走到方法调用、循环跳转等预设的安全点位置。此时即使 JVM 设置了中断标志，该线程也无法轮询、无法检查、无法挂起——它根本没在“跑”，轮询机制彻底失能。
安全区域填补了这个不可控空档
安全区域不是某个指令位置，而是一段语义上“引用关系冻结”的代码区间。线程进入该区间（如调用 Object.wait() 前、Thread.sleep() 开始前）会主动标记自己“已入安全区域”。此后：
- JVM 发起 GC 时，会跳过所有已标记为安全区域的线程，不等待、不唤醒、不轮询；
- 这些线程仍保持阻塞状态，但其栈帧和局部变量中的对象引用关系已被认定为稳定不变；
- GC 可以安全地基于当前快照完成根节点枚举与对象标记，无需它们参与同步停顿。
退出时的协同检查才是关键动作
线程从阻塞中恢复（如 wait 被 notify、sleep 时间到）准备离开安全区域时，会做一次轻量检查：
- 若 GC 已结束 → 清除标记，继续执行；
- 若 GC 仍在进行 → 当前线程暂停在“出口处”，等待 GC 完成信号再离开。
这个检查发生在用户态，开销极低，且避免了让休眠线程强行“醒过来走一步再睡”的荒谬操作。
一句话总结质变所在
安全点要求线程“动起来配合停”，安全区域则让线程“静下来也被信任”——前者是运行时协作机制，后者是语义级信任契约。阻塞场景下，后者把“不可控等待”转化为了“可确认安全”，这是 GC 能真正实现低延迟停顿的核心设计之一。
