对象锁无独立生命周期，其获取与释放由synchronized执行逻辑决定：进入同步块时获取，正常结束、抛异常或调用wait()时释放；sleep/yield等不释放锁；ReentrantLock通过显式lock/unlock提供更可控的生命周期管理。
Java 中对象锁本身没有独立的“生命周期”，它依附于被同步的对象和持有锁的线程，其存在与释放完全由同步块（synchronized）的执行逻辑和线程行为决定。真正需要关注的是：锁何时被获取、何时被释放、哪些操作会触发释放，以及这些行为如何影响资源竞争的协调效果。
对象锁的获取与释放时机
对象锁（即监视器锁，monitor lock）不是创建出来的实体，而是 JVM 在线程进入 synchronized 块或方法时，对目标对象（或类）施加的一种排他性访问控制机制。它的“表现”体现在以下关键节点：
-
获取锁：线程执行到
synchronized(obj)或同步实例方法时，若 obj 的监视器未被占用，则立即获得锁；否则进入同步队列等待（Blocked 状态）。 -
自动释放锁：仅在以下三种情况发生时，JVM 自动释放该锁：
- 同步代码块/方法正常执行完毕；
- 同步代码中抛出未捕获异常；
- 线程在已持锁状态下调用
obj.wait()—— 此时不仅释放锁，还进入等待队列（Waiting 状态）。
-
不释放锁的操作：如
Thread.sleep()、Thread.yield()、join()或 I/O 阻塞，线程虽让出 CPU 或暂停执行，但仍持有对象锁，其他线程无法进入临界区。
锁与资源竞争的协同关系
对象锁的核心作用是串行化对共享资源的访问。它的“生命周期表现”直接决定了资源竞争是否被有效管控：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 若多个线程争抢同一把对象锁（如保护数据库连接池、文件句柄等），只有获得锁的线程能执行临界区逻辑，其余线程阻塞在同步队列，避免并发修改或状态错乱。
- 锁的可重入性允许同一线程多次进入同一同步块（如递归调用或嵌套同步），避免自锁死，但需注意：这不改变锁对外部线程的排他性。
- 一旦锁被释放（如方法返回），下一个等待线程才能获取并继续操作资源——这种“获取→使用→释放”的闭环，构成了资源安全访问的基本节奏。
常见误用导致的生命周期错觉
开发者有时误以为锁有“存活时间”或可手动管理，实际中容易踩坑：
立即学习“Java免费学习笔记（深入）”；
-
锁对象变更：若同步使用的对象引用被重新赋值（如
obj = new Object()），新线程同步的是新对象，原锁对旧对象失效，资源保护失效。 -
锁粒度不当：用过大或过小的对象作为锁，会导致不必要的串行（性能瓶颈）或保护不足（竞态条件）。例如，用
this锁整个实例，但只有一小段逻辑需同步。 - 忽略资源本身的生命周期：对象锁管得了临界区执行顺序，但管不了底层资源（如文件流、连接）是否已关闭。即使锁还在，资源可能已失效，引发运行时异常。
替代方案中的锁生命周期更可控
相比内置锁，java.util.concurrent.locks.ReentrantLock 提供了显式获取与释放能力，使“锁生命周期”更贴近业务逻辑：
- 可通过
lock()和unlock()精确控制锁的作用范围，支持非阻塞尝试（tryLock()）、超时获取、响应中断等； - 必须在
finally块中调用unlock()，否则易造成永久阻塞——这强制开发者明确界定锁的起止边界； - 结合
Condition替代wait()/notify()，等待/唤醒语义更清晰，避免因锁对象混用导致的虚假唤醒。
