;
◆ ThreadA和ThreadB死锁。
必须指出的是,在代码丝毫不做变动的情况下,有些时候上述死锁过程不会出现,VM调度
程序可能让其中一个线程同时获得lock_1和lock_2两个锁,即线程获取两个锁的过程没有被中断。在这种情形下,常规的死锁检测很难确定错误所在。
占有并等待
如果一个线程获得了一个锁之后还要等待来自另一个线程的通知,可能出现另一种隐性死锁,考虑代码二。
//代码二
public class queue {
static java.lang.Object queueLock_;
Producer producer_;
Consumer consumer_;
public class Producer {
void produce() {
while (!done) {
“synchronized” (queueLock_) {
produceItemAndAddItToQueue();
“synchronized” (consumer_) {
consumer_.notify();
}
}
}
}
public class Consumer {
consume() {
while (!done) {
“synchronized” (queueLock_) {
“synchronized” (consumer_) {
consumer_.wait();
}
removeItemFromQueueAndProcessIt();
}
}
}
}
}
}
在代码二中,Producer向队列加入一项新的内容后通知Consumer,以便它处理新的内容。问题在于,Consumer可能保持加在队列上的锁,阻止Producer访问队列,甚至在Consumer等待Producer的通知时也会继续保持锁。这样,由于Producer不能向队列添加新的内容,而Consumer却在等待Producer加入新内容的通知,结果就导致了死锁。
在等待时占有的锁是一种隐性的死锁,这是因为事情可能按照比较理想的情况发展—Producer线程不需要被Consumer占据的锁。尽管如此,除非有绝对可靠的理由肯定Producer线程永远不需要该锁,否则这种编程方式仍是不安全的。有时“占有并等待”还可能引发一连串的线程等待,例如,线程A占有线程B需要的锁并等待,而线程B又占有线程C需要的锁并等待等。
要改正代码二的错误,只需修改Consumer类,把wait()移出“synchronized”()即可。
数据竞争
数据竞争是由于访问共享资源(例如变量)时缺乏或不适当地运用同步机制引起。如果没有正确地限定某一时刻某一个线程可以访问变量,就会出现数据竞争,此时赢得竞争的线程获得访问许可,但会导致不可预知的结果。
由于线程的运行可以在任何时候被中断(即运行机会被其它线程抢占),所以不能假定先开始运行的线程总是比后开始运行的线程先访问到两者共享的数据。另外,在不同的VM上,线程的调度方式也可能不同,从而使数据竞争问题更加复杂。
有时,数据竞争不会影响程序的最终运行结果,但在另一些时候,有可能导致不可预料的结果。
良性数据竞争
并非所有的数据竞争都是错误。考虑代码三的例子。假设getHouse()向所有的线程返回同一House,可以看出,这里会出现竞争:BrickLayer从House.foundationReady_读取,而FoundationPourer写入到House.foundationReady_。
//代码三
public class House {
public volatile boolean foundationReady_ = false;
}
public class FoundationPourer extends Thread {
public void run() {
House a = getHouse();
a.