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