自旋锁仅在临界区极短且线程能快速获取锁时比互斥锁快；否则因CPU浪费和缓存一致性开销反而更慢，现代JVM已优化park/unpark，自旋收益甚微。

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

只在临界区极短（通常 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 缓存带宽饱和、内存控制器压力陡增。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

• 现象：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 都不太爱报。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南