乐观锁和悲观锁

目录

1.乐观锁

乐观锁的实现：

乐观锁的优缺点：

ABA问题：

2.悲观锁

悲观锁的实现：

悲观锁的优缺点：

3.乐观锁和悲观锁的区别：

---

1.乐观锁

乐观锁是一种并发控制机制，其核心思想是在操作数据时，首先假设数据一般来说并不会发生冲突，因此不立即对数据加锁，而是在对数据进行更新前，检查数据是否被其他事务修改过。如果数据未被修改，则允许当前事务继续进行操作；如果数据已被修改，则当前事务可能需要进行回滚、重试等操作。

乐观锁的实现：

乐观锁的实现通常是版本号法和CAS法。在数据中引入版本号（Version Number）或时间戳（Timestamp）等字段，用于标识数据的版本。在事务进行数据更新操作时，会将查询出的版本号或时间戳一并提交，数据库会根据提交的版本号或时间戳和数据库中的当前版本号或时间戳进行比对，以判断数据是否被修改。如果提交的版本号或时间戳与数据库中的当前版本号或时间戳一致，则允许数据更新；否则拒绝更新操作。

乐观锁的优缺点：

优点：

1. 减少锁的使用：相对于悲观锁，乐观锁能够降低对数据的锁定，提高了并发更新数据的能力。
2. 减少系统开销：不需要频繁地加锁和解锁，可以减少系统开销。
3. 适用于读多写少的情况：在读多写少的应用场景下，乐观锁的使用更为合适，可以减少锁争用的情况。

缺点：

1. 可能需要重试：由于并发冲突的可能性，当数据版本号不一致时需要终止事务处理，并重新尝试。这可能会增加系统负担。
2. 无法防止写冲突：如果并发更新的操作较多，那么乐观锁会导致更多的冲突，增加了处理冲突的可能性，可能增加了资源的浪费。
3. 版本维护：需要为每个数据行维护版本信息，占用了额外的存储空间。

总的来说，乐观锁适用于读多写少的应用场景，能够减少锁的使用, 提高数据库并发性能，但需要开发者在编程时注意并发冲突的处理，以确保数据的一致性。在高并发和写多场景下，需要谨慎使用乐观锁，并考虑实际的业务复杂性，权衡。

ABA问题：

在乐观锁中，ABA问题通常指一个共享变量的版本在检查和修改期间经历了如下情况：初始值为A，然后经历了其他操作变成了B，最后又变回A。在这种情况下，乐观锁的版本检查机制可能会认为数据并未被修改，导致并发操作出现问题。

为了解决乐观锁的ABA问题，通常会使用带有标签的版本号或者使用CAS（Compare and Swap）原子操作来确保检测到数据真实的变化。

下面是一个简单的Java代码示例，演示了如何使用AtomicStampedReference类来解决ABA问题：

import java.util.concurrent.atomic.AtomicStampedReference;

public class OptimisticLockingExample {
    private AtomicStampedReference<String> data = new AtomicStampedReference<>("initialValue", 0);

    public void updateData(String newValue) {
        int[] stampHolder = new int[1];
        String oldValue = data.get(stampHolder);
        while (true) {
            if (data.compareAndSet(oldValue, newValue, stampHolder[0], stampHolder[0] + 1)) {
                // 修改成功
                break;
            } else {
                // 版本号已经发生变化，进行重试或者其他处理
                oldValue = data.get(stampHolder);
            }
        }
    }
}

在上面的示例中，使用了AtomicStampedReference类来包装共享变量，其中版本号以及数值都被记录下来。在更新数据时，通过compareAndSet方法进行原子性的判断和更新，如果版本号发生变化，则需要进行重试或者其他处理。

2.悲观锁

悲观锁是一种并发控制机制，它基于“悲观”的假设，即并发访问会导致数据被其他事务修改的可能性较大。因此，悲观锁在并发访问时会采取阻塞或者独占的方式，来确保同一时刻只有一个事务可以对数据进行操作，以避免数据一致性问题。

悲观锁的实现：

在实际应用中，可以通过不同的方式实现悲观锁，以确保对共享资源的独占访问。以下是几种常见的悲观锁实现方式：

