自旋锁不阻塞线程，靠cas忙等抢锁，cpu时间片持续运行但空耗；高争用时易占满单核，应配合thread.onspinwait()、合理退避策略及临界区特性优化。
Java里用AtomicInteger写自旋锁，为什么死循环不卡主线程？
因为自旋锁本身不阻塞线程，它靠反复调用compareAndSet抢锁，CPU时间片还在跑，只是不做别的事。但这也意味着：如果锁竞争激烈或持有时间长，while(!cas)会白占CPU，吞性能。
- 别在高争用场景（比如10+线程抢同一把锁）直接裸写自旋，容易把一个核跑满
-
compareAndSet失败后建议加Thread.onSpinWait()（JDK9+），提示CPU当前是忙等，可能触发底层优化（如降频、让出流水线） - 注意JVM参数：
-XX:+UsePauselessGC或ZGC下，自旋对GC线程干扰更小；但CMS或Parallel GC时，自旋期间若触发STW，可能延长停顿
自旋次数设多少才合理？硬编码100还是用指数退避？
固定次数太僵硬——短临界区可能10次就拿到锁，长临界区100次根本不够；指数退避又容易拖太久。实际看的是「平均持锁时间」和「线程数」。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 如果临界区操作稳定在微秒级（如计数器++），用固定小值（
16~64）足够，再失败就让出（Thread.yield()）或升级为阻塞锁 - 涉及I/O或不确定耗时的代码，别自旋，直接上
synchronized或ReentrantLock - 避免用
System.nanoTime()算耗时来控制自旋——获取纳秒时间本身就有开销，且不同CPU TSC频率可能不一致
Unsafe.compareAndSwapInt比AtomicInteger.compareAndSet快吗？
几乎没差别。现代JDK中AtomicInteger.compareAndSet就是内联调用Unsafe.compareAndSwapInt，JIT还会做进一步优化。手动用Unsafe反而增加维护成本和安全隐患。
-
Unsafe操作绕过Java内存模型校验，容易写出违反happens-before的代码（比如漏掉volatile语义） - JDK17开始
Unsafe很多方法被标记为@Deprecated(forRemoval = true)，未来会被移除 - 真要极致性能，优先考虑减少锁粒度或用无锁数据结构（如
ConcurrentLinkedQueue），而不是抠Unsafe那点指令
自旋锁和ReentrantLock的tryLock()有什么本质区别？
tryLock()是「尝试一次即返回」，而自旋锁是你自己写的「尝试N次再放弃」逻辑。关键差异不在CAS本身，而在是否交由AQS调度。
-
tryLock()失败后，线程状态仍是RUNNABLE；但若后续调用lock()，就会进AQS队列并可能挂起（WAITING/TIMED_WAITING） - 纯自旋锁全程不进AQS，不参与线程调度排队，所以没有唤醒开销，但也得不到操作系统级别的公平性保障
- 混合方案常见：先自旋几十次，失败后走
ReentrantLock.lock()，兼顾低争用响应速度和高争用资源效率
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
