Java 悲观锁和乐观锁(通俗解释版！简单易懂）附加代码解释

一、悲观锁（Pessimistic Lock）🔒🛑

1. 工作原理

悲观锁假设每次对数据的操作可能会发生冲突，所以我们会在操作前主动上锁，这样其他线程只能等着，直到锁被释放。

2. 代码示例

在Java中，使用 synchronized 关键字来实现悲观锁。我们来看看详细的代码：

```csharp
public class PessimisticLockExample {
    // 一个共享的资源，比如银行账户余额
    private int balance = 1000; // 假设账户初始余额为1000

    // 增加余额的方法，使用悲观锁保证线程安全
    public synchronized void deposit(int amount) {
        // 这个方法加了锁，只有一个线程可以同时操作
        System.out.println(Thread.currentThread().getName() + " 正在存款...");
        int newBalance = balance + amount;  // 计算新的余额
        // 模拟一些耗时操作，比如数据库操作
        try {
            Thread.sleep(1000); // 让线程休眠1秒，模拟真实场景中的延迟
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        balance = newBalance; // 更新余额
        System.out.println(Thread.currentThread().getName() + " 存款完成，余额为：" + balance);
    }

    // 获取当前余额的方法
    public int getBalance() {
        return balance;
    }

    public static void main(String[] args) {
        // 创建一个账户对象
        PessimisticLockExample account = new PessimisticLockExample();

        // 创建两个线程，分别尝试同时存款
        Thread t1 = new Thread(() -> account.deposit(500), "线程1");
        Thread t2 = new Thread(() -> account.deposit(300), "线程2");

        // 启动两个线程
        t1.start();
        t2.start();
    }
}

3. 详细注释解释：

1. balance：这是一个共享资源，代表银行账户的余额。在并发环境下，不同的线程会同时尝试访问和修改它。
2. synchronized：使用这个关键字是为了加锁，确保同一时间只有一个线程可以执行 deposit() 方法。这样做的目的是防止多个线程同时修改余额，导致数据不一致。
3. 模拟真实环境中的耗时操作：我们通过 Thread.sleep(1000) 模拟在真实应用中，比如数据库更新操作可能会花一些时间。在此期间，如果不加锁，另一个线程可能会同时尝试修改余额，导致不一致。
4. 线程执行顺序：由于 synchronized 加了锁，线程1 执行存款操作时，线程2 必须等待锁被释放，才能执行自己的存款操作。

4. 运行结果：

假设运行了上面的代码，输出可能会是：

复制代码
线程1 正在存款...
线程1 存款完成，余额为：1500
线程2 正在存款...
线程2 存款完成，余额为：1800

解释：你可以看到，线程1 先获得了锁，所以 线程2 必须等到 线程1 完成并释放锁后，才能执行存款操作。

优点🌟：

• 安全可靠：因为我们每次操作数据前都上锁，所以可以避免并发冲突（多个线程同时修改数据导致数据不一致）。
• 适合写多读少的场景：如果大部分操作都是写数据而不是读数据，悲观锁可以确保数据一致性。

缺点⚠️：

• 性能低：由于每次都要先上锁，其他线程在等待锁释放的过程中会浪费时间，降低了系统的并发性能。
• 可能造成死锁：如果不小心处理不当，可能会出现死锁，即多个线程互相等待对方释放锁，导致整个系统卡住。

使用场景📝：

• 高冲突的场景：如果你的系统中有大量写操作，且冲突发生的概率非常高，那么悲观锁是个不错的选择。
• 银行转账💸：比如两个线程同时修改同一个银行账户的余额，悲观锁可以确保每次操作都是独占的，避免错误计算。

---

二. 乐观锁（Optimistic Lock）🔓😎

定义：

与悲观锁不同，乐观锁假设冲突不会经常发生。它的思路是：当多个线程同时访问同一数据时，没必要每次都上锁，大家可以“乐观”地认为自己不会遇到冲突。在操作数据时，我们不加锁，等到最后提交数据时，才检查是否有人在我们操作期间修改了数据。如果数据没有被修改，那么我们的操作就可以直接提交；但如果发现数据被其他线程修改了，我们就需要重新读取并重试。

生活中的类比🍔🛒：

想象一下，你在超市看到一个架子上有最后一个汉堡🍔，但你不急着拿，因为你觉得别人也可能暂时不需要它。等到你真正决定去拿时，如果它还在，你就直接拿走（操作成功）；但如果有人先拿走了，那你就得重新挑选其他食物——这就像乐观锁的逻辑：等到最后一步再检查数据是否改变。

工作原理🛠️：

乐观锁通常通过版本号或时间戳来实现。每次读取数据时，我们同时记录下这个数据的版本号。修改数据时，我们会检查当前版本号是否和读取时的一样，如果版本号没变，那就可以提交修改；如果版本号变了，说明数据在此期间被其他线程修改过，我们就要放弃本次操作，并重新尝试。

代码示例

在Java中，我们可以通过CAS操作（Compare-And-Swap）**或者**版本号的方式来实现乐观锁。下面的例子使用了版本号来模拟乐观锁的行为：

public class OptimisticLockExample {
    // 一个共享的资源，比如银行账户余额
    private int balance = 1000; // 假设账户初始余额为1000
    private int version = 0; // 版本号，用来跟踪修改

    // 增加余额的方法，使用乐观锁
    public void deposit(int amount) {
        // 记录当前版本号
        int currentVersion = version;
        System.out.println(Thread.currentThread().getName() + " 尝试存款，当前版本号：" + currentVersion);
        
        // 模拟耗时操作，像是数据库查询
        try {
            Thread.sleep(1000); // 模拟延迟
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        
        // 检查版本号是否一致
        if (currentVersion == version) {
            // 如果版本号没有变化，执行更新
            int newBalance = balance + amount;
            balance = newBalance;
            version++; // 更新版本号
            System.out.println(Thread.currentThread().getName() + " 存款成功，余额为：" + balance + "，新版本号：" + version);
        } else {
            // 如果版本号变化了，说明数据被其他线程修改，需要重试
            System.out.println(Thread.currentThread().getName() + " 存款失败，版本号已改变，重试...");
        }
    }

    public static void main(String[] args) {
        // 创建一个账户对象
        OptimisticLockExample account = new OptimisticLockExample();

        // 创建两个线程，分别尝试同时存款
        Thread t1 = new Thread(() -> account.deposit(500), "线程1");
        Thread t2 = new Thread(() -> account.deposit(300), "线程2");

        // 启动两个线程
        t1.start();
        t2.start();
    }
}

详细注释解释：

1. version：这是一个版本号，用来跟踪数据的修改。每当我们成功更新数据时，版本号都会增加。

2. currentVersion：这是线程在开始存款操作时记录的版本号，用来检测其他线程是否在操作期间修改了数据。

3. 乐观锁的工作流程

   ：

   • 线程开始存款时，记录下当前的版本号。
   • 在执行操作前，线程等待一段时间（模拟真实场景中的延迟，比如数据库访问）。
   • 存款前，检查版本号是否和最初读取时一致。如果一致，表示数据没有被其他线程修改，那么可以成功提交修改；如果不一致，表示数据已经被其他线程修改，需要放弃当前操作并重试。

运行结果：

复制代码
线程1 尝试存款，当前版本号：0
线程2 尝试存款，当前版本号：0
线程1 存款成功，余额为：1500，新版本号：1
线程2 存款失败，版本号已改变，重试...

解释：线程1 和 线程2 几乎同时开始操作，但由于 线程1 成功更新了余额并修改了版本号，线程2 在检查时发现版本号已经改变，导致存款失败。如果是实际应用中，线程2 会重试这个操作。

优点🌟：

• 高性能：乐观锁在大多数情况下不需要加锁，因此可以提高系统的并发性，尤其适合读多写少的场景。
• 避免死锁：因为乐观锁不需要长时间持有锁，减少了死锁的风险。

缺点⚠️：

• 重试成本高：如果发生冲突，操作需要重新尝试，这会带来额外的性能开销，尤其是在冲突频繁的场景下，可能会降低效率。
• 不适合高冲突场景：在冲突发生率较高的场景中，乐观锁的重试机制可能导致性能不佳。

使用场景📝：

• 读多写少的场景：当大部分操作是读取数据，而修改操作较少时，乐观锁能够最大化并发性能。
• 电子商务系统中的库存管理🛒：比如查看商品库存，大家可以频繁查看库存信息（读取操作），而库存的修改操作相对较少，这种情况下乐观锁就非常适用。

---

悲观锁 vs 乐观锁 详细对比🔍

特性	悲观锁🔒	乐观锁🔓
加锁时机	操作数据之前，先主动上锁	操作数据时不加锁，提交时检查冲突
并发性能	并发性能较低，线程需要等待锁释放	并发性能较高，适合读多写少的场景
适用场景	高冲突、高并发的场景	低冲突、读多写少的场景
实现难度	实现简单，通过 synchronized 实现	实现稍复杂，通过版本号或CAS实现
死锁风险	可能会发生死锁	不存在死锁问题
性能影响	由于频繁加锁，性能会下降	如果冲突多，重试次数过多时性能下降

---

总结🎯：

• 悲观锁：适合高并发和高冲突的场景，比如在写操作很多的情况下。悲观锁通过主动加锁来确保每次对数据的操作都是独占的，避免了数据的不一致问题。虽然这样可以确保数据的安全性，但是会带来性能下降，因为其他线程必须等到锁被释放才能继续操作。此外，悲观锁还有可能出现死锁的风险。

• 乐观锁：适合低冲突或读多写少的场景。它假设大部分时间不会有数据冲突，所以不主动上锁，而是在操作提交时检查数据是否被其他线程修改过。乐观锁的优势在于可以提高并发性能，因为它允许多个线程同时操作数据而不用等待。不过，如果发生冲突，乐观锁需要重新尝试，可能导致重试开销大，尤其在高冲突的情况下，重试次数过多会影响性能。