面视题之——悲观锁和乐观锁

概念

悲观锁

悲观锁是在执行线程任务时直接加锁，以确保同一时刻只有一个线程可以访问共享资源。在使用悲观锁时，每次访问共享资源时都会尝试获取锁，如果锁已经被其他线程占用，当前线程就会被阻塞，直到获取到锁为止。

乐观锁

乐观锁则是在执行线程任务时，不会直接加锁，而是在读取资源时会先检查资源是否已被其他线程修改。如果资源未被修改，当前线程就可以继续执行；如果资源已被修改，则需要回滚事务并重试。

在使用乐观锁时，不会直接给线程任务中执行的 SQL 方法加锁，而是通过在数据表中增加版本号或时间戳等字段来实现乐观锁。当多个线程尝试更新同一个记录时，只有一个线程能够成功更新，其他线程需要回滚事务并重试。

优缺点

悲观锁

1. 优点
   • 保证数据的完整性，不会出现数据不一致的情况。
   • 操作简单，易于实现。
2. 缺点
   • 对系统资源的占用较多，性能较低。
   • 可能会阻塞其他线程的访问，降低系统的并发性。

乐观锁

1. 优点
   • 对系统资源的占用较少，性能较高。
   • 不会阻塞其他线程的访问，提高系统的并发性。
2. 缺点
   • 可能出现数据不一致的情况，需要使用额外的机制来解决。
   • 在高并发情况下，可能会出现性能问题。

使用场景

悲观锁适用场景

• 对数据的修改非常频繁，而且对数据的完整性要求较高。
• 并发访问量较低，因此使用锁的开销相对较小。
• 操作的执行时间比较短。

乐观锁适用场景

• 对数据的修改非常频繁，但并发访问量较高。
• 对数据的完整性要求较高，但允许一定程度的数据不一致。
• 操作的执行时间较长，因此使用锁的开销相对较大。

使用乐观锁开发中的实际场景

在我们设计中后台管理系统时，我们需要设计库房管理，即此时可能存在多个管理人员同时进行入库操作，同时对一个库房信息进行访问修改，此时我们适合使用乐观锁来提高效率。

使用方法

给库房的数据库表添加一个标识字段——版本号(version)，在每次执行入库的sql语句时，执行条件中添加判断version是否是最新的，如果满足，则修改对应内容以及版本号更新(如+1）,如果不满足，则事务回滚，重新执行。

sql示例

update inventory set qty = qty + #{qty},version = version+1 where productId = #{productId} and version = #{version}