对象锁的获取与释放直接决定线程状态转换：获取失败进入BLOCKED，正常退出或异常时自动释放锁，wait()主动释放并进入WAITING/TIMED_WAITING，sleep/yield不释放锁。
Java 中对象锁的获取与释放，直接决定线程能否进入临界区、是否被挂起、以及何时恢复执行。它不是独立于线程状态存在的机制，而是和线程生命周期深度耦合的关键环节。
对象锁获取导致线程进入 BLOCKED 状态
当一个线程尝试进入 synchronized 方法或代码块，而该对象锁已被其他线程持有时，当前线程无法立即执行，会转入 BLOCKED 状态。此时它被挂起，不占用 CPU，也不参与调度，只在锁释放后由 JVM 唤醒并重新竞争锁。
- BLOCKED 是“等待锁”的状态，不是“正在运行中等待某事”，比如 IO 或 sleep 那样的阻塞
- 多个线程争抢同一把对象锁时，只有一个能成功获取，其余全部 BLOCKED
- 一旦持有锁的线程退出同步块（正常结束或抛出异常），锁被释放，JVM 从等待队列中唤醒至少一个 BLOCKED 线程，它转为 RUNNABLE 状态参与锁竞争
对象锁释放触发 WAITING/TIMED_WAITING 状态转换
调用 wait() 是唯一能在持有锁的前提下主动释放锁的操作。线程释放锁后，并不会回到 RUNNABLE，而是进入 WAITING（或 TIMED_WAITING）状态，等待其他线程 notify/notifyAll 或超时唤醒。
- wait() 必须在 synchronized 块内调用，否则抛出 IllegalMonitorStateException
- 执行 wait() 后，线程立刻释放对象锁，并进入该对象的等待队列（wait set）
- notify() 只唤醒一个等待线程，notifyAll() 唤醒全部；被唤醒的线程不会立即执行，而是先重新竞争该对象锁，抢到后才从 wait() 返回，继续后续逻辑
- sleep() 和 yield() 不释放锁，所以它们不会导致线程离开 BLOCKED 或 WAITING 状态去争夺锁
锁自动释放的三种明确时机
对象锁不是靠手动 close 或 unlock 释放的，而是由 JVM 在特定语义边界自动管理：
立即学习“Java免费学习笔记（深入）”；
- 同步代码块或方法正常执行完毕：锁随作用域退出自动返还
- 同步代码块中发生未捕获异常：JVM 在异常传播前确保锁被释放，避免死锁
- 线程调用 wait()：主动让出锁并转入等待，这是唯一可编程控制的“提前释放”方式
锁持有期间线程状态的稳定性
只要线程持有对象锁，它就始终处于 RUNNABLE 状态（即使实际被操作系统暂停或在 sleep），因为 JVM 层面认为它“有资格运行”。这点容易误解：
- Thread.sleep(1000) 在 synchronized 块里执行 → 线程仍持有锁，状态是 TIMED_WAITING，但锁未释放
- IO 阻塞（如 socket.read()）→ 状态仍是 RUNNABLE（JVM 不感知底层阻塞），锁依然被占着
- 只有 wait()、异常退出、同步块结束这三类事件，才会真正改变锁的归属