1. 数据库级别的悲观锁：在关系型数据库中，可以通过数据库提供的锁机制来实现悲观锁。常见的数据库锁包括行级锁、表级锁、页级锁等。通过在事务中使用SELECT ... FOR UPDATE语句或者BEGIN TRANSACTION WITH LOCK命令，可以对数据进行加锁，以阻止其他事务对相同数据的访问和修改。

2. 锁机制：在编程语言中，可以使用锁机制来实现悲观锁。例如，在Java中，可以使用synchronized关键字、ReentrantLock类等来实现对共享资源的独占访问。下面是一个使用ReentrantLock类的简单示例：

import java.util.concurrent.locks.ReentrantLock;

public class PessimisticLockExample {
    private ReentrantLock lock = new ReentrantLock();

    public void performOperation() {
        lock.lock();
        try {
            // 在锁保护的临界区内对共享资源进行操作
        } finally {
            lock.unlock();
        }
    }
}

1. 信号量：信号量是一种用于控制对共享资源访问的同步机制。通过使用信号量，可以限制同时访问共享资源的线程数量，从而实现悲观锁的效果。在Java中，可以使用Semaphore类来实现信号量控制。

除了上述方式，还有一些其他方法可以实现悲观锁，比如数据库中的悲观锁机制、分布式锁、链表锁等。

悲观锁的优缺点：

优点：

1. 数据一致性：悲观锁可以确保在同一时刻只有一个事务可以对共享资源进行访问和修改，从而有效地避免了由并发访问引起的数据不一致问题。

2. 简单直观：悲观锁通常比较直观，并且易于理解和使用。在使用编程语言提供的锁机制或数据库提供的锁机制时，通常只需简单地对关键代码块进行加锁。

3. 避免竞争条件：悲观锁可以有效地避免多个事务对相同资源进行争夺和竞争，从而降低了并发访问可能导致的问题。

缺点：

1. 性能开销：悲观锁通常需要进行阻塞或者等待操作，以确保同一时刻只有一个事务可以访问共享资源，这可能导致较高的性能开销。特别是在高并发场景下，悲观锁可能会引起大量线程阻塞，从而影响系统的吞吐能力。

2. 死锁风险：由于悲观锁可能引起事务阻塞，如果在并发环境中使用不当，可能会出现死锁的情况，从而影响系统的稳定性和可用性。

3. 可伸缩性差：悲观锁通常使得多个事务难以同时对共享资源进行访问和修改，这可能降低系统的并发性能和可伸缩性。

综合考虑，悲观锁适用于对数据一致性要求较高、并发访问量相对较低的场景。在高并发、大规模的分布式系统中，可能需要更多的考虑乐观锁等并发控制机制，以获得更好的性能和吞吐能力。

3.乐观锁和悲观锁的区别：

乐观锁和悲观锁是两种常见的并发控制机制，它们在处理多个事务对共享资源进行访问和修改时具有不同的思想和实现方式。以下是它们的主要区别：

1. 思想差异：

   • 乐观锁：乐观锁的思想是认为在一般情况下并发冲突较少发生，因此允许多个事务同时对共享资源进行读取和修改，只在更新时检查共享资源是否发生冲突。如果检测到冲突，可以采取回滚等方式进行处理。
   • 悲观锁：悲观锁的思想是认为并发冲突发生的可能性较大，因此在对共享资源进行访问时持有悲观的态度，先进行加锁，以阻止其他事务对资源进行访问。

2. 实现方式：

   • 乐观锁：乐观锁通常通过版本号、时间戳等机制来进行并发冲突的检测和解决。在读取数据时不加锁，在更新数据时校验数据是否被其他事务修改，若未被修改则进行更新，若已被修改则进行冲突处理。
   • 悲观锁：悲观锁依赖于锁机制，在对共享资源进行访问时先进行加锁，以阻止其他事务的访问。

3. 性能开销：

   • 乐观锁：乐观锁在正常情况下不进行加锁操作，因此有利于提高并发度和性能。但在发生并发冲突时需要进行冲突处理，可能带来一定的性能开销。
   • 悲观锁：悲观锁在访问共享资源时进行加锁操作，可能导致多个事务的阻塞和等待，带来一定的性能开销。

总的来说，乐观锁适用于读多写少的场景，以及并发冲突相对较少的情况；而悲观锁适用于对数据一致性要求较高的场景，以及并发访问量较大的情况