悲观锁、乐观锁的个人理解

一、乐观锁

概念： 乐观锁从字面上来看就知道它是比较乐观的，它认为数据一般不会产生冲突，因此开始执行方法的时候一般不加锁，只有当数据进行提交更新时，才会真正对数据是否产生冲突进行监测，再加锁更新数据。如果监测时发生冲突，就返回给用户错误信息，由用户来决定如何去做。

主要步骤：

1.数据表表中加一个version字段

2.实体类中在version字段的注解加@version

3.加一个乐观锁插件

 4.测试乐观锁，先查询version，你会发现version=1，修改后，version会等于2

 

 

public class OptimisticLockExample {
    private int version;

    public void optimisticLockTest() {
        int v = version;
        // 假设一些其他操作可能会改变version值
        // 执行一些其他操作...
        version++;
        // 更新数据前监测version是否因为其他操作修改了
        if (v == version - 1) {
            // 版本号未被其他线程改变，操作成功
            // 更新业务逻辑代码...
        } else {
            // 被改动了，抛出异常
            throw new OptimisticLockException("版本号已被其他线程改变，操作失败");
        }
    }
}

二、悲观锁

概念： 悲观锁它总是会假设当前情况是最坏的情况，在每次去拿数据的时候，都会认为数据会被别人改变，所以在拿数据的时候一开始就加锁，确保同一时刻只有一个线程能够访问和修改数据，其他线程需要等待当前线程释放锁之后才能进行访问和修改。

public class PessimisticLockExample {
    private Lock lock = new ReentrantLock();
    
    public void pessimisticLockTest() {
        // 获取锁
        lock.lock();
        try {
            // 执行共享资源操作..
        } finally {
            lock.unlock();
        }
    }
}

Java里面synchronized(同步锁)和ReentrantLock(重入锁)等独占锁就是悲观锁思想的实现，上述代码使用的是ReentrantLock(重入锁)，在对共享资源进行操作时，先通过lock()方法获取锁，操作完成后再通过unlock()方法释放锁。这种方式能够保证同一时刻只有一个线程能够对资源进行操作。

适用场景： 悲观锁适用于写多读少的场景，如银行转账、库存更新等。因为悲观锁需要加锁，可以保证数据的一致性和完整性，但是也会降低并发性能。

三、总结
乐观锁通常是通过CAS算法来实现，也可以使用版本号或时间戳等方式。而悲观锁通常是通过synchronized关键字或者ReentrantLock来实现的。当多个线程同时更新同一条数据时，如果使用乐观锁，可能会发生更新冲突，需要进行重试或者回滚操作；而如果使用悲观锁，则可以保证同一时刻只有一个线程能够更新数据，不会出现更新冲突。总之，乐观锁和悲观锁各有优缺点，具体使用场景需要结合具体业务需求和并发情况进行选择。