Java用Lock实现线程同步方法详解

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《Java如何用Lock实现线程同步》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

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：

Lock fairLock = new ReentrantLock(true);

• 公平锁能减少线程饥饿，但每次获取都要遍历等待队列，吞吐量明显下降
• 除非明确遇到“某些线程长期抢不到锁”的问题，否则别开公平模式
• 公平性只影响等待队列中的线程顺序，不影响已持有锁的线程继续重入

真正难处理的，是锁的粒度和持有时间——锁太粗会拖慢并发，太细则容易引发死锁或重复加锁。这些没法靠Lock接口本身解决，得靠设计时厘清共享状态边界。

今天关于《Java用Lock实现线程同步方法详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！