不得不了解的Java：乐观锁与悲观锁详解

不得不了解的Java：乐观锁与悲观锁详解 ?

大家好，我是闫工！今天我们要聊一个非常有意思的话题——乐观锁与悲观锁。这俩“锁”虽然听起来像是武侠小说里的武器，但在Java世界里，它们可是解决并发问题的神器！无论你是刚入行的小白，还是已经摸爬滚打多年的资深工程师，这个知识点都必须烂熟于心。毕竟，在多线程编程的世界里，“锁”就是你的安全带，没有它，你随时可能“翻车”。好了，话不多说，咱们马上进入正题！

一、什么是乐观锁与悲观锁？

在讲具体细节之前，我得先让你明白：乐观锁和悲观锁都是用来解决并发问题的机制。简单来说，就是多个线程同时操作同一个资源时，如何保证数据的一致性和正确性。

悲观锁：像老股民一样谨慎

悲观锁的态度是：“这世界上没有免费的午餐，数据随时可能被修改，我要提前占位。”它会在读取数据时就加上一个锁（比如共享锁或排他锁），防止其他线程在当前事务未提交前进行修改。这种锁机制的特点是独占性高、安全性强，但也会导致并发性能较差。

乐观锁：像年轻人一样自信

而乐观锁则相反，它认为：“数据被同时修改的概率很低，我先干，有问题再说。”乐观锁不会在读取时加锁，而是假设其他线程也不会同时修改这个数据。如果提交时发现数据已经被修改过，就回滚事务重新尝试。这种机制的特点是并发性能高、开销小，但在写多于读的场景下可能效率较低。

二、乐观锁与悲观锁的区别

为了更直观地理解两者的区别，我来画个表格对比一下：

三、如何在Java中实现乐观锁与悲观锁？

接下来，咱们来看看在Java中具体怎么实现这两种锁机制。

1. 悲观锁的实现

悲观锁最经典的实现方式是通过数据库的锁机制。比如，在MySQL中，可以通过SELECT ... FOR UPDATE语句来实现行锁。这样可以保证在事务提交前，其他线程无法修改该数据。

示例代码：使用JPA实现悲观锁

假设我们有一个用户表，想在更新用户信息时加锁：

