乐观锁与悲观锁详解

1. 基本概念

1.1 悲观锁

悲观锁是一种总是假设最坏情况的并发控制机制。它认为在并发环境中，数据总是会被其他线程修改，因此在访问数据前就先加锁，防止其他线程同时访问。

• 核心思想：先加锁，后访问
• 基本假设：冲突是常态，数据会被频繁修改
• 特点：独占性、排他性

1.2 乐观锁

乐观锁是一种假设冲突很少发生的并发控制机制。它认为在并发环境中，数据不会被其他线程修改，所以不加锁，只在更新数据时检查是否有其他线程修改了数据。

• 核心思想：先访问，后检查
• 基本假设：冲突是少数，数据很少被同时修改
• 特点：非阻塞、无锁

2. 乐观锁与悲观锁的区别

3. 应用场景

3.1 悲观锁适用场景

1. 写操作频繁的场景：当数据经常被修改时，使用悲观锁可以避免大量的冲突检测和重试。
2. 冲突概率高的场景：当多个线程同时修改同一数据的概率很高时，悲观锁可以减少因冲突导致的重试次数。
3. 数据一致性要求极高的场景：如金融交易、库存扣减等，确保数据的一致性是首要任务。
4. 持续时间较短的操作：当加锁后的操作很快就能完成时，不会长时间阻塞其他线程。

3.2 乐观锁适用场景

1. 读操作频繁的场景：当数据主要是被读取，很少被修改时，乐观锁可以提供更好的性能。
2. 冲突概率低的场景：当多个线程同时修改同一数据的概率很低时，乐观锁可以减少加锁带来的开销。
3. 长时间事务：当事务持续时间较长，使用悲观锁会导致其他线程长时间阻塞时，乐观锁是更好的选择。
4. 分布式系统：在分布式环境中，乐观锁更容易实现和维护。

4. 实现方式

4.1 悲观锁的实现方式

4.1.1 Java中的synchronized关键字

public class PessimisticLockExample {
    private final Object lock = new Object();
    private int sharedResource = 0;

    public void increment() {
        synchronized (lock) {  // 加锁
            sharedResource++;  // 临界区代码
        }  // 释放锁
    }
}

4.1.2 Java中的ReentrantLock

import java.util.concurrent.locks.ReentrantLock;

public class PessimisticLockExample {
    private final ReentrantLock lock = new ReentrantLock();
    private int sharedResource = 0;

    public void increment() {
        lock.lock();  // 加锁
        try {
            sharedResource++;  // 临界区代码
        } finally {
            lock.unlock();  // 确保锁被释放
        }
    }
}

4.1.3 数据库中的排他锁（X锁）

-- 开始事务
BEGIN;

-- 对行加排他锁
SELECT * FROM products WHERE id = 1 FOR UPDATE;

-- 修改数据
UPDATE products SET stock = stock - 1 WHERE id = 1;

-- 提交事务，释放锁
COMMIT;

4.2 乐观锁的实现方式

4.2.1 版本号机制

public class OptimisticLockExample {
    private int version = 0;
    private int sharedResource = 0;

    public boolean increment() {
        int currentVersion = version;
        // 模拟一些处理时间
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        
        // CAS操作：如果version没有被其他线程修改，则更新
        if (version == currentVersion) {
            sharedResource++;
            version++;  // 版本号增加
            return true;  // 更新成功
        } else {
            return false;  // 更新失败，需要重试
        }
    }
}

4.2.2 数据库中的版本号

-- 创建表时添加版本号字段
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    stock INT,
    version INT DEFAULT 0
);

-- 更新操作，检查版本号
UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE id = 1 AND version = 0;

4.2.3 CAS（Compare And Swap）操作

import java.util.concurrent.atomic.AtomicInteger;

public class OptimisticLockExample {
    private AtomicInteger sharedResource = new AtomicInteger(0);

    public void increment() {
        int oldValue, newValue;
        do {
            oldValue = sharedResource.get();
            newValue = oldValue + 1;
            // CAS操作：如果当前值等于oldValue，则更新为newValue
        } while (!sharedResource.compareAndSet(oldValue, newValue));
    }
}

4.2.4 时间戳机制

import java.util.concurrent.atomic.AtomicLong;

public class OptimisticLockExample {
    private final AtomicLong timestamp = new AtomicLong(System.currentTimeMillis());
    private int sharedResource = 0;

    public boolean increment() {
        long currentTimestamp = timestamp.get();
        // 模拟一些处理时间
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        
        // 如果时间戳没有被修改，则更新
        if (timestamp.compareAndSet(currentTimestamp, System.currentTimeMillis())) {
            sharedResource++;
            return true;  // 更新成功
        } else {
            return false;  // 更新失败，需要重试
        }
    }
}

5. 工作原理可视化

5.1 悲观锁工作流程

5.2 乐观锁工作流程

5.3 乐观锁与悲观锁对比时序图

5.4 适用场景对比

6. 总结

乐观锁和悲观锁是并发控制中两种重要的锁机制，它们各有优缺点，适用于不同的场景。

• 悲观锁适合写操作频繁、冲突概率高的场景，通过提前加锁确保数据一致性，但可能会带来性能开销和死锁风险。
• 乐观锁适合读操作频繁、冲突概率低的场景，通过最后检查的方式避免加锁开销，但需要处理更新失败的情况。

在实际应用中，应根据具体业务场景和数据访问模式选择合适的锁机制，有时甚至可以结合使用两种锁机制，以达到最佳的性能和一致性平衡。