使用Timer和TimerTask時的Java線程執行順序

Question

我將Timer用作進程中斷機制。 邏輯流程如下：

T0：在T0創建新計時器，並安排新的計時器任務在T2執行（任務延遲1秒，任務非常簡單-設置標志變量）

T1：在主調用線程中，睡眠5秒鍾

T2：在計時器線程中，任務執行

T5：睡眠結束

T6：取消計時器和任何計划的任務

該代碼可以在我的Windows和Ubuntu開發環境中完美運行。 但是，當我在SLES 10構建服務器上運行相同的代碼時，日志記錄表明此執行順序：

T0：創建計時器和計時器任務以在T2執行

T1：主線程休眠5秒

T5：主線程喚醒

T6：計時器取消

T7：任務執行

誰能解釋為什么會這樣？ 非常感謝。

Answer 1

嗯 我很驚訝您看到這么多差異（以秒為單位？），但是我猜您可能會看到從機器到機器，從jvm到jvm等不同的執行順序。尤其是當JIT為第一次，我傾向於在我的代碼中看到大約100-300ms的延遲（與隨后執行相同的代碼相比），所以也許在您的代碼中它更引人注目？

不知道您所說的“進程中斷機制”是什么。 您是說定時器任務中斷了某個線程嗎？

無論如何，我現在建議使用System.nanoTime()代替。 （盡管我認為它不會解釋任何問題，但建議不要在嚴重的測量中使用System.currentTimeMillis() ）。 通常建議將-server到JAVA_OPTS中，以便您在通過JIT優化代碼時看到行為。 強烈建議您多次運行代碼並進行統計。

如果您是我，我將首先做這些小事情，然后使用CyclicBarrier ， CountdownLatch類的同步器進行調試，並查看延遲的確切位置。

SLES中的“背景噪音”（活動度）是多少？ 操作系統可能很忙還是什么？

任務的性質是什么？ 網絡/ IO相關嗎？

Answer 2

原來這是一個時間戳問題。 使用新的Date（）。getTime而不是System.currentTimeMillis產生了預期的執行時間戳順序。

感謝所有的好主意。

Answer 3

您應該考慮在任務完成時觸發事件。 這樣可以確保執行順序。