并发之锁介绍

涉及并发操作时，必然会面临共享资源的抢占问题，而锁正是解决这一问题的核心同步机制。

核心原理就是把并发操作，改为顺序执行操作。

一、简介

"锁"是一种用于控制对共享资源访问 的机制，广泛应用于计算机系统、操作系统、数据库、多线程编程、分布式系统 等领域。其核心目标是保证数据一致性、防止竞态条件（Race Condition）和避免并发错误。

举个例子：

想象一个公共洗澡间，一次只能容纳一个人使用。当有人进入时，会从内部上锁，防止其他人闯入；只有当前使用者洗完离开并解锁后，下一位人才能进入。

这正是锁（Lock）的基本原理 ：当多个线程（或进程）竞争同一个有限且不可同时共享的资源（如内存、文件、设备等）时，通过"加锁"确保同一时刻仅有一个访问者，从而避免混乱和数据错误；使用完毕后"释放锁"，允许其他等待者继续使用。

软件锁的发展：

时间	里程碑事件 / 技术	贡献者 / 系统	核心思想与意义
1965年	信号量（Semaphore）提出	Edsger W. Dijkstra	首次形式化解决进程互斥与同步问题，引入 P/V 操作（`wait/signal`），成为并发控制基石。
1967年	管程（Monitor）概念提出	Per Brinch Hansen（后由 C.A.R. Hoare 完善）	将共享数据与操作封装在一起，自动提供互斥访问，影响后续高级语言设计（如 Java）。
1970年代初	临界区（Critical Section）与互斥锁（Mutex）在操作系统中实现	Unix、THE 操作系统	内核提供基本互斥原语，用于保护共享资源，成为多任务系统标配。
1981年	Peterson 算法发表	Gary L. Peterson	纯软件实现双线程互斥，无需硬件原子指令，在理论层面证明软件可解决互斥问题。
1980s	自旋锁（Spinlock）广泛用于多处理器内核	BSD Unix、Linux 内核早期版本	适用于短临界区，避免上下文切换开销，但消耗 CPU。
1980s--1990s	读写锁（Read-Write Lock）引入	多种 Unix 变体	支持多读者并发，提升读密集型场景性能。
1990s	条件变量（Condition Variable）成为标准同步原语	POSIX Threads (pthreads)	与互斥锁配合，实现线程等待/唤醒机制（如生产者-消费者模型）。
1995年	Java 1.0 引入 `synchronized` 关键字	Sun Microsystems	基于 JVM 的内置管程机制，自动加锁/释放，简化线程安全编程。
2004年	JDK 5 发布 `java.util.concurrent` 包	Doug Lea 等	引入 `ReentrantLock`、`ReadWriteLock`、`Semaphore` 等高级锁，支持公平性、可中断、超时等特性。
2000s 中期	无锁编程（Lock-Free Programming）兴起	多家高性能系统（如数据库、交易系统）	利用 CPU 原子指令（如 CAS - Compare-and-Swap）构建无锁队列、计数器，避免锁开销与死锁。
2010s	分布式锁成为微服务基础设施	Redis、ZooKeeper、etcd	解决跨节点资源竞争问题，如：Redis 的 `SET key value NX PX` + RedLock；ZooKeeper 临时顺序节点。
2010s--至今	替代锁的并发模型普及	Go（goroutine + channel）、Erlang（Actor）、Rust（所有权模型）	"不要通过共享内存来通信，而要通过通信来共享内存"，减少对传统锁的依赖。

二、锁分类

2.1 按重量级分类

重量级层级	包含的锁 / 同步机制	说明
1. 无锁（Lock-Free / No Locking）	• CAS（Compare-And-Swap）原子操作 • `AtomicInteger` / `AtomicReference` 等原子类 • 无锁队列（Lock-Free Queue） • 无锁栈、无锁哈希表 • Disruptor 环形缓冲区	不使用传统锁，依赖 CPU 提供的原子指令（如 x86 的 `cmpxchg`）实现线程安全。线程永不阻塞，但冲突时需重试。适用于简单状态更新或高性能并发数据结构。
2. 轻量级锁（Lightweight Lock）	• 自旋锁（Spin Lock） • JVM 轻量级锁（Lightweight Locking） • Ticket Lock（票锁） • MCS Lock • 读写自旋锁（Read-Write Spinlock） • 用户态互斥（User-space Mutex，无竞争时）	在用户态通过忙等（自旋）或 CAS 实现互斥，不触发线程挂起或内核切换。适合临界区极短、竞争低的场景。高竞争时通常会"膨胀"为重量级锁。
3. 重量级锁（Heavyweight Lock）	• 操作系统 Mutex（如 pthread_mutex） • JVM 重量级锁（即 `synchronized` 在竞争激烈时的状态） • Linux futex（Fast Userspace Mutex） • 信号量（Semaphore，当用作互斥且涉及阻塞时） • 条件变量（Condition Variable） • ReentrantLock（默认非公平模式，在阻塞等待时） • 文件锁（flock, lockf）	依赖操作系统内核调度，线程在无法获取锁时被挂起（阻塞），由 OS 唤醒。涉及用户态 ↔ 内核态切换，开销大，但适合长时间持有锁或高竞争环境，避免 CPU 空

根据具体场景的时候选择决定使用什么级别的锁。

