locksupport 无法实现优先级抢占，因其仅提供被动阻塞/唤醒，不参与 os 或 jvm 的调度决策；真正可中断高性能同步需结合 volatile 状态、while 循环检查、cas 控制及正确 unpark 顺序。
不能直接用 LockSupport 实现“优先级抢占”——它本身不提供线程优先级调度能力，也不参与 OS 层的抢占逻辑。所谓“优先级抢占”必须由 JVM 或操作系统配合完成，LockSupport 只负责阻塞/唤醒，且唤醒是被动、非抢占式的。
为什么 park/unpark 无法实现真正抢占
LockSupport.park() 把线程挂起后，线程状态变为 WAITING，但是否能被立即调度执行，完全取决于 JVM 线程调度器和底层 OS（如 Linux 的 CFS 调度器）。即使你对目标线程调用了 Thread.setPriority()，现代 JVM（尤其是 HotSpot）已基本忽略该设置；JDK 文档也明确说明：setPriority 不保证任何语义，仅作尽力提示。
-
unpark(t)只是给t发一个 permit，不强制 CPU 切换上下文 - 如果
t所在 CPU 正在运行高优先级任务（如 GC 线程、IO 中断处理），它仍需排队等待调度 - 没有机制让
t“插队”中断当前正在运行的其他线程 —— 这不是LockSupport的职责，也不是用户态能控制的
可中断 + 高性能的正确组合方式
真正的“可中断高性能同步组件”，关键在于：用 park 降低空转开销，用循环条件 + 中断检查保障响应性，再靠 CAS 和 volatile 控制状态流转。典型结构如下：
- 状态变量用
volatile int state或AtomicInteger，避免锁竞争 - 核心等待逻辑必须包裹在 while 循环中：
while (!conditionMet()) { LockSupport.park(this); if (Thread.interrupted()) throw new InterruptedException(); } - 每次
park前应确保blocker参数传入（如this），否则jstack看不到阻塞点，线上排查等于盲人摸象 - 唤醒方必须在更新共享状态后，再调用
LockSupport.unpark(target)，顺序不能颠倒
容易踩的三个坑
实际编码中最常导致“看似可中断实则卡死”的错误：
- 在
synchronized块内调用park()：它不释放 monitor，可能造成持有锁的线程被 park，而其他线程因抢不到锁无限等待 —— 表象是“中断无效”，本质是锁未释放 - 忽略中断状态残留：若线程在
park()返回后未调用Thread.interrupted()清除状态，下一次park()可能立刻返回（因中断位仍为 true），导致忙等或逻辑跳过 - 误用
parkNanos当定时器：传100_000纳秒 ≠ 100 微秒唤醒，实测延迟常达毫秒级；真要精准，得用System.nanoTime()+ 自旋，但务必限制自旋次数，否则耗尽 CPU
复杂点在于：所有“抢占感”都来自上层状态设计（比如用优先队列管理等待线程，再按序 unpark），而非 LockSupport 本身。它只是肌肉，不是大脑。
