面试官: 什么时候用乐观锁,什么时候用悲观锁?
我回答:
乐观锁和悲观锁是两种常用的并发控制策略，它们在多线程环境下用于保护共享资源免受并发修改的问题。下面我们将详细讨论这两种锁的使用场景和优缺点，以便你在实际开发中能够根据具体情况做出合适的选择。
悲观锁
悲观锁（Pessimistic Locking）假设最坏的情况，即认为数据非常有可能会发生冲突，所以在数据被读取的时候就开始加锁，直到修改完毕释放锁。对共享资源的访问会产生冲突，因此默认认为每次访问都会发生冲突，需要加锁保证独占访问。
特点
- 加锁时机：在开始操作数据之前加锁。
- 解锁时机：在完成数据操作后解锁。
- 适用场景：
- 数据更新频繁，竞争激烈。
- 数据一致性要求非常高。
- 对性能要求不高，可以接受较高的锁等待时间。
优点
- 确保了数据的一致性。
- 在高竞争的情况下，可以有效地避免数据冲突。
缺点
- 锁的竞争可能导致线程等待时间较长，降低系统的整体吞吐量。
- 过度锁定可能导致线程饥饿。
实现方式：
- 可以使用
synchronized关键字或java.util.concurrent.locks包下的Lock接口的具体实现（如ReentrantLock）来实现。
乐观锁
乐观锁（Optimistic Locking）则假设最乐观的情况，即认为数据不太可能发生冲突，所以在数据被读取时不加锁，只有在更新数据的时候才判断数据是否被其他线程修改过。
在读取数据时，每个线程会获得一个标识符（如版本号或时间戳）。在提交修改之前，会比较当前标识符与之前读取的标识符是否相等，如果相等则提交成功，否则说明数据已被其他线程修改，需要进行冲突处理。
特点
- 加锁时机：在更新数据时才进行版本号比较或加锁。
- 解锁时机：如果数据版本匹配，则更新数据并释放锁；如果不匹配，则放弃本次更新。
- 适用场景：
- 数据更新不频繁，竞争不激烈。
- 数据一致性要求相对较低。
- 对性能要求较高，尽量减少锁的使用。
优点
- 减少了锁的使用，提高了系统的并发能力。
- 适用于读多写少的场景。
缺点
- 在高并发的情况下，可能会出现多次尝试更新数据的情况。
- 如果数据冲突频繁发生，性能优势会减弱。
实现方式：
- 通常使用版本号或时间戳来实现。
- 可以在数据库中添加一个额外的字段作为标识符，并在更新操作时进行比较。
- 在Java中，可以通过
java.util.concurrent.atomic包下的原子类（如AtomicInteger、AtomicLong、AtomicStampedReference等）利用CAS（Compare and Swap）算法来实现乐观锁。
选择时机
何时使用悲观锁？
- 高并发更新：如果一个资源被频繁地并发修改，悲观锁可以确保数据的一致性。
- 数据竞争激烈：当多个线程试图修改同一资源时，悲观锁可以有效防止数据冲突。
- 严格的数据一致性要求：对于金融交易、数据库事务等场景，悲观锁可以提供更强的一致性保证。
- 适用于写操作频繁的场景。
- 能够确保数据一致性和线程安全。
何时使用乐观锁？
- 低并发更新：如果资源的并发修改较少，使用乐观锁可以减少锁的竞争。
- 读多写少：当大部分操作是读取而非修改时，乐观锁可以提高并发性能。
- 性能敏感的应用：对于需要高性能的应用程序，乐观锁可以减少锁带来的性能开销。
总结
- 悲观锁 适用于数据竞争激烈的场景，能够提供强一致性，但可能导致较多的线程等待。
- 乐观锁 适用于读多写少的场景，能够提供更高的并发性能，但可能需要多次尝试才能成功更新数据。