特性	无锁	轻量级锁	重量级锁
是否阻塞线程	否	否（忙等）	是（挂起）
是否进入内核	否	否	是
CPU 开销	低（但冲突时重试多）	中（自旋消耗 CPU）	高（上下文切换）
延迟	极低	低（短临界区）	高（唤醒有延迟）
适用场景	简单原子操作、高频低冲突	短临界区、低竞争	长临界区、高竞争或必须阻塞
典型代表	`AtomicInteger`、CAS 操作	JVM 轻量级锁、自旋锁	`synchronized`（竞争时）、`pthread_mutex`

2.2 按作用范围分类

分类依据：竞争主体是谁？资源在哪个层级共享？

作用范围决定了"锁如何被感知和传递" 。

不同范围的锁，底层实现完全不同，不能混用。例如，Java 的 ReentrantLock 对分布式场景完全无效。

类型	说明	典型场景
线程级锁（Thread-level Lock）	用于同一进程内多个线程之间的互斥访问，保护共享内存中的临界区，是多线程编程中最基础的同步机制。	Java `synchronized`、C++ `std::mutex`
进程级锁（Process-level Lock）	用于同一台机器上不同进程之间协调对共享资源（如文件、设备）的访问，通常依赖操作系统提供的 IPC 机制实现。	文件锁（`flock`）、System V 信号量、Windows Mutex
分布式锁（Distributed Lock）	用于跨多台服务器的分布式系统中，确保在集群环境下对全局唯一资源（如任务调度、库存扣减）的互斥访问，需解决网络延迟、节点故障等挑战。	Redis 锁、ZooKeeper 临时节点、etcd lease

按"作用范围"分类，是从系统架构层面回答："这把锁能管住谁？"

2.2.1 . 线程级锁（Thread-level Lock）

用于同一进程内多个线程之间的互斥同步，保护共享内存中的临界区资源。

原理

所有线程共享同一地址空间，可直接访问同一把锁对象（如内存中的 mutex 变量）。
加锁/解锁操作通常由语言运行时或操作系统线程库（如 pthread）提供。
不涉及进程间通信或网络，开销最小。

典型实现

语言/平台	实现方式
Java	`synchronized`、`ReentrantLock`、`ReadWriteLock`
C++	`std::mutex`、`std::shared_mutex`（C++17）
Python	`threading.Lock`、`RLock`
Go	虽鼓励 channel，但提供 `sync.Mutex`、`RWMutex`
POSIX	`pthread_mutex_t`

适用场景

多线程修改全局变量、单例初始化、线程安全集合等。
示例：Web 服务器中多个请求线程并发更新用户会话缓存。

* 注意事项

仅对同进程内的线程有效，跨进程无效。
死锁、优先级反转等问题仍需防范。

伪代码（java）

复制代码

// 共享资源
int counter = 0;
Object lock = new Object(); // 锁对象

// 多个线程执行以下逻辑
void increment() {
    synchronized (lock) {        // ← 获取线程级锁
        counter = counter + 1;   // ← 临界区（受保护）
    }                            // ← 自动释放锁
}

synchronized 是 JVM 提供的线程级互斥锁。
所有线程运行在同一个 JVM 进程内 ，共享 counter 和 lock。
跨进程无效（如另一个 Java 进程无法感知此锁）。

2.2.2 进程级锁（Process-level Lock）

用于同一台机器上多个独立进程之间协调对共享资源（如文件、设备、共享内存）的访问。

原理

进程内存空间隔离，无法直接共享普通锁变量。
必须依赖操作系统提供的 IPC（进程间通信）机制实现锁语义。
锁状态通常存储在内核或文件系统中，所有进程可感知。

典型实现

类型	说明
文件锁（File Lock）	使用 `flock()`（BSD）或 `fcntl()`（POSIX）对文件加锁；简单可靠，常用于脚本防重复执行。
System V / POSIX 信号量	内核维护的计数器，可用于互斥或限流（如 `sem_open`, `sem_wait`）。
命名互斥体（Named Mutex）	Windows 中通过名称创建跨进程 Mutex；Linux 可通过 `/dev/shm` + futex 模拟。
共享内存 + 自旋锁	高性能场景下，将锁变量放在共享内存中，配合原子操作实现（需谨慎处理崩溃恢复）。

适用场景

多个独立程序实例访问同一数据库文件（如 SQLite）。
后台守护进程确保单实例运行（如 crond、日志收集器）。
多进程 Web 服务器（如 Apache prefork 模式）共享监听套接字。

*注意事项

进程异常退出可能导致锁未释放（死锁），需配合超时或看门狗机制。
性能低于线程级锁（涉及系统调用）。

伪代码（python）

复制代码

import fcntl
import time
import sys

LOCK_FILE = "/tmp/myapp.lock"

def main():
    with open(LOCK_FILE, "w") as f:
        try:
            # 尝试获取排他文件锁（进程级）
            fcntl.flock(f.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)
            print("获得锁，开始执行任务...")
            time.sleep(10)  # 模拟任务
            print("任务完成")
        except IOError:
            print("另一个实例正在运行，退出。")
            sys.exit(1)
        finally:
            # 文件关闭时自动释放锁（或显式 flock(LOCK_UN)）
            pass

if __name__ == "__main__":
    main()

fcntl.flock() 是 Linux/Unix 的文件锁，由内核管理，对所有进程可见。
即使脚本由不同用户启动，只要访问同一文件路径，锁就生效。
若进程崩溃未释放锁，重启后可手动清理 /tmp/myapp.lock。

2.2.3. 分布式锁（Distributed Lock）

用于跨多台服务器的分布式系统中 ，确保集群内对全局唯一资源的互斥访问。

原理

