system.nanotime() 不适合直接控制自旋锁退避时间，因其调用开销大、跨cpu精度不可靠，且退避需按轮次分阶段而非绝对纳秒值。
不能用 System.nanoTime() 直接控制自旋锁的退避时间——它本身就有可观开销，且纳秒级精度在不同 CPU 上不可靠，更不适合作为“休眠时长”的依据。
为什么 nanoTime 不适合做退避计时
自旋锁退避的核心目标是：前期快速尝试（避免调度），后期逐步让出 CPU（节省资源）。而 System.nanoTime() 是一个高精度但高成本的系统调用：
- 每次调用需访问 CPU 的 TSC（时间戳计数器），在某些虚拟化环境或频率动态调整的 CPU 上，结果可能跳变或不准；
- 用它反复判断“是否超时”，会把本该省下的上下文切换开销，换成密集的硬件访存和分支预测失败；
- 退避策略真正需要的是“轮次”和“阶段感”，不是绝对纳秒值——比如“前 4 轮自旋，第 5 轮 parkNanos(100_000)”，而非“自旋满 237892 纳秒后休眠”。
正确做法：用轮次 + onSpinWait + parkNanos 混合控制
真实高性能同步器（如 AQS）采用分阶段退避，nanoTime 只用于超时判定，不参与循环节奏：
- 初始阶段（例如 0–3 轮）：纯自旋 +
Thread.onSpinWait()，向 CPU 发出提示，降低功耗并减少流水线冲突； - 中期阶段（例如 4–7 轮）：每轮后调用
Thread.yield()或短时parkNanos(1000)（注意不是 1 纳秒）； - 后期阶段（例如 >7 轮）：改用
parkNanos(10_000)以上，并传入 blocker（如this），确保 jstack 可定位； - 所有 parkNanos 前，必须用 volatile 读或 CAS 再检查一次状态，防止虚假唤醒跳过条件判断。
超时控制仍可用 nanoTime，但仅锚定起点
如果你需要整体等待不超过 500ms，可以用 nanoTime 记录起始点，全程只比对差值：
long start = System.nanoTime();- 每次进入新阶段前，计算
System.nanoTime() - start是否已超阈值； - 一旦超时，直接退出重试循环，不继续 park 或自旋；
- 整个过程不依赖
nanoTime控制单次自旋时长，只用于全局截止判断。
实际代码中要避开的坑
几个高频错误写法需警惕：
- ❌
while (nanoTime() - start —— 空转中频繁调用 nanoTime，CPU 白耗； - ❌
parkNanos(TimeUnit.NANOSECONDS.toNanos(1))—— JVM 对纳秒级无保障，实测等效于 park，还多一次单位转换； - ❌ 在 synchronized 块内调用 park() —— 锁不会释放，极易死锁；
- ❌ 自旋轮数写死为 100 —— 应结合当前竞争强度（如 CAS 失败次数）动态调整，例如
spins = Math.min(1 。
