PostgreSQL作为一款成熟的开源关系型数据库，在多线程与多进程并行的架构中需要多种锁机制来保障共享资源的安全访问。自旋锁SpinLock是其中最轻量的一类，专门用于保护极短时间的临界区。与常见的互斥锁不同，SpinLock在获取不到锁时并不会让进程睡眠，而是通过CPU空转不断尝试，这种特性决定了它只适合保护那些能在几个指令周期内完成的操作。
一、SpinLock的设计动机与适用场景
在数据库内核里，像缓冲区描述符状态位、轻量锁表元信息这类共享变量，被修改的频率极高，但每次修改只需要极短的时间。如果使用传统的互斥量（Mutex）或信号量，一旦竞争激烈，线程就会被挂起，陷入内核态，等待调度器重新唤醒，这种上下文切换的成本远远高于临界区本身的执行时间。PostgreSQL因此引入了SpinLock，用忙等换取更低的延迟。
不过SpinLock并非万能。因为它在等待期间持续占用CPU，如果临界区稍长或者锁冲突严重，就会看到某个CPU核心飙升到百分百，而实际业务推进缓慢。所以在源码中，SpinLock通常只出现在后端进程局部或共享内存中那些“一改即走”的地方，例如LWLock的底层获取路径、ProcArray的某些计数更新等。开发者在扩展或调试时应清楚这一点，避免滥用。
二、底层原子指令支撑
SpinLock能够正确工作的前提，是硬件提供原子性的“测试并置位”能力。在x86和x86_64架构上，PostgreSQL通过嵌入汇编或者使用编译器内置函数，执行带lock前缀的cmpxchg或直接使用tas（test and set）语义的指令。这类指令能保证在多核缓存一致性协议（如MESI）下，对同一个内存字的修改互斥可见。
下面是一段简化版的C语言风格伪代码，展示了SpinLock获取的核心逻辑，它不断读取锁变量，若为零则尝试原子地把它设为1：
// 简化自旋锁获取逻辑，实际PG使用汇编或pg_atomic接口
typedef volatile int slock_t;
static inline int
tas(slock_t *lock)
{
int old = 0;
// 原子比较并交换：若 *lock == 0，则设为 1，返回旧值
return __sync_val_compare_and_swap(lock, old, 1);
}
void
spin_lock(slock_t *lock)
{
// 自旋等待直到成功拿到锁
while (tas(lock) != 0)
{
// 可以适当插入pause指令降低总线压力
__asm__ __volatile__ ("pause" : : : "memory");
}
}
上面的代码中，__sync_val_compare_and_swap是GCC提供的原子内建函数，对应底层lock cmpxchg。若返回的不是0，说明锁已被别人持有，当前线程就会继续循环。真实PostgreSQL还会在循环一定次数后让出CPU或者报警，防止完全死占。
三、内存屏障与正确性保障
现代CPU和编译器都会对指令做重排以提升流水线效率，但在锁的实现里，必须保证“拿到锁之后的写操作”不会被挪到置位之前，也不能让“释放锁的写”滞后于临界区内的写。PostgreSQL在SpinLock的加锁与解锁处插入了恰当的内存屏障（memory barrier），在x86上读屏障相对便宜，写屏障通过lock指令顺带完成，而在弱内存模型平台如ARM则会使用dmb等指令。
这一点在排查诡异的并发bug时尤为关键。如果自行在扩展插件里用普通变量模拟自旋而没有屏障，很可能出现在A核看来锁已释放、但B核仍读到旧共享数据的情况。因此源码里的SpinLock封装不仅处理原子置位，也屏蔽了这些体系结构差异，提供给上层统一的s_lock和s_unlock接口。
四、与LWLock、Mutex的协作关系
SpinLock在PostgreSQL中往往作为更上层锁的构件。例如LWLock在真正修改等待队列前，会先短暂持有SpinLock；而当LWLock发现需要长等时，才切换成基于信号量的睡眠机制。这种分层设计兼顾了快路径与慢路径：绝大多数无冲突时刻走SpinLock的忙等，极快返回；真正冲突严重时交给操作系统调度，避免CPU空耗。
| 锁类型 | 等待方式 | 典型用途 | 开销特征 |
|---|---|---|---|
| SpinLock | 忙等自旋 | 极短临界区如状态位 | 无上下文切换，耗CPU |
| LWLock | 自旋+睡眠 | 缓冲区、锁表 | 平衡延迟与资源 |
| Mutex/信号量 | 睡眠 | 较长临界区 | 切换成本高但省CPU |
从上表可以看出，三种机制并非替代关系，而是按持有时间梯度排列。理解SpinLock底层，能帮助我们在阅读pg_stat_activity或perf采样时，分辨出哪些CPU热点来自合理的自旋、哪些来自错误的锁粒度设计。
五、实践中的观察与调优
在生产环境，若通过perf发现大量CPU周期消耗在s_lock函数内，通常意味着某个共享结构成为热点。此时应检查是否存在过多后端同时修改同一缓冲区头，或是否可以在业务层做分区降低冲突。PostgreSQL也提供了配置如spin_delay参数相关的内部计数，辅助判断自旋失败率。
另外在编写C扩展时，若必须自选实现类似保护，应优先调用PostgreSQL暴露的原子操作API，而不是手写volatile变量判断。这样既能获得跨平台屏障保证，也便于和未来版本的内核改动保持一致。只有摸清SpinLock从指令到封装的全链路，才能在复杂并发场景里做到心中有数。
PostgreSQLSpinLock并发控制修改时间：2026-08-12 02:21:36