节点间无共享内存，必须依赖外部协调服务作为"第三方仲裁者"。
锁状态存储在高可用、强一致（或最终一致）的中间件中。
需解决：网络分区、节点宕机、时钟漂移、锁续期等分布式难题。

典型实现

中间件	实现方式	一致性模型
Redis	`SET key value NX PX timeout` + Lua 脚本释放；RedLock 算法增强可靠性	最终一致（单机 Redis）强一致（Redis Cluster + RedLock 争议较大）
ZooKeeper	创建临时顺序节点（Ephemeral Sequential Node），最小序号者获得锁	强一致（ZAB 协议）
etcd	利用 Lease（租约）+ Compare-and-Swap（CAS）实现锁	强一致（Raft 协议）
数据库	`SELECT ... FOR UPDATE` 或唯一索引 + 插入竞争	强一致（依赖 DB 事务）

适用场景

分布式任务调度（如 Quartz 集群模式）：确保定时任务只在一个节点执行。
秒杀系统：防止超卖，保证库存扣减原子性。
分布式 ID 生成器：避免 ID 重复。
配置中心变更通知：串行化处理配置更新。

*注意事项

必须设置超时（自动过期），防止客户端崩溃导致死锁。
锁续期（Watchdog） ：长时间任务需后台线程定期延长锁有效期（如 Redisson 的 watchdog 机制）。
释放锁需原子性：避免误删他人锁（Redis 中用 Lua 脚本校验 value）。
CAP 权衡：强一致锁（ZK/etcd）可能牺牲可用性；高性能锁（Redis）可能牺牲一致性。

伪代码（redis+lua）

复制代码

import redis
import time
import uuid

redis_client = redis.StrictRedis(host='redis-cluster', port=6379)

LOCK_KEY = "inventory:product_123"
LOCK_VALUE = str(uuid.uuid4())  # 唯一标识当前实例
LOCK_TIMEOUT = 10000  # 10秒过期（毫秒）

def acquire_lock():
    # SET key value NX PX timeout ------ 原子加锁
    return redis_client.set(
        LOCK_KEY,
        LOCK_VALUE,
        nx=True,      # only set if not exists
        px=LOCK_TIMEOUT  # auto expire
    )

def release_lock():
    # Lua 脚本：仅当 value 匹配时才删除（防误删）
    lua_script = """
    if redis.call("GET", KEYS[1]) == ARGV[1] then
        return redis.call("DEL", KEYS[1])
    else
        return 0
    end
    """
    redis_client.eval(lua_script, 1, LOCK_KEY, LOCK_VALUE)

def deduct_stock():
    if acquire_lock():
        try:
            stock = int(redis_client.get("stock:product_123") or 0)
            if stock > 0:
                redis_client.decr("stock:product_123")
                print("扣减成功")
            else:
                print("库存不足")
        finally:
            release_lock()  # 必须释放
    else:
        print("获取分布式锁失败，可能正在处理")

# 多个服务实例并发调用 deduct_stock()

fcntl.flock() 是 Linux/Unix 的文件锁，由内核管理，对所有进程可见。
即使脚本由不同用户启动，只要访问同一文件路径，锁就生效。
若进程崩溃未释放锁，重启后可手动清理 /tmp/myapp.lock。

锁状态存储在 Redis 集群 中，所有服务节点共享。
NX + PX 保证原子性；Lua 脚本保证释放安全性。
必须设置超时，防止服务宕机导致死锁。
更高可靠方案：ZooKeeper（临时顺序节点）、etcd（lease + CAS）。

2.3 按功能与行为分类

分类依据：锁在运行时表现出什么样的控制语义和调度行为？

功能与行为决定了"锁如何管理访问顺序和并发粒度"。

类型	说明	适用场景
互斥锁（Mutex / Exclusive Lock）	最基本的独占锁，保证同一时刻只有一个线程能进入临界区，适用于所有需要排他访问的场景。	保护临界区，如修改全局变量
读写锁（Read-Write Lock）	允许多个读操作并发执行，但写操作必须独占；在"读多写少"场景下显著提升并发性能	读多写少场景（如缓存、配置）
可重入锁（Reentrant Lock）	允许同一线程多次获取同一把锁而不会死锁，内部通过持有者线程 ID 和计数器实现，适合递归调用或复杂嵌套逻辑。	避免递归调用导致死锁（如 Java `ReentrantLock`）
公平锁 vs 非公平锁	公平锁按请求顺序分配锁，避免线程饥饿；非公平锁允许新线程"插队"抢锁，吞吐更高但可能造成某些线程长期等待。	公平锁防饥饿，非公平锁吞吐更高
自旋锁（Spin Lock）	获取失败时不挂起线程，而是循环检查（忙等），适用于临界区极短、上下文切换成本高于 CPU 空转的场景（如内核或高性能库）。	临界区极短、上下文切换成本高（如内核）
信号量（Semaphore）	控制最多 N 个线程同时访问某类资源，本质是计数器，可用于限流、连接池管理或模拟互斥锁（当 N=1 时）。	连接池、限流、资源池管理
条件变量（Condition Variable）	与互斥锁配合使用，让线程在特定条件不满足时主动挂起，并在条件达成时被唤醒，实现高效的线程协作（如生产者-消费者模型）。	生产者-消费者、线程协作

按"功能与行为"分类，是从编程模型层面回答："这把锁怎么工作？"

2.3.1互斥锁（Mutex / Exclusive Lock）

