浅谈一下Java中的悲观锁和乐观锁

目录

• 悲观锁（Pessimistic Locking）
• 悲观锁存的问题：
• 乐观锁
• 乐观锁存在的问题
• 悲观锁和乐观锁的对比
• 总结

悲观锁和乐观锁是面试高频问题之一，本文将对悲观锁和乐观锁简单的进行一个介绍。

悲观锁（Pessimistic Locking）

悲观锁在并发环境中认为数据随时会被其他线程修改，因此每次在访问数据时都会加锁，直到操作完成后才释放锁。悲观锁适用于写操作多、竞争激烈的场景，比如多个线程同时对同一数据进行修改或删除操作的情况。悲观锁可以保证数据的一致性，避免脏读、幻读等问题的发生

悲观锁就像一个大保安，总是认为有坏人想要偷走共享资python源，于是它把资源护得紧紧的，不让任何人接近，同时还会排队等待资源，想要使用就得先获取锁，这样虽然安全可靠，但是也会导致效率低下，因为别的线程必须等待锁的释放才能继续执行。

Java中常用的悲观锁是synchronized关键字和ReentrantLock类。

使用开发者_开发培训synchronized关键字实现悲观锁的代码如下：

synchronized (lock) {
    //访问共享资源的代码块
}

使用ReentrantLock实现悲观锁的代码如下：

ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    //访问共享资源的代码块
} finally {
    lock.unlock();
}

悲观锁存的问题：

• 效率低：悲观锁需要获取锁才能进行操作，当有多个线程需要访问同一份http://www.devze.com数据时，每个线程都需要先获取锁，然后再进行操作，如果锁竞争激烈，就会导致线程等待锁的释放，浪费了大量的时间。
• 容易引起死锁：悲观锁在获取锁的过程中，如果获取不到就会一直等待，如果不同的线程都在等待对方释放锁，就会导致死锁的情况出现。
• 可能会引起线程阻塞：当某个线程获取到锁时，其他线程需要等待，如果等待的时间过长，就会导致线程阻塞，影响应用的性能。

乐观锁

乐观锁在并发环境中认为数据一般情况下不会被其他线程修改，因此在访问数据时不加锁，而是在更新数据时进行检查。如果检查到数据被其他线程修改，则放弃当前操作，重新尝试更新。

乐观锁适用于读操作多、写操作少的场景，比如多个线程同时对同一数据进行读取操作的情况。乐观锁可以减少锁的竞争，提高系统的并发性能。

乐观锁就像一个乐天派，总是认为没有坏人想要偷走共享资源，于是它就不怎么防范，直接对资源进行操作，如果没有其他线程对资源进行修改，操作就会成功，否则就会进行重试，这样虽然效率高，但是如果多个线程同时进行修改，就会导致竞争和冲突，需要进行额外的处理。

Java中常用的乐观锁是基于CAS（Compare and Swap，比较和交换）算法实现的。

CAS操作包括三个操作数：内存地址V、旧的预期值A和新的值B。CAS操作首先读取内存地址V中的值，如果该值等于旧的预期值A，那么将内存地址V中的值更新为新的值B；

否则，不进行任何操作。在更新过程中，如果有其他线程同时对该共享资源进行了修改，那么CAS操作会失败，此时需要重试更新操作。

下面是一段基于CAS算法实现的乐观锁代码：

// 假设共享资源为变量value，初始值为1
AtomicInteger value = new AtomicInteger(1);
// 假设旧的预期值为1，新的值为2
int expect = 1;
int update = 2;

// 使用CAS操作更新共享资源的值
while (true) {
    // 读取共享资源的当前值
    int current = value.get();
    // 如果当前值等于旧的预期值，使用CAS操作将新的值更新到共享资源中
    if (current == expect) {
        if (value.compareAndSet(expect, update)) {
            // 更新成功，退出循环
            break;
        } else {
            // 更新失败，可能是因为其他线程修改了共享资源的值，重试更新操作
            continue;
        }
    } else {
        // 当前值不等于旧的预期值，说明共享资源的值已经被其他线程修改，重试更新操作
        continue;
    }
}

在这段代码中，内存地址V对应的是AtomicInteger对象value，旧的预期值A对应的是变量expect，新的值B对应的是变量update。使用AtomicInteger对象可以保证CAS操作的原子性，即只有一个线程能够成功更新共享资源的值。使用compareAndSet方法可以判断共享资源的值是否等于旧的预期值，并尝试将新的值更新到共享资源中。如果更新成功，就退出循环；否则，说明共享资源的值已经被其他线程修改，需要重试更新操作。

在实际应用中，乐观锁的实现通常比这个简单实现要复杂。例如，在对数据库中的数据进行更新时，需要在更新操作中同时更新版本号和其他字段的值，并且需要处理更新失败和重试的情况。

乐观锁存在的问题

CAS虽然很⾼效的解决原⼦操作，但是CAS仍然js存在三⼤问题：ABwww.devze.comA问题，自旋时间过长和只能保证单个变量的原子性。

• ABA问题：CAS算法在比较和替换时只考虑了值是否相等，而没有考虑到值的版本信息。如果一个值在操作过程中被修改了两次，从原值变成新值再变回原值，此时CAS会认为值没有发生变化，从而出现操作的错误。为了解决ABA问题，可以在共享资源中增加版本号，每次修改操作都将版本号加1，从而保证每次更新操作的唯一性。在更新数据时先读取当前版本号，如果与自己持有的版本号相同，则可以更新数据，否则更新失败。版本号算法可以避免ABA问题，但需要维护版本号，增加了代码复杂度和内存开销。
• 自旋时间过长：由于CAS算法在失败时会一直自旋，等待共享变量可用，如果共享变量一直不可用，就会出现自旋时间过长的问题，浪费CPU资源。
• 只能保证单个变量的原子性：CAS算法只能保证单个变量的原子性，如果需要php多个变量的原子操作，就需要使用锁等其他方式进行保护。

悲观锁和乐观锁的对比

总结

悲观锁和乐观锁各有优缺点，应根据具体的业务场景和性能需求来选择合适的锁机制。在实际应用中，也可以考虑使用两种锁机制的组合，例如在高并发读写的情况下，可以使用乐观锁来提高读操作的效率，同时在写操作时使用悲观锁来保证数据的一致性。

到此这篇关于浅谈一下Java中的悲观锁和乐观锁的文章就介绍到这了,更多相关Java悲观锁和乐观锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！