如何理解Java线程中的wait和notify方法？
我对这两个描述感到非常困惑：
- “wait 方法阻塞调用线程并放弃监视器锁”
- “notify 方法解锁一个等待线程但不放弃监视器锁”
这是我的问题：
我知道Java中的每个对象都有一个锁，但是“监视器锁”是什么意思？它和对象的锁一样吗？
为什么notify方法需要放弃monitor锁？
如果我尝试使用以下代码让对象等待：
类 simpleTask 扩展了 Thread { int 等待时间； 公共 simpleTask(int waitingTime) { this.waitingTime = waitingTime; } 公共无效运行（） { synchronized(this) // this是当前对象的引用 { 尝试 { this.wait(等待时间); } catch (InterruptedException e) { // TODO 自动生成的 catch 块 e.printStackTrace(); } } }
像上面第一个描述一样，这是否意味着当前对象被synchronized关键字阻塞，然后wait方法释放锁？
I'm very confusing about these two descriptions:
- "The wait method blocks the calling thread and gives up the monitor lock"
- "The notify method unblocks one waiting thread but does not give up the monitor lock"
Here is my questions:
I know each object in Java has a lock, but what is the "monitor lock" means? is it the same as the oject's lock?
Why notify method needs to give up the monitor lock?
If I try to make a object waiting with the following code:
class simpleTask extends Thread { int waitingTime; public simpleTask(int waitingTime) { this.waitingTime = waitingTime; } public void run() { synchronized(this) // this is a reference of current object { try { this.wait(waitingTime); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } }
Like the first description above, is that means the the current object is blocked by synchronized keyword, and then wait method releases the lock?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，它们是同一件事。它们有时也被称为对象的“互斥体”和对象的“原始锁”。 （但是当有人谈论
Lock时，他们正在谈论这个 Java 接口 ...这是一个不同的锁定机制。）notify方法不会放弃锁定。在notify调用返回后，您的代码有责任放弃锁（即离开同步块或从同步方法返回）。为什么有必要？因为当前正在等待该锁的任何其他线程（在
wait(...)调用中）必须在wait调用完成之前重新获取该锁。他们为什么要这样设计
notify/wait？这样它们就可以用来实现条件变量。这是正确的。当线程调用
someObject.wait()时，它对someObject的锁定会被释放……然后在wait()< 之前重新获取（由同一线程） /code> 调用返回。当然，与此同时，someObject可能已被其他线程多次获取和释放。重点是，当wait返回时，调用wait的线程将拥有锁。Yes, they are the same thing. They are also occasionally called the object's "mutex" and the object's "primitive lock". (But when someone talks about
Lock, they are talking about this Java interface ... which is a different locking mechanism.)The
notifymethod doesn't give up the lock. It is your code's responsibility to give up the lock (i.e. leave the synchronized block or return from the synchronized method) after thenotifycall returns.Why is that necessary? Because any other thread that is currently waiting on that lock (in a
wait(...)call) has to reacquire that lock before thewaitcall can complete.Why did they design
notify/waitlike this? So that they can be used to implement condition variables.That is correct. When a thread calls
someObject.wait()its lock onsomeObjectis released ... and then reacquired (by the same thread) before thewait()call returns. Of course, in the meantime the locksomeObjectmay have been acquired and released multiple times by other threads. The point is that whenwaitreturns, the thread that calledwaitwill have the lock.是的，监视器锁和对象锁是一样的。如果您执行
synchronized (object)，那就是锁。在您的示例中，当前对象将在等待时放弃锁定，
wait()调用放弃锁定。 ，调用notify()来唤醒对象，当wait()调用返回时，它将再次持有锁。Yes, the monitor lock is the same as the object's lock. If you do
synchronized (object), that's the lock.In your example, the current object will give up the lock while waiting, the
wait()call gives up the lock. In another thread,notify()is called to wake the object up, and when thewait()call returns it will hold the lock again.监视器是一种同步构造。
等待放弃锁的原因以便其他线程可以获取锁，例如其他可能想要等待的线程。另外：唤醒其他线程的线程通常会在释放任何线程之前锁定，以防止竞争条件。
有关此内容的更多信息，您应该研究条件变量（即 condvars）。
A monitor is a type of synchronization construct.
The reason that waiting gives up the lock is so that other threads can acquire the lock, such as other threads that might want to wait. Also: It's usual for the thread that's awakening other threads to lock before releasing any threads, to prevent a race condition.
For more about this, you should study condition variables (i.e. condvars).