项目	说明
定义	最基本的独占锁，确保同一时刻仅一个线程可进入临界区。
原理	线程尝试获取锁 → 成功则执行临界区；失败则阻塞（或自旋）等待。释放后唤醒等待者。
典型实现	Java: `synchronized`, `ReentrantLock` C++: `std::mutex` POSIX: `pthread_mutex_t`
适用场景	保护共享变量、单例初始化、资源独占访问等通用互斥需求。
优点	简单、通用、语义清晰。
缺点	串行化执行，高竞争时性能下降；可能死锁。

所有并发控制的"基石"。

伪代码：（java）

复制代码

// 共享资源
int balance = 100;
Object mutex = new Object();

void withdraw(int amount) {
    synchronized (mutex) {          // ← 获取互斥锁
        if (balance >= amount) {
            balance -= amount;      // ← 临界区
        }
    }                              // ← 自动释放锁
}

本质：最基础的排他锁，synchronized 或 std::mutex 即为此类。

2. 读写锁（Read-Write Lock）

项目	说明
定义	支持多读单写：多个读线程可并发，写线程必须独占。
原理	内部维护两个锁：读锁（共享）和写锁（互斥）。写锁优先级通常更高（防写饥饿）。
典型实现	Java: `ReentrantReadWriteLock` C++: `std::shared_mutex` (C++17) Go: `sync.RWMutex`
适用场景	读多写少场景：缓存、配置中心、统计信息更新。
优点	显著提升读并发吞吐。
缺点	写操作可能被大量读阻塞（需注意写饥饿）；实现比互斥锁复杂。

为"读多写少"量身定制的高性能锁。

伪代码（java）

允许多读并发，写操作独占。

复制代码

ReadWriteLock rwLock = new ReentrantReadWriteLock();
Map<String, String> cache = new HashMap<>();

// 读操作
String get(String key) {
    rwLock.readLock().lock();       // ← 获取读锁（可多个线程同时持有）
    try {
        return cache.get(key);      // ← 并发安全读
    } finally {
        rwLock.readLock().unlock();
    }
}

// 写操作
void put(String key, String value) {
    rwLock.writeLock().lock();      // ← 获取写锁（独占）
    try {
        cache.put(key, value);      // ← 独占写
    } finally {
        rwLock.writeLock().unlock();
    }
}

适用：缓存、配置等 读多写少 场景。

3. 可重入锁（Reentrant Lock）

项目	说明
定义	允许同一线程多次获取同一把锁，不会导致自死锁。
原理	内部记录持有者线程 ID + 重入计数器。每次加锁计数+1，释放-1，归零才真正释放。
典型实现	Java: `ReentrantLock`（显式）、`synchronized`（隐式） Python: `threading.RLock`
适用场景	递归调用、嵌套方法同步、复杂业务逻辑中多次进入同一临界区。
优点	避免同一线程死锁，编程更安全。
缺点	略微增加内存开销（需存储线程ID和计数）。

让"自己不卡自己"的智能锁。

示例（java）：

同一线程可多次获取同一把锁，避免自死锁。

复制代码

ReentrantLock lock = new ReentrantLock();

void outer() {
    lock.lock();
    try {
        System.out.println("outer");
        inner();                    // ← 递归调用
    } finally {
        lock.unlock();
    }
}

void inner() {
    lock.lock();                   // ← 同一线程再次加锁（成功！）
    try {
        System.out.println("inner");
    } finally {
        lock.unlock();
    }
}

关键：内部维护 线程ID + 重入计数器，计数归零才真正释放。

4. 公平锁 vs 非公平锁

项目	公平锁（Fair Lock）	非公平锁（Non-fair Lock）
定义	按请求顺序分配锁（FIFO）	允许新线程"插队"抢锁
原理	维护等待队列，唤醒按序	新线程先尝试直接获取，失败再入队
典型实现	Java: `new ReentrantLock(true)`	Java: `synchronized`、`ReentrantLock()`（默认）
优点	避免线程饥饿，行为可预测	吞吐更高（减少上下文切换）
缺点	性能略低（需维护队列）	可能导致某些线程长期等待
适用场景	对响应时间公平性要求高（如金融交易）	追求高吞吐、低延迟（如 Web 服务）

公平锁保"秩序"，非公平锁拼"效率"。

示例（java）：

是否按请求顺序分配锁。

复制代码

// 公平锁：按 FIFO 顺序唤醒等待线程
ReentrantLock fairLock = new ReentrantLock(true);

// 非公平锁（默认）：新线程可"插队"抢锁
ReentrantLock unfairLock = new ReentrantLock(); // 默认 false

void accessResource() {
    unfairLock.lock();
    try {
        // 临界区
    } finally {
        unfairLock.unlock();
    }
}

公平锁：吞吐略低，但无饥饿；
非公平锁：吞吐高，但可能有线程长期等待。

5. 自旋锁（Spin Lock）

项目	说明
定义	获取失败时不挂起线程，而是循环检查（忙等）直到成功。
原理	用户态 CPU 循环执行 CAS 或 test-and-set 指令，持续尝试获取锁。
典型实现	Linux 内核：`spinlock_t` Java：JVM 轻量级锁底层（短暂自旋）用户态库：DPDK、高性能中间件
适用场景	临界区极短（< 1μs）、低竞争、多核环境（如内核、网络驱动）。
优点	无上下文切换开销，响应快。
缺点	浪费 CPU（空转）；高竞争或长临界区会导致严重性能问题。

用 CPU 换时间，只适合"闪电战"。

示例（c）：

忙等（不挂起线程），适合极短临界区。

复制代码

// C 伪代码（用户态原子操作）
volatile int spinlock = 0;

