Java中悲观锁和乐观锁的核心区别是什么？

Question

在Java并发编程中，悲观锁与乐观锁的核心区别在于**对并发冲突的预判与处理策略不同**： 悲观锁假设“写操作频繁、冲突大概率发生”，因此在操作前就加锁（如`synchronized`、`ReentrantLock`），独占资源直至事务完成，以阻塞方式保证一致性； 乐观锁则假设“读多写少、冲突概率低”，不加锁，而是在更新时通过CAS（如`AtomicInteger`）或版本号（如数据库`version`字段）校验数据是否被修改，若已变更则重试或失败。 二者本质是**时间换空间 vs 空间换时间**：悲观锁用线程阻塞换取数据安全，适合高冲突场景；乐观锁避免锁开销提升吞吐，但依赖重试机制，高争用下可能引发ABA问题或大量自旋浪费CPU。 实际选型需结合业务场景——金融扣款倾向悲观锁，计数器类场景常用乐观锁。

Answer 1

```html

一、概念层：什么是悲观锁与乐观锁？

在Java并发编程中，悲观锁（Pessimistic Locking）与乐观锁（Optimistic Locking）并非JVM内置的“锁类型”，而是两种截然不同的并发控制哲学。悲观锁将并发视为“危险常态”，默认任何写操作都可能引发冲突，因此提前加锁；乐观锁则将并发视为“安全例外”，默认读写极少冲突，仅在提交更新时做轻量校验。

这种根本性差异直接决定了其技术实现路径：前者依赖JVM级同步原语（如monitor），后者依托无锁算法（CAS）或应用层协议（如version字段）。二者不是互斥的API选择，而是系统架构师在设计高并发模块时必须权衡的第一性原理。

二、机制层：底层实现与关键差异

• 悲观锁实现：基于操作系统互斥量（mutex）或JVM monitor机制。例如：synchronized隐式获取对象监视器，ReentrantLock显式调用AQS队列阻塞线程。
• 乐观锁实现：Java中以java.util.concurrent.atomic包为核心，如AtomicInteger.compareAndSet()调用Unsafe类的CAS指令；数据库层面则需配合UPDATE ... WHERE version = ?语义。

三、性能特征对比分析

维度	悲观锁	乐观锁
线程调度开销	高（涉及内核态切换、队列管理、唤醒延迟）	极低（纯用户态原子指令，无上下文切换）
内存占用	低（仅需锁对象头Mark Word或AQS Node）	较高（需额外存储版本号/时间戳/CAS标记位）
吞吐量稳定性	随争用加剧急剧下降（线程阻塞→CPU空转+调度抖动）	在低争用下接近线性扩展；高争用时因重试导致CPU自旋飙升

四、典型问题与深度陷阱

乐观锁在真实场景中面临三大经典挑战：

1. ABA问题：值从A→B→A，CAS误判为未修改。Java通过AtomicStampedReference引入版本戳解决；但业务语义上“两次A”未必等价（如账户余额归零后又充值）。
2. 循环时间浪费：高并发写场景下，CAS失败率超70%，线程持续自旋消耗CPU，甚至触发JVM自适应自旋策略失效。
3. 单点更新瓶颈：所有线程竞争同一变量的CAS，形成“伪共享”（False Sharing）热点，L3缓存行频繁失效，性能反低于细粒度悲观锁。

五、工程选型决策树（Mermaid流程图）

flowchart TD
    A[写操作占比 > 30%?] -->|Yes| B[是否强一致性不可妥协?]
    A -->|No| C[读多写少 & 冲突率 < 5%?]
    B -->|Yes| D[✅ 优先悲观锁
synchronized / ReentrantLock]
    B -->|No| E[评估乐观锁+重试退避策略]
    C -->|Yes| F[✅ 优先乐观锁
AtomicXXX / 版本号机制]
    C -->|No| G[混合方案：
分段锁/读写锁/StampedLock]

六、实战代码对比：银行转账 vs UV计数器

悲观锁示例（金融扣款）：

public class BankAccount {
    private final ReentrantLock lock = new ReentrantLock();
    private volatile BigDecimal balance;

    public void transfer(BankAccount target, BigDecimal amount) {
        // 双重锁定防死锁（按对象哈希码排序）
        Lock first = this.hashCode() < target.hashCode() ? this.lock : target.lock;
        Lock second = this.hashCode() < target.hashCode() ? target.lock : this.lock;
        first.lock(); second.lock();
        try {
            if (this.balance.compareTo(amount) >= 0) {
                this.balance = this.balance.subtract(amount);
                target.balance = target.balance.add(amount);
            }
        } finally {
            second.unlock(); first.unlock();
        }
    }
}

乐观锁示例（UV统计）：

public class UVCounter {
    private final AtomicInteger counter = new AtomicInteger(0);
    private final Set seenIds = ConcurrentHashMap.newKeySet();

    public long incrementIfNew(String userId) {
        if (seenIds.add(userId)) { // CAS-based add in CHM
            return counter.incrementAndGet();
        }
        return counter.get(); // 无需更新，返回当前值
    }
}

七、高阶演进：混合锁与新一代方案

现代Java并发库已超越简单二分法：

• StampedLock提供乐观读+悲观写组合，在读多写少且读操作耗时长的场景下，比ReentrantReadWriteLock减少50%以上读线程阻塞。
• Loom项目中的虚拟线程（Virtual Threads）使悲观锁的“阻塞成本”大幅降低——百万级线程可共存，让传统高开销悲观锁在I/O密集型服务中重获竞争力。
• Rust风格的RefCell<T>思想正渗透至Java生态：如VarHandle + 内存屏障 + 自定义校验逻辑，构建领域专属的轻量乐观协议。

```