安全区域是JVM自动管理的静态可信区间，用于解决Sleep/Blocked线程无法响应GC中断的问题；线程在sleep前、wait后、锁竞争失败时等位置主动报备“已安全”，JVM据此跳过轮询直接STW，并在唤醒时检查GC是否结束。

安全区域（Safe Region）不是由开发者手动“使用”的功能，它完全由 JVM 自动识别和管理。你不需要写代码去声明、进入或退出安全区域，也不需要配置参数来启用它——它是 HotSpot 虚拟机底层 GC 机制的内置保障逻辑。

安全区域在哪发生？

它出现在线程主动放弃 CPU 控制权、即将进入不可执行状态的那些典型位置：

• 调用 Thread.sleep(long) 之后、OS 线程真正挂起之前：JVM 插入检查点，确认栈帧和引用关系已冻结
• Object.wait() 执行完释放锁、加入 WaitSet、状态切换为 WAITING 后：此时对象引用不再变动
• synchronized 竞争失败，准备进入 Monitor Contention Queue 时：线程尚未阻塞，但已停止修改 Java 堆引用
• JNI 方法返回 Java 层前的过渡阶段（部分 JVM 实现）：本地代码退出，Java 上下文恢复前做安全快照

它怎么起作用？

核心是“提前报备 + 延迟确认”两步：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 线程判断自己已处于语义稳定状态（如 wait 结束、sleep 将启），就设置本地标志 in_safe_region = true，并通知 JVM：“我已静止，GC 可跳过轮询”
• JVM 在 STW 阶段发现该线程已标记，直接将其视为“已暂停”，不等待、不中断、不重试，加快 GC Roots 枚举速度
• 线程被唤醒后，第一件事不是继续执行，而是检查 GC 是否结束；若仍在进行，就在原地等待（仍在安全区域内，引用关系不变）

为什么不能靠 SafePoint 解决？

SafePoint 要求线程主动走到指定指令点才能停，但 Sleep/Blocked 状态的线程不执行字节码，收不到中断信号，也无法“走到”任何点。安全区域绕开了这个限制——不等它动，而是确认它已经不动且安全。

对开发者意味着什么？

你无需干预，但需理解其存在带来的实际影响：

• 频繁调用 wait() 或 sleep() 的线程，在 GC 期间停顿时间更可控，不会拖慢 STW
• 在锁竞争激烈或大量 JNI 调用的场景中，安全区域能缓解 GC 延迟尖刺
• 它和 OopMap、SafePoint 共同构成 GC 可靠性的底层三角，确保任意时刻都能准确枚举存活对象