void spin_lock() {
    while (!__sync_bool_compare_and_swap(&spinlock, 0, 1)) {
        // 忙等：持续尝试 CAS（Compare-And-Swap）
        // 可加入 pause 指令优化 CPU
    }
}

void spin_unlock() {
    __sync_store(&spinlock, 0);  // 释放锁
}

// 使用
void critical_section() {
    spin_lock();
    // 极短操作（如更新 flag）
    spin_unlock();
}

注意：仅适用于临界区 < 1μs 且低竞争场景，否则浪费 CPU。

6. 信号量（Semaphore）

项目	说明
定义	控制最多 N 个线程同时访问某类资源的计数器（N ≥ 1）。
原理	内部维护一个整型计数器： - `acquire()`：计数 -1，若 <0 则阻塞 - `release()`：计数 +1，唤醒等待者
典型实现	Java: `Semaphore` POSIX: `sem_wait/sem_post` Python: `threading.Semaphore`
适用场景	连接池、线程池、限流、生产者-消费者缓冲区大小控制。
优点	灵活控制并发度；可模拟互斥锁（N=1 时即为二值信号量）。
缺点	不记录持有者，无法实现可重入；易误用导致资源泄漏。

不是"门锁"，而是"入场券发放机"。

示例（java）：

控制最多 N 个线程同时访问资源。

复制代码

// 最多 3 个线程同时访问数据库连接池 为1的时候为互斥锁
Semaphore dbPool = new Semaphore(3);

void accessDatabase() {
    dbPool.acquire();              // ← 获取许可（若无则阻塞）
    try {
        // 使用数据库连接（最多3个并发）
    } finally {
        dbPool.release();          // ← 释放许可
    }
}

扩展：当 N=1 时，等价于互斥锁（二值信号量）。

7. 条件变量（Condition Variable）

项目	说明
定义	与互斥锁配合，实现线程"等待-通知"协作机制。
原理	- `wait()`：原子释放锁 + 挂起线程 - `signal()/notify()`：唤醒一个等待者 - `broadcast()/notifyAll()`：唤醒所有
典型实现	Java: `Object.wait()/notify()`、`Condition` POSIX: `pthread_cond_wait` Python: `threading.Condition`
适用场景	生产者-消费者、线程池任务调度、状态变更等待（如"等数据就绪"）。
优点	高效协作，避免轮询浪费 CPU。
缺点	必须与互斥锁配对使用；易出现"虚假唤醒"（需用 while 循环检查条件）。

让线程"睡到条件满足再醒"，是协作的桥梁。

示例（java）：

线程等待某条件成立后再继续（配合互斥锁使用）。

复制代码

ReentrantLock lock = new ReentrantLock();
Condition notEmpty = lock.newCondition();
Queue<String> queue = new LinkedList<>();

// 消费者
String take() {
    lock.lock();
    try {
        while (queue.isEmpty()) {
            notEmpty.await();       // ← 释放锁 + 挂起，等待通知
        }
        return queue.poll();
    } finally {
        lock.unlock();
    }
}

// 生产者
void put(String item) {
    lock.lock();
    try {
        queue.add(item);
        notEmpty.signal();          // ← 唤醒一个等待者
    } finally {
        lock.unlock();
    }
}

必须在持有锁时调用 await()；
使用 while 而非 if（防虚假唤醒）；
signal() 唤醒一个，signalAll() 唤醒全部。

2.4 按实现策略分类

分类依据：系统对并发冲突的基本假设是什么？采用何种哲学来保证正确性？

实现策略反映了系统对"并发本质"的理解与权衡（正确性 vs 性能 vs 复杂度）。

类型	说明	代表技术
悲观锁（Pessimistic Locking）	假设并发冲突频繁，每次访问共享数据前都先加锁，确保安全但可能降低并发效率；典型如数据库行锁、Java `synchronized`。	数据库行锁、`synchronized`
乐观锁（Optimistic Locking）	假设冲突较少，不加锁直接操作，仅在提交时通过版本号或 CAS 检查是否被修改；若冲突则重试，适用于低竞争高吞吐场景。	数据库 version 字段、CAS（Compare-And-Swap）
无锁（Lock-Free）	不依赖传统锁机制，而是利用原子指令（如 CAS）构建数据结构，保证至少有一个线程能 progress，避免死锁和优先级反转。	`AtomicInteger`、无锁队列（如 Disruptor）
免锁（Wait-Free）	无锁的更强形式，保证每个线程都能在有限步内完成操作，不受其他线程影响，实现复杂，多用于实时系统。	更强的无锁保证，实现复杂

按"实现策略"分类，是从并发理论和系统设计哲学层面回答："我们相信世界是怎样的？"

2.4.1. 悲观锁（Pessimistic Locking）

项目	说明
核心思想	"世界充满危险"------假设并发冲突一定会发生，因此在访问共享数据前先加锁，确保安全。
工作方式	- 读/写前获取排他锁 - 操作完成后再释放锁 - 其他线程必须等待锁释放
典型实现	- 数据库：`SELECT ... FOR UPDATE` - Java：`synchronized`、`ReentrantLock` - 操作系统：互斥锁（Mutex）
适用场景	- 写操作频繁 - 冲突概率高 - 要求强一致性（如金融交易）
优点	- 逻辑简单，正确性高 - 避免重试开销
缺点	- 串行化执行，吞吐低 - 可能死锁、阻塞、优先级反转 - 锁竞争激烈时性能急剧下降

宁可错杀一千，不可放过一个------先锁再做事。

示例（java）：

银行转账（强一致性要求）（数据库 + 应用层）

复制代码

// 开启事务
beginTransaction();

