如果线程在同步块之前等待监视器释放或调用 wait() 有什么区别吗
我读过很多关于线程状态的文档，其中一些告诉我们有两种不同的状态：阻塞（同步之前）和等待（如果调用等待），其他一些则告诉我们只有一种状态：等待。此外，一些文档告诉您应该为每个 wait() 调用 notification() ，如果您不这样做，那么即使监视器已解锁， wait() 线程也将永远没有资格执行。
I've read many docs about thread states, some of them tells that there is two different states: blocked (before synchronized) and wait (if calls wait), some others are telling that there is only one state: wait. Moreover, some docs telling that you should call notify() for every wait() and if you don't then threads waiting() will never be eligible for execution even if monitor is unlocked.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从你的最后一句话中我发现你没有完全理解
synchronized和wait()/notify()之间的区别。基本上，监视器有锁定和条件。这几乎是正交的概念。
当线程进入
synchronized块时，它会获取锁。当线程离开该块时，它会释放锁。只有一个线程可以拥有特定监视器上的锁。当拥有锁的线程调用
wait()时，它会释放锁并开始等待其条件。当拥有锁的线程调用notify()时，等待条件的线程之一（在notifyAll()情况下为所有线程）将有资格执行（并开始等待获取锁，因为通知线程仍然拥有锁）。因此，等待获取锁 (Thread.State.BLOCKED) 和等待监视器的条件 (Thread.State.WAITING) 是不同且独立的状态。
如果您查看 ，这种行为会变得更加清晰
Lock类 - 它实现与synchronized块相同的同步原语（带有一些扩展），但提供了锁和条件之间的明确区别。From you last sentence I see you don't fully understand the difference between
synchronizedandwait()/notify().Basically, monitor has lock and condition. It's almost orthogonal concepts.
When thread enters a
synchronizedblock, it acquires a lock. When thread leaves that block, it releases a lock. Only one thread can have a lock on a particular monitor.When thread having a lock calls
wait(), it releases a lock and starts waiting on its condition. When thread having a lock callsnotify(), one of the threads (all threads in the case ofnotifyAll()) waiting on the condition becomes eligible for execution (and starts waiting to acquire a lock, since notifying thread still has it).So, waiting to acquire a lock (Thread.State.BLOCKED) and waiting on the monitor's condition (Thread.State.WAITING) are different and independent states.
This behaviour becames more clear if you look at
Lockclass - it implements the same synchronization primitives assynchronizedblock (with some extensions), but provides clear distinction between locks and conditions.有两种不同的状态 BLOCKED 和等待。
如果没有人通知（或打断）您，则永远等待的部分是正确的。
There are two different states BLOCKED and WAITING.
The part about waiting forever if no one notifies (or interrupts) you is true.
标准文档在这里
Standard doc is here
从Java的角度来看（Thread.State ），有两种不同的状态： BLOCKED 和 WAITING 。当线程在对象上同步时，它处于 BLOCKED 状态。线程执行wait后，就处于WAITING状态。
在Linux平台上，Java线程是操作系统本机线程。 BLOCKED 和 WAITING 状态的操作系统线程状态都是可中断睡眠。当使用 ps 检查时，BLOCKED 和 WAITING 线程的状态都是“Sl+”。
In Java's perspective (Thread.State), there are two different states: BLOCKED and WAITING . When a thread synchronizes on a Object, it is in BLOCKED state. After a thread executes wait, it is in WAITING state.
On Linux platform, Java thread is OS native thread. The OS thread state for both BLOCKED and WAITING states is Interruptible sleep. When being checked with ps, the state for both BLOCKED and WAITING threads is "Sl+".