LockSupport不能用于构建非阻塞调度器，因其park/parkNanos会使线程进入WAITING/TIMED_WAITING状态，属阻塞式等待；非阻塞调度需全程用户态自旋（如onSpinWait+CAS），不交出CPU调度权。
LockSupport 不能用于构建“非阻塞”调度器——只要调用了 park 或 parkNanos，线程就进入 TIMED_WAITING 或 WAITING 状态，这属于**阻塞式等待**。所谓“非阻塞调度器”，必须全程在用户态自旋（如 Thread.onSpinWait() + CAS），不交出 CPU 调度权。
为什么“动态权重调整 + LockSupport”组合天然矛盾
调度器若依赖 park 实现线程挂起，就无法做到：
- 权重变更的实时生效（unpark 只能唤醒，不能“插队”或“降级”已 parked 的线程）
- 每次权重更新都需重新计算等待时长，但 parkNanos 一旦调用就不可中断修改（除非被中断或超时）
- park 不感知业务语义，无法根据权重决定“该等多久”，只能靠外层循环重试
常见错误是写一个“按权重 sleep 不同时间”的轮询器，例如：
if (weight == 1) LockSupport.parkNanos(1_000_000); // 1ms else if (weight == 5) LockSupport.parkNanos(5_000_000); // 5ms
这实际是伪权重：OS 调度抖动可能让 1ms 等待变成 8ms，而 5ms 变成 3ms，权重关系完全失效。
真正可行的“权重感知”调度必须基于自旋 + 许可预占
如果你需要响应式权重调整（比如高优先级任务插入后，低权线程立刻让出 CPU），唯一路径是：
- 用 AtomicInteger 或 VarHandle 维护全局权重快照
- 工作线程循环检查自身权重是否仍为当前最高，否则调用 Thread.onSpinWait()
- 新任务提交时，通过 CAS 更新权重并用 Unsafe.storeFence() 刷新可见性
- 关键点：不调用任何 park，不进入内核态
示例节选：
while (!tryAcquireTask()) {
if (currentWeight < globalMaxWeight.get()) {
Thread.onSpinWait(); // 用户态轻量让步
continue;
}
// 权重足够，继续尝试获取任务
}注意：onSpinWait() 在 Java 9+ 才有，Java 8 只能用 Unsafe.pause() 替代。
如果非要混合 park，只能做粗粒度协作式退让
某些场景下（如后台 IO 轮询线程），可以接受“每轮最多等 X ms”，此时 parkNanos 是合理选择，但必须满足：
- 权重仅影响 单次 park 时长，而非实时调度决策
- 每次 park 前重新读取权重值（避免缓存旧值）
- 总等待时间由外层 deadline 控制，不是靠 park 精确累加
正确模式：
long start = System.nanoTime();
long deadline = start + TimeUnit.MILLISECONDS.toNanos(10);
while (!taskReady() && System.nanoTime() < deadline) {
long nanos = weightToNanos(currentWeight); // 如 weight=3 → 300_000ns
LockSupport.parkNanos(nanos);
if (Thread.interrupted()) break;
}这里 weightToNanos 只是启发式退让策略，不是调度保证；parkNanos 的实际延迟仍由系统决定，不能假设它会“按权重比例休眠”。
最易被忽略的一点：所有基于 park 的逻辑，一旦涉及“公平性”“优先级”“动态调整”，就必须放弃对唤醒时间的任何确定性假设——parkNanos 的纳秒参数只是 hint，不是契约。