try {
    // 1. 加悲观锁（SELECT ... FOR UPDATE）
    Account from = db.query("SELECT * FROM accounts WHERE id = ? FOR UPDATE", fromId);
    Account to = db.query("SELECT * FROM accounts WHERE id = ? FOR UPDATE", toId);

    // 2. 检查余额
    if (from.balance < amount) throw new InsufficientFundsException();

    // 3. 执行转账
    from.balance -= amount;
    to.balance += amount;

    db.update("UPDATE accounts SET balance = ? WHERE id = ?", from.balance, fromId);
    db.update("UPDATE accounts SET balance = ? WHERE id = ?", to.balance, toId);

    commit(); // 提交事务，释放行锁
} catch (Exception e) {
    rollback();
}

数据库在 FOR UPDATE 时对行加排他锁；
其他事务读/写该行会被阻塞，直到当前事务提交；
适合写多、冲突高、强一致场景

2.4.2. 乐观锁（Optimistic Locking）

项目	说明
核心思想	"世界基本和平"------假设冲突很少发生，因此不加锁直接操作，仅在提交时检查是否被修改，冲突则重试。
工作方式	- 读取数据 + 版本号（或时间戳） - 在本地修改 - 提交时比对版本号：　✓ 相同 → 更新成功　✗ 不同 → 失败重试
典型实现	- 数据库：`version` 字段 + `UPDATE ... WHERE version = ?` - Java：`AtomicInteger.compareAndSet(expected, newValue)` - MVCC（多版本并发控制）：PostgreSQL、MySQL InnoDB
适用场景	- 读多写少 - 冲突概率低 - 高吞吐需求（如电商浏览、配置更新）
优点	- 无锁开销，高并发性能好 - 避免死锁
缺点	- 冲突高时重试成本大（CPU 浪费） - 不适合长事务（重试代价高） - 无法保证实时一致性

先做事，后验货；不行就重来。

示例代码（java）：

商品信息编辑（多人可能同时查看，但少人同时修改）带 version 字段【不加锁，提交时检查版本是否被修改。】

复制代码

class Product {
    long id;
    String name;
    int version; // 乐观锁版本号
}

boolean updateProduct(Product newProd) {
    Product old = db.query("SELECT id, name, version FROM products WHERE id = ?", newProd.id);
    
    if (old == null) return false;

    // 尝试更新：仅当 version 未变时才成功
    int rows = db.update(
        "UPDATE products SET name = ?, version = version + 1 WHERE id = ? AND version = ?",
        newProd.name, newProd.id, old.version
    );

    if (rows == 0) {
        // 冲突！别人已修改
        throw new OptimisticLockException("数据已被他人修改，请重试");
    }
    return true;
}

// 调用方需处理重试
void editProductSafely(long id, String newName) {
    int maxRetries = 3;
    for (int i = 0; i < maxRetries; i++) {
        try {
            Product p = new Product(id, newName, 0);
            if (updateProduct(p)) return; // 成功
        } catch (OptimisticLockException e) {
            if (i == maxRetries - 1) throw e;
            Thread.sleep(10); // 短暂等待后重试
        }
    }
}

无锁，高并发读性能好；
冲突时需应用层重试；
适合读多写少、冲突低场景。

2.4.3. 无锁（Lock-Free）

项目	说明
核心思想	完全摒弃传统锁，利用原子指令（如 CAS）构建数据结构，保证至少有一个线程能 progress（不会全部卡住）。
工作方式	- 使用 CPU 提供的原子操作（如 x86 的 `cmpxchg`） - 多线程通过循环 + CAS 更新共享状态 - 失败线程重试，但系统整体始终前进
典型实现	- Java：`AtomicInteger`、`ConcurrentLinkedQueue` - C++：`std::atomic` - 高性能框架：Disruptor（无锁环形缓冲区）
适用场景	- 高频简单操作（计数器、指针切换） - 低延迟系统（交易引擎、实时日志） - 避免死锁/优先级反转的关键路径
优点	- 无死锁、无优先级反转 - 高吞吐、低延迟（无上下文切换）
缺点	- 编程复杂，调试困难 - ABA 问题需额外处理（如加版本戳） - 重试可能浪费 CPU

没有门卫，但大家靠"原子礼仪"自觉排队。

示例代码（java）：

用原子指令（如 CAS）实现线程安全，系统整体始终 progress。高并发计数器

复制代码

import java.util.concurrent.atomic.AtomicLong;

AtomicLong counter = new AtomicLong(0);

void increment() {
    long current, next;
    do {
        current = counter.get();      // 读当前值
        next = current + 1;
        // CAS：仅当值仍为 current 时才更新为 next
    } while (!counter.compareAndSet(current, next));
    // 失败则重试，但至少有一个线程会成功 → Lock-Free
}

// 或直接使用内置方法（内部也是 CAS 循环）
void incrementSimple() {
    counter.incrementAndGet(); // 原子自增
}

无阻塞、无死锁；
适用于简单状态更新（计数器、指针切换）；
ABA 问题 需注意（可用 AtomicStampedReference 解决）。

2.4.4. 免锁（Wait-Free）

项目	说明
核心思想	比 Lock-Free 更强：每个线程都能在有限步内完成操作，不受其他线程影响。
特点	- 无任何等待、重试或依赖 - 实时系统理想选择
实现难度	极高，通常仅用于特定数据结构（如某些队列、栈）
典型应用	航空航天、工业控制等硬实时系统

人人独立，永不等待；

示例代码（java）：

