自旋锁与互斥锁对比及使用场景分析

自旋锁并非万能的性能加速器，其真正优势仅存在于临界区极短（

自旋锁在什么情况下比互斥锁快？

只在临界区极短（通常 SpinLock 才可能比 synchronized 或 ReentrantLock 快。它的优势不是“绝对快”，而是避免线程挂起/唤醒的开销——但代价是持续占用 CPU。

• 适用场景：高频率、超轻量操作，比如计数器自增、状态位翻转、无锁队列的 head/tail 更新
• 不适用场景：任何涉及 I/O、内存分配、方法调用或不确定耗时的操作——这时自旋就是在烧 CPU
• JVM 不会优化自旋等待为 yield 或 park，纯靠忙等，Thread.onSpinWait()（Java 9+）只是提示 CPU 可能有缓存同步意图，不保证行为

Java 标准库有没有真正的自旋锁实现？

没有。java.util.concurrent 里所有公开锁（ReentrantLock、StampedLock）底层在争用时都最终走向 Unsafe.park()，即阻塞式等待。所谓“自旋”，仅存在于部分锁的 acquire 前置尝试阶段（如 ReentrantLock 非公平模式下的一次 CAS 尝试），但不是完整自旋锁语义。

• AtomicInteger 的 compareAndSet() 是自旋基础，但不是锁；要手写自旋锁，得自己循环 + Thread.onSpinWait() + 退出条件
• 第三方库如 JCTools 的 MpmcArrayQueue 内部有自旋逻辑，但封装极深，不建议直接复用其锁机制
• 别信网上“用 while(true) + CAS 实现自旋锁”的简单示例——缺退出策略、缺退避、缺可中断性，生产环境等于埋雷

为什么在多核机器上自旋锁反而更容易拖垮性能？

因为自旋本身不释放 CPU 时间片，多个线程在不同核心上死等同一个锁，会同时触发缓存行在核心间反复无效化（cache line bouncing），导致 L3 缓存带宽饱和、内存控制器压力陡增。

• 现象：CPU 使用率接近 100%，但吞吐量不升反降，perf stat 显示 high LLC-load-misses
• 典型误用：在 Web 应用中对单个 ConcurrentHashMap 实例做高频 putIfAbsent()，以为“无锁”就安全，实则内部 hash 桶竞争引发自旋恶化
• 解决方案不是换锁，而是减少共享——用 ThreadLocal、分段设计（如 LongAdder）、或改用消息队列解耦

ReentrantLock 的 spinForTimeoutThreshold 参数到底影响什么？

这个隐藏参数（默认 1000 纳秒）控制的是 AQS 中“自旋等待超时阈值”：当请求锁的剩余等待时间 > 此值，线程会先自旋若干轮；否则直接 park。但它只对 tryLock(long, TimeUnit) 生效，对普通 lock() 无影响。

• 修改方式只能通过反射篡改 AbstractQueuedSynchronizer 类的静态字段，不推荐
• 实际效果非常有限：现代 JVM 在 Contended Lock 场景下，自旋收益已远不如内核调度器的 park/unpark 效率
• 真正该调的是 JVM 参数：-XX:PreBlockSpin（仅 HotSpot 早期版本支持，JDK 10+ 已移除），现在连这个都没了

自旋锁不是性能银弹，它是把“线程调度延迟”换成“CPU 资源浪费”的权衡。很多人卡在“为什么我加了自旋反而更慢”，答案往往藏在 cache 一致性协议和 JVM 对 park 的深度优化里——这些地方，连 profilers 都不太爱报。

到这里，我们也就讲完了《自旋锁与互斥锁对比及使用场景分析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！