乐观锁与悲观锁是两种并发控制思想：悲观锁假设冲突必然发生，操作前加锁阻塞其他线程，适用于写多、高冲突、强一致场景；乐观锁假设冲突极少，不加锁，提交时校验版本或cas，适用于读多、低冲突、可重试场景。

乐观锁和悲观锁不是具体某把“锁”，而是两种应对并发问题的设计思想。核心区别在于：一个提前加锁防冲突，一个先干再说、提交时再验。

悲观锁：先锁住，再操作

悲观锁认为“别人随时会改数据”，所以一上来就抢锁，确保自己独占资源。锁没拿到，线程就得等——这是典型的阻塞式行为。

• 典型实现：数据库的 SELECT ... FOR UPDATE、Java 的 synchronized、ReentrantLock
• 适用场景：写操作频繁、冲突概率高、强一致性不可妥协的地方，比如银行转账、秒杀扣库存
• 注意点：容易引发死锁或长事务阻塞；锁粒度越细（如行锁）性能越好，但管理更复杂

乐观锁：不锁，只校验

乐观锁相信“多数时候没人跟我抢”，读数据时不加锁，更新时才比对数据是否被改过。如果发现已被动过手脚，就放弃或重试。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 典型实现：数据库加 version 字段 + WHERE version = ?；Java 的 AtomicInteger（底层是 CAS）；JPA 中的 @Version 注解
• 适用场景：读多写少、冲突率低、可接受短暂不一致的业务，比如文章点赞数、用户资料轻量更新
• 注意点：高冲突下重试频繁会浪费 CPU；CAS 存在 ABA 问题（值变回原样但中间已变化），需配合带时间戳的原子引用解决

怎么选？看冲突频率和一致性要求

没有绝对好坏，关键看业务特征：

• 若写操作占比超过 30%、失败重试代价大、必须零误差——选悲观锁
• 若读操作远多于写、冲突极少、允许少量重试——选乐观锁更轻量高效
• 混合场景可分层处理：比如用乐观锁做初筛，冲突后降级为悲观锁兜底

实际代码中常见搭配

真实项目往往不是非此即彼：

• 数据库层用 FOR UPDATE 防超卖，应用层用 @Version 避免覆盖式更新
• 计数类高频读写用 AtomicLong（乐观+CAS），避免 synchronized 带来的串行瓶颈
• 分布式环境下单机锁失效，常结合 Redis 分布式锁（悲观）或 ZooKeeper 临时节点（类乐观）来协同

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南