锁用于多线程“排队用资源”，防止竞态条件导致数据错误；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内部实现）
记住：锁的边界越小越好，临界区越短越好，能用原子类就别用锁，能读写分离就别全用独占锁。
