为什么也notify
需要锁?
想象一下这种情况:
synchronized(x){ while(x.count < 4) { x.wait(); //... }}
现在想象一下
notify其他地方没有任何锁定:
//...println(x.count); // print 3x.count++;if(count == 4) x.notify()//...
乍一看,整个声音总能按预期工作。
但是,请考虑以下竞争条件:
//Thread1 enters heresynchronized(x){ while(x.count < 4) { //condition is judged true and thread1 is about to wait //..but..ohh!! Thread2 is prioritized just now ! //Thread2, acting on notify block side, notices that with its current count incrementation, //count increases to 4 and therefore a notify is sent.... //but...but x is expected to wait now !!! for nothing maybe indefinitely ! x.wait(); //maybe block here indefinitely waiting for a notify that already occurred! }}
如果只有我们有办法告诉这一点
notify:
主题1:“嗯
notify,你很可爱,但我刚刚开始将我的条件(
x.count <4)评估为true,所以请…不要傻傻地立即发送您的预期通知(在我将状态设置为等待),否则,我会等待已经过去的事情荒谬”
线程2:“好吧…为了保持一致,我将在逻辑周围加一个锁,以便 在 您的等待调用释放我们的共享锁 之后
发送通知,这样您将收到此通知,从而可以退出等待状态 ;)”
因此,
notify为了避免这种情况,请始终在旁边等待的同一对象上放置锁,以使关系始终保持一致。
= >导致a notify
的逻辑和导致a 的逻辑wait
不应重叠。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)