17370845950

锁用于多线程“排队用资源”，防止竞态条件导致数据错误；synchronized适用于简单场景，ReentrantLock支持超时、中断、Condition等高级功能；读多写少时应选用ReadWriteLock；锁应尽量细粒度、短临界区，避免滥用。

锁的作用，就是让多线程“排队用资源”，避免几个线程同时改同一个变量，导致结果错乱、数据丢失或程序崩溃。

为什么不用锁就会出问题？

比如两个线程同时执行 count++（本质是“读→改→写”三步），若没锁保护，可能出现：线程A读到 count=5，还没来得及+1；线程B也读到 count=5；两者都写回 6——最终结果是6，而不是预期的7。这就是典型的竞态条件（race condition）。

常见错误现象包括：

• 计数器总比预期少
• 缓存里反复存入旧值
• 对象状态不一致（如订单已支付但库存未扣）

synchronized 和 ReentrantLock 怎么选？

绝大多数简单同步场景，直接用 synchronized 就够了——它自动加锁、自动释放（哪怕抛异常），不易出错。

但遇到这些情况，就得换 ReentrantLock：

• 需要超时获取锁（lock.tryLock(3, TimeUnit.SECONDS)），避免无限等待
• 需要响应中断（lock.lockInterruptibly()），让线程能被 Thread.interrupt() 唤醒
• 需要绑定多个 Condition 实现精准唤醒（比如生产者只唤醒消费者，不唤醒其他生产者）
• 需要查询锁持有者、等待队列长度等诊断信息

⚠️ 注意：ReentrantLock 必须在 finally 块中调用 unlock()，漏写会导致锁永远不释放——这是新手最常踩的坑。

读多写少时，别硬用独占锁

如果一个资源90%时间被读、10%被写（比如配置项、用户权限缓存），用 synchronized 或 ReentrantLock 会让所有读线程排队，严重拖慢吞吐量。

这时该用 ReentrantReadWriteLock：

• 多个线程可同时持有 readLock()（读读不互斥）
• 写操作必须独占 writeLock()（写写互斥、读写互斥）
• 注意：读锁不升级为写锁！不能在持读锁时再申请写锁，会死锁

public class ConfigCache {
    private String config;
    private final ReadWriteLock lock = new ReentrantReadWriteLock();

    public String get() {
        lock.readLock().lock();
        try {
            return config;
        } finally {
            lock.readLock().unlock();
        }
    }

    public void update(String newConfig) {
        lock.writeLock().lock();
        try {
            this.config = newConfig;
        } finally {
            lock.writeLock().unlock();
        }
    }
}

锁不是万能解药，滥用反而更慢

锁解决的是“正确性”，不是“性能”。过度加锁、锁粒度太粗、持有时间太长，会把并发变成串行。

容易被忽略的关键点：

• synchronized 方法默认锁的是当前实例（this），静态方法锁的是类对象（MyClass.class）——混用可能锁错目标
• JVM 会做锁优化（如偏向锁、轻量级锁、锁消除），但这些只在特定条件下生效；不要依赖它们来掩盖设计缺陷
• 真正高并发场景（如百万QPS），要考虑无锁方案（AtomicInteger、CAS、Disruptor）或分段锁（ConcurrentHashMap 内部实现）

记住：锁的边界越小越好，临界区越短越好，能用原子类就别用锁，能读写分离就别全用独占锁。