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 <p>注意：<code>onSpinWait()</code> 在 Java 9+ 才有，Java 8 只能用 <code>Unsafe.pause()</code> 替代。</p><h3>如果非要混合 park，只能做粗粒度协作式退让</h3><p>某些场景下（如后台 IO 轮询线程），可以接受“每轮最多等 X ms”，此时 <code>parkNanos</code> 是合理选择，但必须满足：
- 权重仅影响 <strong>单次 park 时长</strong>，而非实时调度决策
- 每次 park 前重新读取权重值（避免缓存旧值）
- 总等待时间由外层 deadline 控制，不是靠 park 精确累加</p><p>正确模式：</p><pre class="brush:php;toolbar:false;">long start = System.nanoTime();
long deadline = start + TimeUnit.MILLISECONDS.toNanos(10);
while (!taskReady() && System.nanoTime() <p>这里 <code>weightToNanos</code> 只是启发式退让策略，不是调度保证；<code>parkNanos</code> 的实际延迟仍由系统决定，不能假设它会“按权重比例休眠”。</p><p>最易被忽略的一点：所有基于 <code>park</code> 的逻辑，一旦涉及“公平性”“优先级”“动态调整”，就必须放弃对唤醒时间的任何确定性假设——<code>parkNanos</code> 的纳秒参数只是 hint，不是契约。</p>
