在 Java 中, 最好的停止線程的方式是使用中斷 interrupt, 但是這僅僅是會通知到被終止的線程 "你該停止運行了", 被終止的線程自身擁有決定權 (決定是否、以及何時停止), 這依賴于請求停止方和被停止方都遵守一種約定好的編碼規范.
- 任務和線程的啟動很容易. 在大多數時候, 我們都會讓它們運行直到結束, 或者讓它們自行停止.然而, 有時候我們希望提前結束任務或線程, 或許是因為用戶取消了操作,或者服務需要被快速關閉, 或者是運行超時或出錯了.
- 要使任務和線程能安全、快速、可靠地停止下來, 并不是一件容易的事. Java沒有提供任何機制來安全地終止線程. 但它提供了中斷 (Interruption), 這是一種協作機制,能夠使一個線程終止另一個線程的當前工作.
- 這種協作式的方法是必要的, 我們很少希望某個任務、線程或服務立即停止,因為這種立即停止會使共享的數據結構處于不一致的狀態. 相反, 在編寫任務和服務時可以使用一種協作的方式: 當需要停止時,它們首先會清除當前正在執行的工作, 然后再結束. 這提供了更好的靈活性, 因為任務本身的代碼比發出取消請求的代碼更清楚如何執行清除工作.
- 生命周期結束 (End-of-Lifecycle) 的問題會使任務、服務以及程序的設計和實現等過程變得復雜, 而這個在程序設計中非常重要的要素卻經常被忽略. 一個在行為良好的軟件與勉強運的軟件之間的最主要區別就是, 行為良好的軟件能很完善地處理失敗、關閉和取消等過程.
處理中斷的最好方法是什么?
優先選擇在方法上拋出異常.
用 throws InterruptedException 標記你的方法, 不采用 try 語句塊捕獲異常,以便于該異常可以傳遞到頂層, 讓run方法可以捕獲這一異常, 例如:
1
2
3
|
void subTask() throws InterruptedException sleep(delay); } |
由于 run 方法內無法拋出 checked Exception (只能用 try catch), 頂層方法必須處理該異常, 避免了漏掉或者被吞掉的情況, 增強了代碼的健壯性.
如果不能拋出中斷, 要怎么做?
如果不想或無法傳遞 InterruptedException (例如用 run 方法的時候, 就不讓該方法 throws InterruptedException), 那么應該選擇在 catch 子句中調用 Thread.currentThread().interrupt() 來恢復設置中斷狀態, 以便于在后續的執行依然能夠檢查到剛才發生了中斷.
代碼演示詳見視頻, 在這里, 線程在sleep期間被中斷, 并且由 catch 捕獲到該中斷, 并重新設置了中斷狀態, 以便于可以在下一個循環的時候檢測到中斷狀態, 正常退出.
為什么用 volatile 停止線程不夠全面?
解答: 這種做法是錯誤的, 或者說是不夠全面的, 在某些情況下雖然可用, 但是某些情況下有嚴重問題。
這種方法在《Java并發編程實戰》中被明確指出了缺陷, 我們一起來看看缺陷在哪里:
此方法錯誤的原因在于, 如果我們遇到了線程長時間阻塞 (這是一種很常見的情況, 例如生產者消費者模式中就存在這樣的情況), 就沒辦法及時喚醒它, 或者永遠都無法喚醒該線程, 而 interrupt 設計之初就是把 wait 等長期阻塞作為一種特殊情況考慮在內了, 我們應該用 interrupt 思維來停止線程.
以上就是Java 停止線程需要注意的地方的詳細內容,更多關于Java 停止線程的資料請關注服務器之家其它相關文章!
原文鏈接:https://segmentfault.com/a/1190000024429547?utm_source=tuicool&utm_medium=referral