【java】乐观锁和悲观锁的区别

乐观锁和悲观锁是两种常见的并发控制机制，它们在处理数据竞争和并发访问时采用了不同的策略。以下是它们的主要区别：

乐观锁 (Optimistic Locking)

1. 设计思想：

• 乐观锁假设对资源的并发访问通常不会发生冲突，因此不加锁，但在更新数据时会进行冲突检测。
• 它适用于冲突少的场景，认为大部分情况下数据更新是不会冲突的。

2. 实现方式：

• 常见的实现方法是使用版本号或时间戳。在每次读取数据时，读取对应的版本号或时间戳，在提交更新时，检查当前数据的版本号是否与读取时一致。
• 如果版本号一致，则更新成功；否则，说明数据在此期间被其他事务修改过，更新失败，需要重新读取数据并重试操作。

3. 应用场景：

• 适用于读操作多、写操作少的场景，例如大部分查询操作且较少修改操作的系统。
• 数据库、ORM框架中常用乐观锁来确保并发事务的一致性，例如Hibernate的@Version注解。

4. 优点和缺点：

• 优点：不会出现死锁，适用于大多数读操作的场景。
• 缺点：在并发写操作频繁的情况下，可能会导致较多的重试和失败操作。

示例代码（使用版本号）：

public class OptimisticLockingExample {
    private int version;

    public boolean updateData(int newVersion) {
        if (this.version == newVersion) {
            this.version++;
            // 执行更新操作
            return true;
        } else {
            return false; // 更新失败，需要重试
        }
    }
}

悲观锁 (Pessimistic Locking)

1. 设计思想：

• 悲观锁假设对资源的并发访问会发生冲突，因此在读取数据时就对资源进行加锁，以确保在锁定期间其他事务无法访问该资源。
• 它适用于冲突多的场景，认为大部分情况下数据更新会冲突。

2. 实现方式：

• 使用数据库提供的锁机制（如行锁、表锁）来锁定数据，在事务处理完毕后释放锁。
• 悲观锁可以在数据库层面通过SELECT ... FOR UPDATE语句实现，锁定读取的数据行，防止其他事务修改。

3. 应用场景：

• 适用于写操作多、冲突频繁的场景，例如银行转账系统、库存管理系统等需要确保数据一致性的场景。
• 在需要严格控制并发访问的情况下，使用悲观锁可以避免数据不一致问题。

4. 优点和缺点：

• 优点：在高并发写操作场景下可以确保数据一致性，避免冲突。
• 缺点：会阻塞其他事务访问被锁定的资源，可能导致性能下降，存在死锁风险。

示例代码（使用数据库锁）：

BEGIN TRANSACTION;
SELECT * FROM inventory WHERE product_id = 1 FOR UPDATE;
/* 执行更新操作 */
UPDATE inventory SET stock = stock - 1 WHERE product_id = 1;
COMMIT;

总结

• 乐观锁适用于并发冲突少的场景，通过版本号或时间戳进行冲突检测，在数据更新时确保一致性。
• 悲观锁适用于并发冲突多的场景，通过锁定资源防止其他事务访问，以确保数据的一致性和完整性。

根据应用场景的不同选择合适的锁机制，可以在确保数据一致性的同时，最大限度地提高系统的性能。