thread.interrupt() 不依赖安全点，仅原子修改线程对象的 interrupted 字段；中断标志设置即时生效，真正响应延迟源于线程自身未检查或阻塞在不可中断操作中。
Thread.interrupt() 在 JVM 中并不依赖安全点（Safepoint）来设置中断标志位，它的核心动作是纯用户态的内存写操作——直接将目标线程对象中的 interrupted 布尔字段设为 true，这个过程完全不涉及 JVM 的 safepoint 机制。
中断标志位的设置是即时且无 safepoint 依赖的
调用 thread.interrupt() 时，JVM 只做一件事：原子地修改目标线程实例内部的中断状态字段。该字段位于 java.lang.Thread 对象中，属于 Java 堆上的普通字段。JVM 通过 CAS 或 volatile 写语义确保可见性，整个过程毫秒级完成，无需等待线程到达任何 safepoint。
这意味着：即使目标线程正执行密集计算、处于 JIT 编译后的 native 代码段、或卡在系统调用中（如 read() 阻塞），interrupt() 调用仍能立即返回，且中断标志已生效。
真正需要 safepoint 的场景是“强制挂起线程”而非“发中断信号”
JVM 的 safepoint 主要服务于 GC、类卸载、JIT 优化等全局操作，要求所有线程暂停并达到一致状态。但 interrupt() 不属于这类操作——它不暂停线程，也不改变线程调度权，只是写一个标记。
常见误解来源：当人们观察到“调用 interrupt() 后线程没立刻停”，便猜测是被 safepoint 拖延。实际上延迟来自线程自身逻辑，例如：
- 线程正在执行长循环，且未检查
isInterrupted() - 线程陷入不可中断的系统调用（如某些文件 I/O、本地 socket 阻塞），JVM 无法注入中断
- 线程持有锁并死循环，而中断标志无人读取
阻塞方法抛出 InterruptedException 的时机与 safepoint 无关
像 Thread.sleep()、Object.wait()、LockSupport.park() 这些可中断的阻塞点，其响应中断的机制是各自实现的轮询或内核通知，不是靠 JVM 在 safepoint 上统一检查中断位。
以 sleep() 为例：JVM 底层会调用操作系统定时器 + 线程状态机。一旦中断位为 true，且线程正处于 WAITING 状态，JVM 就主动唤醒它，并抛出 InterruptedException，同时清空中断标志——这一过程由线程自身的状态转换驱动，与 safepoint 无关联。
虚拟线程（Virtual Thread）进一步印证了无 safepoint 依赖
在 Project Loom 中，虚拟线程的 interrupt() 行为与平台线程一致：同样是设置字段 + 触发阻塞点的中断响应。而虚拟线程的调度完全在用户态完成，根本不存在传统 safepoint 概念。这也反向说明，中断机制的设计初衷就是轻量、异步、无全局停顿。
中断的本质是协作式通信，不是 JVM 的调度指令。它不需要线程配合停在某个位置，只需要线程在合适的地方读一次内存——而那次读，也从不被 safepoint 所约束。
