自旋锁是CPU在原地循环检测锁状态而非让出CPU，虽省上下文切换但易致高CPU空转；MySQL可通过innodb_spin_wait_delay和innodb_sync_spin_loops调优，PostgreSQL隐式使用LWLock自旋，Redis“自旋锁”实为客户端重试逻辑。
自旋锁不是“锁住就完事”，而是“CPU在原地打转等锁”
自旋锁在数据库（如 MySQL InnoDB、PostgreSQL、SQL Server）里，本质是线程发现锁被占了，不交出 CPU，而是在一个循环里反复检查——test_and_set 是否成功。它省掉了上下文切换开销，但代价是：只要没拿到锁，这个线程就在空跑，吃 CPU。
常见错误现象：
• top 或 htop 显示某个数据库进程 CPU 占用长期 90%+，但 QPS 并不高
• SHOW ENGINE INNODB STATUS 里频繁看到 spin waits 或 os_waits 计数飙升
• PostgreSQL 的 pg_stat_activity 中大量会话卡在 active 状态，但实际没执行 SQL
- 这不是数据库“卡死”，而是线程在自旋——它还在跑，只是没进展
- 真正持有锁的线程可能已阻塞（比如等磁盘 I/O、等网络响应），导致自旋线程无限等下去
- 别急着调高并发连接数——更多线程自旋 = 更多 CPU 白烧
MySQL 的 innodb_spin_wait_delay 和 innodb_sync_spin_loops 怎么调才不翻车
MySQL InnoDB 默认会自旋 30 次（innodb_sync_spin_loops=30），每次间隔约 6 微秒（由 innodb_spin_wait_delay=6 控制）。但这不是“越小越好”或“越大越稳”，得看你的硬件和负载特征。
- SSD + 高频短事务场景：可适当降低
innodb_spin_wait_delay（如设为2），让自旋更积极——因为锁释放确实快 - 高并发更新同一行/页（如计数器表）：增大
innodb_sync_spin_loops反而加剧争用，建议直接设为0，强制跳过自旋，走睡眠等待 - 虚拟机或容器环境：注意
innodb_spin_wait_delay的单位是“微秒”，但宿主机调度抖动可能远超这个量级，此时自旋基本无效，还白耗 CPU —— 建议统一设为0
实操建议：先用 SELECT @@innodb_spin_wait_delay, @@innodb_sync_spin_loops; 查当前值；修改后观察 SHOW ENGINE INNODB STATUS 中的 Spin rounds per wait 是否明显下降，且 OS Waits 未激增。
PostgreSQL 里看不到 “spin lock” 报错？那是它藏在 pg_locks 和等待事件里
PG 不暴露 spin lock 统计给用户，但它真实存在——尤其在共享缓冲区、WAL buffer、clog 等内存结构上。你不会看到 “spin lock timeout”，但会看到线程卡在 BufferPin、Lock 或 LWLockNamed 等等待事件上，背后往往就是 spin lock 在起作用。
- 查实时等待：运行
SELECT pid, wait_event_type, wait_event, state FROM pg_stat_activity WHERE wait_event IS NOT NULL;，重点关注wait_event_type = 'LWLock'的会话 - 典型高自旋信号：多个会话同时等待
buffer_content或clog类 LWLock，且state = 'active'—— 这说明它们正在自旋抢内存锁，而非休眠 - 别迷信
shared_buffers调大就能缓解：如果热点数据页集中（如索引根页、频繁更新的元数据页），增大缓存只会让更多线程挤在同一个 spin lock 上
Redis 实现的“自旋锁”根本不是内核级 spin lock，别拿它对标数据库
Redis 里所谓“自旋锁”，其实是客户端用 SET key value NX EX 30 循环重试实现的业务层逻辑。它不涉及 CPU 自旋，也不消耗服务端 CPU——所有“自旋”都在客户端进程里。
- 服务端视角：每次
SET ... NX是一个普通命令，失败就返回(nil)，不阻塞、不自旋 - 客户端视角：你代码里写了个
while (!tryLock()) { Thread.sleep(10); }，这才是真正在“自旋”——但消耗的是应用服务器的 CPU，跟 Redis 无关 - 风险点：若客户端 sleep 时间太短（如
1ms），大量请求密集刷 Redis，可能触发连接数/OPS 限流；若太长（如500ms），又导致锁获取延迟毛刺
真正要注意的，是这种模式下锁的可靠性：没有自动续期、没有看门狗、超时即失效——和数据库里靠事务生命周期或 WAL 保证的锁，完全不在一个抽象层级上。
复杂点在于：数据库自旋锁是底层基础设施，你没法绕过；而 Redis “自旋锁”是你自己写的逻辑，容易误以为“我控制了锁”，其实只控制了获取动作，锁的语义全靠你补全。