java线程使用lock接口需显式调用lock()和unlock()，且unlock()必须置于finally块中；常用reentrantlock实现可重入锁；支持lock()、lockinterruptibly()、trylock()三种加锁方式；配合condition可实现精准线程通信。

Java 线程使用 Lock 接口加锁，核心是**显式获取与释放锁**，必须手动调用 lock() 和 unlock()，且 unlock() 一定要放在 finally 块中，否则容易导致死锁或资源泄漏。

创建 Lock 实例并加锁

最常用的是 ReentrantLock，它是 Lock 接口的标准可重入实现：

• 声明一个 Lock 类型变量，初始化为 new ReentrantLock()
• 在需要同步的代码前调用 lock.lock() —— 若锁空闲则立即获得，否则线程阻塞等待
• 同步逻辑写在 try 块中，确保业务执行不受中断影响
• finally 中必须调用 lock.unlock()，哪怕发生异常也要释放锁

三种加锁方式的区别与适用场景

Lock 提供了比 synchronized 更精细的锁控制能力：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• lock()：阻塞式抢锁，不响应中断，适合简单、确定能拿到锁的场景
• lockInterruptibly()：可中断抢锁，线程在等待时收到 interrupt() 会抛出 InterruptedException 并退出等待，适合需响应外部取消的长时间操作（如任务调度）
• tryLock() 或 tryLock(long, TimeUnit)：非阻塞或限时抢锁，失败立即返回 false 或超时后返回 false，适合避免死等、实现乐观并发控制（如库存扣减、抢红包）

务必配对使用 unlock() 且放在 finally 中

这是使用 Lock 最关键也最容易出错的一点：

• 忘记 unlock() → 锁永远不释放 → 其他线程永久阻塞
• 只在 try 里 unlock() → 发生异常时跳过 → 锁未释放
• 正确写法：无论是否异常、是否抢锁成功，只要调用了 lock()，就必须在 finally 中对应一次 unlock()

配合 Condition 实现精准线程通信

当需要“等待某个条件成立再继续”，Lock 比 synchronized + wait/notify 更灵活：

• 通过 lock.newCondition() 创建绑定到该锁的 Condition 对象
• 线程在持有锁的前提下调用 condition.await() → 释放锁并挂起
• 其他线程完成条件后，调用 condition.signal() 或 signalAll() 唤醒等待线程
• 被唤醒线程重新竞争锁，获得锁后从 await() 返回，继续执行

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南