線程啟動完畢后，在運行時可能需要終止，Java提供的終止方法只有一個stop，但是我不建議使用這個方法，因為它有以下三個問題：（1）stop方法是過時的從Java編碼規則來說，已經過時的方法不建議采用。（2）stop方法會導致代碼邏輯不完整stop方法是一種“惡意”的中斷，一旦執行stop方法，即終止當前正在運行的線程，不管線程邏輯是否完整，這是非常危險的。看如下的代碼：

這段代碼的邏輯是這樣的：子線程是一個匿名內部類，它的run方法在執行時會休眠1秒鐘，然后再執行后續的邏輯，而主線程則是休眠0.1秒后終止子線程的運行，也就是說，JVM在執行thread.stop()時，子線程還在執行sleep(1000)，此時stop方法會清除棧內信息，結束該線程，這也就導致了run方法的邏輯不完整，輸出語句println代表的是一段邏輯，可能非常重要，比如子線程的主邏輯、資源回收、情景初始化等，但是因為stop線程了，這些就都不再執行，于是就產生了業務邏輯不完整的情況。這是極度危險的，因為我們不知道子線程會在什么時候被終止，stop連基本的邏輯完整性都無法保證。而且此種操作也是非常隱蔽的，子線程執行到何處會被關閉很難定位，這為以后的維護帶來了很多麻煩。（3）stop方法會破壞原子邏輯多線程為了解決共享資源搶占的問題，使用了鎖概念，避免資源不同步，但是正因此原因，stop方法卻會帶來更大的麻煩：它會丟棄所有的鎖，導致原子邏輯受損。例如有這樣一段程序：

MultiThread實現了Runnable接口，具備多線程能力，其中run方法中加上了synchronized代碼塊，表示內部是原子邏輯，它會先自增然后再自減少，按照synchronized同步代碼塊的規則來處理，此時無論啟動多少個線程，打印出來的結果都應該是a=0，但是如果有一個正在執行的線程被stop，就會破壞這種原子邏輯，代碼如下：

首先要說明的是所有線程共享了一個MultiThread的實例變量t，其次由于在run方法中加入了同步代碼塊，所以只能有一個線程進入到synchronized塊中。此段代碼的執行順序如下：1）線程t1啟動，并執行run方法，由于沒有其他線程持同步代碼塊的鎖，所以t1線程執行自加后執行到sleep方法即開始休眠，此時a=1。2）JVM又啟動了5個線程，也同時運行run方法，由于synchronized關鍵字的阻塞作用，這5個線程不能執行自增和自減操作，等待t1線程鎖釋放。3）主線程執行了t1.stop方法，終止了t1線程，注意，由于a變量是所有線程共享的，所以其他5個線程獲得的a變量也是1。4）其他5個線程依次獲得CPU執行機會，打印出a值。分析了這么多，相信讀者也明白了輸出的結果，結果如下：

原本期望synchronized同步代碼塊中的邏輯都是原子邏輯，不受外界線程的干擾，但是結果卻出現原子邏輯被破壞的情況，這也是stop方法被廢棄的一個重要原因：破壞了原子邏輯。既然終止一個線程不能使用stop方法，那怎樣才能終止一個正在運行的線程呢？答案也很簡單，使用自定義的標志位決定線程的執行情況，代碼如下：

這是很簡單的辦法，在線程體中判斷是否需要停止運行，即可保證線程體的邏輯完整性，而且也不會破壞原子邏輯。可能有讀者對Java API比較熟悉，于是提出疑問：Thread不是還提供了interrupt中斷線程的方法嗎？這個方法可不是過時方法，那可以使用嗎？它可以終止一個線程嗎？非常好的問題，interrupt，名字看上去很像是終止一個線程的方法，但是我可以很明確地告訴你，它不是，它不能終止一個正在執行著的線程，它只是修改中斷標志而已，例如下面一段代碼：

執行這段代碼，你會發現一直有Running在輸出，永遠不會停止，似乎執行了interrupt沒有任何變化，那是因為interrupt方法不能終止一個線程狀態，它只會改變中斷標志位（如果在t1.interrupt()前后輸出t1.isInterrupted()則會發現分別輸出了false和true），如果需要終止該線程，還需要自行進行判斷，例如我們可以使用interrupt編寫出更加簡潔、安全的終止線程代碼

總之，如果期望終止一個正在運行的線程，則不能使用已經過時的stop方法，需要自行編碼實現，如此即可保證原子邏輯不被破壞，代碼邏輯不會出現異常。當然，如果我們使用的是線程池（比如ThreadPoolExecutor類），那么可以通過shutdown方法逐步關閉池中的線程，它采用的是比較溫和、安全的關閉線程方法，完全不會產生類似stop方法的弊端。