高级java每日一道面试题-2024年7月29日-并发篇-什么时候用乐观锁,什么时候用悲观锁?

面试官: 什么时候用乐观锁,什么时候用悲观锁?

我回答:

乐观锁和悲观锁是两种常用的并发控制策略，它们在多线程环境下用于保护共享资源免受并发修改的问题。下面我们将详细讨论这两种锁的使用场景和优缺点，以便你在实际开发中能够根据具体情况做出合适的选择。

悲观锁

悲观锁（Pessimistic Locking）假设最坏的情况，即认为数据非常有可能会发生冲突，所以在数据被读取的时候就开始加锁，直到修改完毕释放锁。对共享资源的访问会产生冲突，因此默认认为每次访问都会发生冲突，需要加锁保证独占访问。

特点

• 加锁时机：在开始操作数据之前加锁。
• 解锁时机：在完成数据操作后解锁。
• 适用场景：
  • 数据更新频繁，竞争激烈。
  • 数据一致性要求非常高。
  • 对性能要求不高，可以接受较高的锁等待时间。

优点

• 确保了数据的一致性。
• 在高竞争的情况下，可以有效地避免数据冲突。

缺点

• 锁的竞争可能导致线程等待时间较长，降低系统的整体吞吐量。
• 过度锁定可能导致线程饥饿。

实现方式：

• 可以使用synchronized关键字或java.util.concurrent.locks包下的Lock接口的具体实现（如ReentrantLock）来实现。

乐观锁

乐观锁（Optimistic Locking）则假设最乐观的情况，即认为数据不太可能发生冲突，所以在数据被读取时不加锁，只有在更新数据的时候才判断数据是否被其他线程修改过。

在读取数据时，每个线程会获得一个标识符（如版本号或时间戳）。在提交修改之前，会比较当前标识符与之前读取的标识符是否相等，如果相等则提交成功，否则说明数据已被其他线程修改，需要进行冲突处理。

特点

• 加锁时机：在更新数据时才进行版本号比较或加锁。
• 解锁时机：如果数据版本匹配，则更新数据并释放锁；如果不匹配，则放弃本次更新。
• 适用场景：
  • 数据更新不频繁，竞争不激烈。
  • 数据一致性要求相对较低。
  • 对性能要求较高，尽量减少锁的使用。

优点

• 减少了锁的使用，提高了系统的并发能力。
• 适用于读多写少的场景。

缺点

• 在高并发的情况下，可能会出现多次尝试更新数据的情况。
• 如果数据冲突频繁发生，性能优势会减弱。

实现方式：

• 通常使用版本号或时间戳来实现。
• 可以在数据库中添加一个额外的字段作为标识符，并在更新操作时进行比较。
• 在Java中，可以通过java.util.concurrent.atomic包下的原子类（如AtomicInteger、AtomicLong、AtomicStampedReference等）利用CAS（Compare and Swap）算法来实现乐观锁。

选择时机

何时使用悲观锁？

• 高并发更新：如果一个资源被频繁地并发修改，悲观锁可以确保数据的一致性。
• 数据竞争激烈：当多个线程试图修改同一资源时，悲观锁可以有效防止数据冲突。
• 严格的数据一致性要求：对于金融交易、数据库事务等场景，悲观锁可以提供更强的一致性保证。
• 适用于写操作频繁的场景。
• 能够确保数据一致性和线程安全。

何时使用乐观锁？

• 低并发更新：如果资源的并发修改较少，使用乐观锁可以减少锁的竞争。
• 读多写少：当大部分操作是读取而非修改时，乐观锁可以提高并发性能。
• 性能敏感的应用：对于需要高性能的应用程序，乐观锁可以减少锁带来的性能开销。

总结

• 悲观锁 适用于数据竞争激烈的场景，能够提供强一致性，但可能导致较多的线程等待。
• 乐观锁 适用于读多写少的场景，能够提供更高的并发性能，但可能需要多次尝试才能成功更新数据。