每个线程都能在有限步内完成操作，完全不受其他线程影响。Wait-Free 队列（理论模型）基于环形缓冲区 + 原子索引

复制代码

// Wait-Free Queue（简化版，假设单生产者单消费者）
class WaitFreeQueue<T> {
    private final T[] buffer = (T[]) new Object[CAPACITY];
    private final AtomicLong head = new AtomicLong(0); // 出队位置
    private final AtomicLong tail = new AtomicLong(0); // 入队位置

    boolean enqueue(T item) {
        long currentTail = tail.get();
        long currentHead = head.get();
        
        if (currentTail - currentHead >= CAPACITY) {
            return false; // 队列满
        }

        // 直接写入，无需重试（因 tail 是原子递增）
        buffer[(int)(currentTail % CAPACITY)] = item;
        tail.lazySet(currentTail + 1); // 最终一致性写入
        return true;
    }

    T dequeue() {
        long currentHead = head.get();
        long currentTail = tail.get();

        if (currentHead == currentTail) {
            return null; // 队列空
        }

        T item = buffer[(int)(currentHead % CAPACITY)];
        buffer[(int)(currentHead % CAPACITY)] = null;
        head.lazySet(currentHead + 1);
        return item;
    }
}

此例为 单生产者-单消费者 的 Wait-Free 实现（无竞争）；
真正的多生产者 Wait-Free 队列（如 Michael-Scott）需更复杂算法；

三、锁

3.1 锁和临界区

"临界区"和"锁"是并发编程中两个紧密关联的核心概念。它们共同解决多个执行单元（线程/进程）同时访问共享资源时可能导致的数据不一致或竞态条件（Race Condition）问题。

临界区：指程序中访问共享资源（如变量、文件、设备等）的一段代码 ，这段代码必须被互斥执行------即同一时刻只能有一个线程/进程在执行它。

锁（Lock）：是一种同步机制 ，用于控制对临界区的访问，确保同一时间只有一个执行单元能进入临界区。

锁的作用就是保护临界区。没有锁，临界区就无法安全并发；没有临界区，锁就失去了存在的意义。

在实际编程中，临界区的划分直接影响锁的性能与安全性。若临界区划分过小，可能导致频繁加锁解锁，增加开销；若划分过大，则会过度限制并发，降低程序吞吐量。例如，在处理用户订单数据时，若将"查询订单信息"和"修改订单状态"都纳入同一个临界区，会导致多个读请求无法并发；而合理的做法是将"修改订单状态"作为临界区加锁保护，"查询订单信息"通过读写锁的读模式允许并发访问，平衡安全性与效率。

此外，临界区的原子性保障依赖锁的正确使用。必须确保锁的粒度与临界区完全匹配，即"进临界区前加锁，出临界区后解锁"，且加锁与解锁必须成对出现。若出现"加锁后未解锁"的情况，会导致锁永久持有，其他线程无法进入临界区，引发死锁；若"未加锁就进入临界区"，则无法避免竞态条件，导致数据错误。在 Java 中，synchronized 关键字会自动完成加锁与解锁（异常时也会释放锁），而 ReentrantLock 则需要手动通过 try-finally 块保证解锁，避免异常场景下的锁泄漏。

3.2 锁的核心特性

理解锁的特性是正确使用锁的前提，除了前文分类中提及的可重入性、公平性等，锁还具备以下核心特性：

1. 互斥性：这是锁最基础的特性，确保同一时刻只有一个线程（或进程）能持有锁并进入临界区。互斥性是保证数据一致性的核心，无论是互斥锁、读写锁的写模式，还是分布式锁，都严格遵循互斥性原则。需要注意的是，读写锁的读模式不具备互斥性，其设计初衷是在读多写少场景下提升并发，通过"读-读兼容、读-写互斥、写-写互斥"的规则平衡互斥与并发。

2. 可见性：锁不仅能控制临界区的访问权限，还能保证共享资源的可见性。在多线程环境中，线程会将共享变量缓存到本地工作内存，若未加锁，一个线程修改的变量可能无法及时被其他线程感知，导致脏读。而加锁操作会强制线程刷新本地缓存，将修改后的变量同步到主内存；解锁操作则会确保本地缓存中的修改已同步到主内存，从而保证后续获取锁的线程能读取到最新的变量值。例如，Java 中的 synchronized 和 ReentrantLock 都能保证可见性，这也是它们区别于普通变量的关键特性之一。

3. 有序性：并发环境中，CPU 可能会对指令进行重排序以提升执行效率，这可能导致程序执行顺序与代码逻辑顺序不一致，引发潜在问题。锁能禁止指令重排序，确保临界区内的代码按逻辑顺序执行。例如，在单例模式的双重检查锁定实现中，若未使用 volatile 关键字或锁机制，可能因指令重排序导致创建出多个实例；而通过锁包裹实例创建逻辑，可强制指令有序执行，避免该问题。

3.3 锁的常见风险与规避策略

锁的使用虽能解决并发问题，但不当使用会引入新的风险，常见的有死锁、活锁、饥饿以及性能损耗等，需针对性采取规避策略。

1. 死锁：

指两个或多个线程互相持有对方所需的锁，且都不主动释放，导致所有线程永久阻塞。例如，线程 A 持有锁 1 并等待锁 2，线程 B 持有锁 2 并等待锁 1，此时两者陷入死锁。

规避死锁的核心原则包括：

一是按固定顺序加锁，确保所有线程获取锁的顺序一致，避免循环等待；

二是设置锁超时时间，若线程在指定时间内未获取到锁，则主动释放已持有的锁，打破阻塞状态（如 ReentrantLock 的 tryLock 方法）；

