Lock接口需手动获取和释放锁，必须在finally中调用unlock()；ReentrantLock支持重入、可中断、超时等特性；tryLock()用于非阻塞或超时获取；默认非公平，公平锁性能较差；锁粒度与持有时间需设计合理。
Lock接口比synchronized更灵活，但必须手动释放
Java里用Lock实现线程同步，核心是显式获取和释放锁，不像synchronized那样自动管理。这意味着你得自己保证unlock()一定被执行，否则会永久阻塞其他线程——这是最常踩的坑。
- 必须在
finally块中调用lock.unlock()，哪怕业务逻辑抛异常也不能跳过 -
ReentrantLock是最常用的实现类，支持重入、可中断、超时获取等特性 - 不能像
synchronized那样直接修饰方法或代码块，必须通过对象引用调用lock()和unlock()
正确写法：try-finally包裹lock/unlock
下面是最小安全模板。漏掉finally或把unlock()写在try里，都可能导致死锁。
private final Lock lock = new ReentrantLock();
public void doSomething() {
lock.lock();
try {
// 临界区代码
System.out.println("执行受保护操作");
} finally {
lock.unlock(); // 必须在这里，且只调用一次
}
}
- 不要在
catch里释放锁——异常可能发生在lock()之后、try开始之前，此时unlock()会抛IllegalMonitorStateException - 同一个
Lock实例不能被不同线程交替调用lock()/unlock()，必须成对出现在同一线程中 - 如果需要条件等待，搭配
lock.newCondition()，而不是wait()/notify()
tryLock()适合避免无限等待的场景
当线程不想一直卡在锁上，可以用tryLock()非阻塞获取，或带超时的tryLock(long, TimeUnit)。它返回boolean，成功才进临界区。
- 返回
false不代表出错，只是当前拿不到锁——你要自己决定是重试、降级还是直接返回 - 即使
tryLock()失败，也不用调用unlock()；只有它返回true后才需要配对释放 - 注意：超时时间单位必须用
TimeUnit枚举，不能传毫秒整数，否则调用的是另一个重载方法（无参版本）
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
// 执行操作
} finally {
lock.unlock();
}
} else {
// 处理获取失败，比如记录日志或返回默认值
}
公平锁不是默认选项，性能通常更差
ReentrantLock默认是非公平锁，意味着新线程可能插队成功获取锁，而排队中的线程继续等待。开启公平模式要显式传true：
立即学习“Java免费学习笔记（深入）”；
Lock fairLock = new ReentrantLock(true);
- 公平锁能减少线程饥饿，但每次获取都要遍历等待队列，吞吐量明显下降
- 除非明确遇到“某些线程长期抢不到锁”的问题，否则别开公平模式
- 公平性只影响等待队列中的线程顺序，不影响已持有锁的线程继续重入
真正难处理的，是锁的粒度和持有时间——锁太粗会拖慢并发，太细则容易引发死锁或重复加锁。这些没法靠Lock接口本身解决，得靠设计时厘清共享状态边界。
