synchronized内置锁下线程阻塞行为及锁获取机制咨询

咱们来逐个拆解你的问题，把synchronized锁的行为说清楚：

1. 线程被synchronized阻塞时会执行什么操作？ #

当一个线程尝试进入被synchronized修饰的代码块或方法，而对应的内置锁已经被其他线程攥在手里时，这个线程会立刻从RUNNABLE（就绪/运行）状态切换到BLOCKED（阻塞）状态。

这时候它会做这几件事：

• 主动让出CPU使用权，不再凑CPU调度的热闹，避免浪费资源做无用功
• 被JVM放进该内置锁的**等待集合（Wait Set）**里——这个集合就是专门给等锁的线程准备的“休息室”
• 它会一直待在这个阻塞状态，直到有机会重新尝试抢锁

2. 锁被其他线程持有时，该线程会尝试重新获取锁吗？ #

不会主动循环重试——这是很多开发者容易踩的认知误区。

线程进入BLOCKED状态后，不会自己每隔一段时间就去查一查锁有没有被释放，而是完全等着JVM来喊它。简单说就是，它不会“没事就去碰运气”，而是老老实实在等待集合里待着，直到锁释放的信号传来。

3. 线程如何得知锁已释放？ #

当持有锁的线程退出同步代码块/方法（不管是正常执行完，还是中途抛出异常），它会把手里的内置锁释放掉。这时候JVM会做这些操作：

• 从该锁的等待集合里唤醒一个或多个处于BLOCKED状态的线程（具体唤醒谁，要看JVM的锁实现策略：默认的非公平锁会随机挑，公平锁则严格按等待顺序来）
• 被唤醒的线程会从BLOCKED状态切回RUNNABLE状态，重新加入CPU的调度队列
• 等轮到这个线程拿到CPU时间片时，它会再次尝试获取锁——如果这时候锁又被别的线程抢走了，它会乖乖回到BLOCKED状态，继续等下一次唤醒

内容的提问来源于stack exchange，提问作者Javdroider