三是使用可中断锁，允许线程在等待锁的过程中响应中断信号，主动退出等待（如 ReentrantLock 的 lockInterruptibly 方法）；

四是定期检测死锁，通过工具（如 Java 的 jstack）排查死锁线程，及时优化锁的使用逻辑。

2. 活锁：

指线程虽未阻塞，但因不断重试操作而无法推进执行。例如，两个线程同时获取锁失败后，都立即释放自身资源并重新尝试获取，导致两者反复重试却始终无法获取到锁。活锁与死锁的区别在于，活锁中的线程处于活跃状态，而死锁中的线程处于阻塞状态。
规避活锁的策略包括：

一是引入随机延迟，线程获取锁失败后，随机等待一段时间再重试，避免多个线程同步重试；

二是设置重试次数上限，若超过次数则暂停重试或降级处理，避免无限循环；

三是优化锁的竞争逻辑，减少不必要的重试操作。

3. 饥饿：

指某个线程长期无法获取锁，始终处于等待状态。常见原因包括锁的非公平性、线程优先级不合理等。例如，在非公平锁机制下，新线程可能频繁"插队"获取锁，导致老线程长期等待；若高优先级线程持续竞争锁，低优先级线程可能永远无法获取锁。
规避饥饿的策略包括：

一是使用公平锁，按线程请求锁的顺序分配锁，确保每个线程都有机会获取锁；

二是合理设置线程优先级，避免优先级倒置；

三是限制锁的持有时间，避免线程长时间占用锁，给其他线程获取锁的机会。

4. 性能损耗：

锁的加锁、解锁操作以及线程阻塞/唤醒都会带来开销，过度使用锁或锁粒度不当会严重影响程序性能。
优化策略包括：

一是减小锁粒度，将大临界区拆分为多个小临界区，降低锁的竞争概率（如 Java 中的 ConcurrentHashMap 采用分段锁机制，将哈希表分为多个段，每个段单独加锁，提升并发性能）；

二是使用合适的锁类型，根据场景选择无锁、轻量级锁或重量级锁，读多写少场景优先使用读写锁；

三是避免锁的嵌套，减少重入锁的使用次数，降低锁管理开销；四是采用锁消除优化，编译器或 JVM 会自动消除不必要的锁（如对局部变量加锁，因局部变量不共享，锁无实际意义，会被自动消除）。

3.4 使用场景

典型业务场景	核心并发问题	推荐锁 / 同步机制	推荐理由
单例模式懒加载（双重检查）	多线程同时初始化实例	`synchronized` + `volatile` 或 `ReentrantLock`	保证实例创建的原子性与可见性；JVM 对 `synchronized` 优化后性能良好
高并发计数器（如 PV 统计）	多线程对整型变量自增	`AtomicLong` / `LongAdder`	无锁 CAS 操作，避免重量级锁开销；`LongAdder` 在高竞争下性能更优
缓存读多写少（如配置、热点数据）	多读一写，需保证一致性	`ReentrantReadWriteLock`（读写锁）	允许多个线程并发读，写时独占，显著提升读吞吐
数据库连接池 / 线程池资源管理	限制同时使用的资源数量	`Semaphore`（信号量）	精确控制并发访问数（如最多 10 个连接），天然匹配资源池模型
生产者-消费者模型（任务队列）	生产满时阻塞生产者，消费空时阻塞消费者	`BlockingQueue`（内部用 `ReentrantLock` + `Condition`）	JDK 提供成熟实现（如 `ArrayBlockingQueue`），无需手写锁逻辑
递归方法中的同步（如遍历树并修改）	同一线程多次进入临界区	`ReentrantLock` 或 `synchronized`	两者均支持可重入，避免自死锁
短临界区、低竞争（如更新标志位）	需要极低延迟的互斥	自旋锁（Spin Lock）或 JVM 轻量级锁	避免线程挂起/唤醒开销，适合微秒级操作
跨 JVM 实例的分布式任务调度	多服务实例争抢唯一任务	分布式锁（Redis + RedLock / ZooKeeper）	确保集群中仅一个节点执行关键任务（如定时批处理）
秒杀/库存扣减（高并发写）	超卖风险，需强一致性	数据库悲观锁（`SELECT ... FOR UPDATE`） + 本地缓存预减	悲观锁保证 DB 层原子性；缓存层用 `Redis incr/decr` + Lua 脚本防超卖
日志写入（多线程追加）	多线程写同一文件乱序	`synchronized` 块或 `ReentrantLock`	保证写操作原子性；若性能敏感，可改用异步日志框架（如 Logback AsyncAppender）
状态机变更（如订单状态流转）	防止并发修改导致状态错乱	乐观锁（version 字段）	通过版本号校验更新是否成功，失败则重试，避免长时间持锁
高性能无锁队列（如 Disruptor）	极致吞吐，避免锁竞争	无锁环形缓冲区（CAS + 内存屏障）	适用于金融交易、高频事件处理等场景，延迟可降至纳秒级

总结：

没有"最好"的锁，只有"最合适"的锁 。

综合考虑：

资源特性（是否可共享、读写比例）
竞争强度（低/高并发）
临界区长度（短/长）
系统架构（单机/分布式）
一致性要求（强一致/最终一致）

实际开发中，最常用的核心锁不超过 6 种如下：

互斥锁（Mutex）
读写锁（Read-Write Lock）
可重入锁（Reentrant Lock）
信号量（Semaphore）
自旋锁（Spin Lock）
分布式锁（Distributed Lock）