Java中自旋锁需手动实现，常用AtomicBoolean配合compareAndSet和Thread.onSpinWait()实现非公平、不可重入的忙等待锁，仅适用于极短临界区，不支持中断与可重入，可扩展超时机制避免无限自旋。
Java 中自旋锁不能直接通过标准库调用，但可以用 AtomicBoolean 或 AtomicInteger 手动实现一个简单的、非公平的、不可重入的自旋锁。核心思想是：线程反复检查锁状态（“自旋”），直到成功获取锁为止，期间不释放 CPU。
用 AtomicBoolean 实现基础自旋锁
这是最常见、最易理解的实现方式。利用 compareAndSet 的原子性保证只有一个线程能成功设置锁标志。
public class SpinLock {
private final AtomicBoolean locked = new AtomicBoolean(false);
<pre class="brush:php;toolbar:false;">public void lock() {
while (!locked.compareAndSet(false, true)) {
// 自旋等待：线程忙等，不进入阻塞态
Thread.onSpinWait(); // JDK9+ 推荐，提示 JVM 当前在自旋（可优化指令/功耗）
}
}
public void unlock() {
locked.set(false);
}}
说明：
立即学习“Java免费学习笔记（深入）”；
-
lock()中循环调用compareAndSet(false, true)，只有当前锁未被占用（值为false）时才设为true并跳出循环；否则继续尝试。 -
Thread.onSpinWait()不是必须的，但比空循环更友好——它向 CPU 和 JVM 发出信号：这是一个短时自旋，有助于降低功耗、提升性能（如避免过度乱序执行）。 -
unlock()直接设为false即可，无需 CAS（因为只有持锁线程会调用它，且锁是独占的）。
注意事项与局限性
自旋锁看似简单，但实际使用需谨慎：
-
只适合临界区极短的场景：比如只做几次赋值、计数或简单判断。若临界区耗时稍长（如涉及 I/O、锁内调用外部方法），自旋会白白消耗 CPU，反而比
synchronized或ReentrantLock更差。 -
不支持可重入：同一线程重复调用
lock()会导致死锁（自己永远等不到false）。 - 无公平性保障：先自旋的线程不一定先拿到锁，完全依赖 CAS 竞争结果。
-
不处理中断：
lock()方法无法响应Thread.interrupt()，调用者需自行设计超时或退出机制（如加计数限制）。
带简单超时的自旋锁（增强实用性）
避免无限自旋，可加入最大尝试次数或纳秒级超时：
public boolean tryLock(long timeoutNs) {
long start = System.nanoTime();
while (System.nanoTime() - start < timeoutNs) {
if (locked.compareAndSet(false, true)) {
return true;
}
Thread.onSpinWait();
}
return false;
}这样调用方可以控制等待上限，失败后可降级为其他同步机制（如阻塞锁或重试策略）。
和 Java 原生锁的关系
需要明确的是：
- JVM 对
synchronized在轻量级锁膨胀前就用了类似自旋优化（称为“自适应自旋”），但这是 JVM 内部行为，开发者不可控也不需手动模拟。 -
java.util.concurrent.locks.Lock接口及其实现（如ReentrantLock）默认不自旋，但可通过tryLock()配合循环实现用户态自旋逻辑——这比手写底层自旋锁更安全、功能更全（支持中断、超时、条件队列等）。 - 真正需要手写自旋锁的场景极少，常见于高性能底层组件（如无锁队列、Disruptor 等）或教学演示。
