看到《Java Threads》第5章，介紹了JDK 1.5新加的一些所謂原子類(Atomic Classes)，總感覺有點為原子而原子，實際操作中，又有多少人會為了少許的性能提升而刻意去用這些別扭的操作而放棄直觀的synchronize關鍵字或者Lock類呢？不過，這里不是想討論這個，而是當其用Atomic Classes來改造它的打字程序后，解釋用原子類只是保證類似遞增、遞減、賦值等操作的原子性，而不能保證其所在的方法一定是線程安全的，然后說，有可能按鍵事件的處理可能需要等待resetScore()處理完才能執(zhí)行，而這會導致錯誤的評分（被當成多敲了鍵）。由于前幾章的內容相對比較簡單易懂，所以也沒有很仔細的運行那些例子。這里為了驗證一下，就運行了一下第4章的例子，然后發(fā)現，基本上第一次的評分總是錯的。這就引起了我的注意，因為，一般情況下，如果是race condition導致的錯誤是很難重現的，這么明顯的錯誤很可能是程序邏輯上的錯誤。仔細看了一下代碼，發(fā)現在start按鈕的事件處理方法里，有下面這樣一段代碼：
startButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent evt) {
displayCanvas.setDone(false);
producer.setDone(false);
startButton.setEnabled(false);
stopButton.setEnabled(true);
feedbackCanvas.setEnabled(true);
feedbackCanvas.requestFocus();
score.resetScore();
}
});
注意重置成績的調用放在了最后，此時，隨機生成字符的線程應該被喚醒并產生了第一個字符，然后，resetScore()將需要輸入的字符又設成了-1，所以，當你第一次輸入字符時，總是被認為是多擊了一次鍵而扣1分:(。既然這樣，那停止然后再啟動也應該會發(fā)生這個錯誤啊。而事實上的確是這樣。我想，這不應該看做是race condition吧，有什么樣的同步技術能夠避免這個問題呢？除非另外弄個標志，當成績沒有被重置前，不能產生第一個字符。當然，這是不需要的，只要將score.resetScore()放到第一句就可以了。
然后又運行了第3章的例子，發(fā)現基本上沒有這個問題。難道第3章的代碼是正確的？打開源代碼一看，重置成績的方法還是放在最后，那這里為什么又是正確的呢？我想，大約是第3章的例子中，每次點擊start按鈕，都重新創(chuàng)建一個線程對象的原因吧。由于創(chuàng)建對象和初始化線程需要一定的時間，剛好給了主線程重置成績的機會。
不知道作者有意為之呢，還是疏忽，不過，這樣的錯誤不能算是race condition的例子。