面视题之——悲观锁和乐观锁
概念
悲观锁
悲观锁是在执行线程任务时直接加锁,以确保同一时刻只有一个线程可以访问共享资源。在使用悲观锁时,每次访问共享资源时都会尝试获取锁,如果锁已经被其他线程占用,当前线程就会被阻塞,直到获取到锁为止。
乐观锁
乐观锁则是在执行线程任务时,不会直接加锁,而是在读取资源时会先检查资源是否已被其他线程修改。如果资源未被修改,当前线程就可以继续执行;如果资源已被修改,则需要回滚事务并重试。
在使用乐观锁时,不会直接给线程任务中执行的 SQL 方法加锁,而是通过在数据表中增加版本号或时间戳等字段来实现乐观锁。当多个线程尝试更新同一个记录时,只有一个线程能够成功更新,其他线程需要回滚事务并重试。
优缺点
悲观锁
- 优点
- 保证数据的完整性,不会出现数据不一致的情况。
- 操作简单,易于实现。
- 缺点
- 对系统资源的占用较多,性能较低。
- 可能会阻塞其他线程的访问,降低系统的并发性。
乐观锁
- 优点
- 对系统资源的占用较少,性能较高。
- 不会阻塞其他线程的访问,提高系统的并发性。
- 缺点
- 可能出现数据不一致的情况,需要使用额外的机制来解决。
- 在高并发情况下,可能会出现性能问题。
使用场景
悲观锁适用场景
- 对数据的修改非常频繁,而且对数据的完整性要求较高。
- 并发访问量较低,因此使用锁的开销相对较小。
- 操作的执行时间比较短。
乐观锁适用场景
- 对数据的修改非常频繁,但并发访问量较高。
- 对数据的完整性要求较高,但允许一定程度的数据不一致。
- 操作的执行时间较长,因此使用锁的开销相对较大。
使用乐观锁开发中的实际场景
在我们设计中后台管理系统时,我们需要设计库房管理,即此时可能存在多个管理人员同时进行入库操作,同时对一个库房信息进行访问修改,此时我们适合使用乐观锁来提高效率。
使用方法
给库房的数据库表添加一个标识字段——版本号(version),在每次执行入库的sql语句时,执行条件中添加判断version是否是最新的,如果满足,则修改对应内容以及版本号更新(如+1),如果不满足,则事务回滚,重新执行。
sql示例
update inventory set qty = qty + #{qty},version = version+1 where productId = #{productId} and version = #{version}