@TransactionalpublicvoidupdateUser(Useruser){// 使用乐观锁的版本字段version进行更新Stringsql="SELECT * FROM User WHERE id = ? FOR UPDATE";UserexistingUser=jdbcTemplate.queryForObject(sql,newObject[]{user.getId()},User.class);// 模拟业务逻辑，修改用户信息existingUser.setName(user.getName());existingUser.setAge(user.getAge());StringupdateSql="UPDATE User SET name=?, age=?, version=? WHERE id=? AND version=?";jdbcTemplate.update(updateSql,existingUser.getName(),existingUser.getAge(),existingUser.getVersion()+1,existingUser.getId(),existingUser.getVersion());}

注意：虽然这里用了FOR UPDATE，但实际上这属于悲观锁的实现方式。而后面的更新逻辑却用了乐观锁的思想（基于版本号）。这个例子只是为了说明两者的结合使用。

2. 乐观锁的实现

乐观锁的核心思想是“边干边看”，常见的方式是通过版本号机制或时间戳机制来实现。每次更新数据时，系统会检查当前版本是否与预期一致，如果不一致则回滚事务。

示例代码：使用JPA实现乐观锁

在Spring Data JPA中，可以使用@Version注解来自动管理版本号：

@EntitypublicclassUser{@IdprivateLongid;privateStringname;privateIntegerage;@VersionprivateIntegerversion;}

更新用户信息时，JPA会自动生成类似以下的SQL语句：

UPDATEUserSETname=?,age=?,version=?WHEREid=?ANDversion=?

这样可以确保只有在版本号匹配的情况下才能更新数据。

四、乐观锁与悲观锁的选择

那么问题来了：什么时候该用乐观锁，什么时候该用悲观锁？这个问题没有标准答案，但有一些经验可以参考：

1. 数据竞争激烈时，悲观锁更安全

比如，在银行转账场景中，两个线程同时操作同一个账户，如果使用乐观锁可能会导致ABA问题（即数据被多次修改，最终结果不一致）。此时，悲观锁能确保每次操作的原子性。

示例代码：银行转账中的悲观锁

@Transactional(isolation=Isolation.SERIALIZABLE)publicvoidtransferMoney(LongfromId,LongtoId,BigDecimalamount){// 读取双方账户余额（加锁）AccountfromAccount=accountRepository.findByIdForUpdate(fromId);AccounttoAccount=accountRepository.findByIdForUpdate(toId);// 执行转账fromAccount.setBalance(fromAccount.getBalance().subtract(amount));toAccount.setBalance(toAccount.getBalance().add(amount));// 提交事务accountRepository.save(fromAccount);accountRepository.save(toAccount);}

注意：isolation = Isolation.SERIALIZABLE表示使用最高的隔离级别，确保所有操作都是串行化的。

2. 数据读多写少时，乐观锁更高效

比如，在电商系统的商品详情页，大多数时间是读操作，只有少数时候才会修改商品信息。此时，乐观锁能极大提升并发性能。

示例代码：商品详情中的乐观锁

@EntitypublicclassProduct{@IdprivateLongid;privateStringname;privateBigDecimalprice;@VersionprivateIntegerversion;}@ServicepublicclassProductService{@TransactionalpublicvoidupdateProductPrice(Longid,BigDecimalnewPrice){// 读取商品信息（不加锁）Productproduct=productRepository.findById(id).orElseThrow(()->newRuntimeException("Product not found"));// 模拟价格计算product.setPrice(newPrice);// 使用乐观锁更新productRepository.save(product);}}

五、常见误区与注意事项

在实际开发中，很多人对乐观锁和悲观锁的理解存在误区。咱们一起来看看：

1. 锁级别越低越好？

不完全是！锁级别（比如Read Committed、Repeatable Read）越高，安全性越好，但并发性能越差。需要根据业务场景权衡。

示例代码：设置事务隔离级别

@Transactional(isolation=Isolation.READ_COMMITTED)publicvoidsomeMethod(){// 业务逻辑}

2. 版本号只能用整数？

不，也可以使用时间戳或其他唯一标识。比如：

@EntitypublicclassUser{@IdprivateLongid;privateStringname;@VersionprivateTimestampversion;// 使用时间戳作为版本号}

3. 悲观锁一定会降低性能？

不，如果业务场景确实需要高并发下的数据一致性，悲观锁可能是更好的选择。比如，在秒杀系统中，使用乐观锁可能会导致大量重复操作，而悲观锁能有效减少这种情况。

六、总结

• 悲观锁：适合数据竞争激烈、一致性要求高的场景。
• 乐观锁：适合读多写少的场景，能提升并发性能。
• 选择的关键点：业务需求和数据特点，而不是盲目追求某一种锁机制。

希望这篇长文能帮助你更好地理解乐观锁与悲观锁的区别与实现方式。如果还有疑问，欢迎留言讨论！

📚 领取 | 1000+ 套高质量面试题大合集（无套路，闫工带你飞一把）！

成体系的面试题，无论你是大佬还是小白，都需要一套JAVA体系的面试题，我已经上岸了！你也想上岸吗？

闫工精心准备了程序准备面试？想系统提升技术实力？闫工精心整理了1000+ 套涵盖前端、后端、算法、数据库、操作系统、网络、设计模式等方向的面试真题 + 详细解析，并附赠高频考点总结、简历模板、面经合集等实用资料！

✅ 覆盖大厂高频题型
✅ 按知识点分类，查漏补缺超方便
✅ 持续更新，助你拿下心仪 Offer！

📥免费领取👉 点击这里获取资料

已帮助数千位开发者成功上岸，下一个就是你！✨