線程

Thread

第一類就是Thread類。大家都知道有兩種實現方式。第一可以繼承Thread覆蓋它的run方法;第二種是實現Runnable接口，實現它的run方法;而第三種創建線程的方法，就是通過線程池。

我們的具體代碼實現，就放在run方法中。

我們關注兩種情況。一個是線程退出條件，一個是異常處理情況。

線程退出

有的run方法執行完成后，線程就會退出。但有的run方法是永遠不會結束的。結束一個線程肯定不是通過Thread.stop()方法，這個方法已經在java1.2版本就廢棄了。所以我們大體有兩種方式控制線程。

定義退出標志放在while中

代碼一般長這樣。

private volatile boolean flag= true;
public void run() {
 while (flag) {
 }
}

標志一般使用volatile進行修飾，使其讀可見，然后通過設置這個值來控制線程的運行，這已經成了約定俗成的套路。

使用interrupt方法終止線程

類似這種。

while（！isInterrupted（））{……}

對于InterruptedException，比如Thread.sleep所拋出的，我們一般是補獲它，然后靜悄悄的忽略。中斷允許一個可取消任務來清理正在進行的工作，然后通知其他任務它要被取消，最后才終止，在這種情況下，此類異常需要被仔細處理。

interrupt方法不一定會真正”中斷”線程，它只是一種協作機制。interrupt方法通常不能中斷一些處于阻塞狀態的I/O操作。比如寫文件，或者socket傳輸等。這種情況，需要同時調用正在阻塞操作的close方法，才能夠正常退出。

interrupt系列使用時候一定要注意，會引入bug，甚至死鎖。

異常處理

java中會拋出兩種異常。一種是必須要捕獲的，比如InterruptedException，否則無法通過編譯;另外一種是可以處理也可以不處理的，比如NullPointerException等。

在我們的任務運行中，很有可能拋出這兩種異常。對于第一種異常，是必須放在try,catch中的。但第二種異常如果不去處理的話，會影響任務的正常運行。

有很多同學在處理循環的任務時，沒有捕獲一些隱式的異常，造成任務在遇到異常的情況下，并不能繼續執行下去。如果不能確定異常的種類，可以直接捕獲Exception或者更通用的Throwable。

while（！isInterrupted（））{
 try{
 ……
 }catch(Exception ex){
 ……
 }
}

同步方式

java中實現同步的方式有很多，大體分為以下幾種。

synchronized 關鍵字

wait、notify等

Concurrent包中的ReentrantLock

volatile關鍵字

ThreadLocal局部變量

生產者、消費者是wait、notify最典型的應用場景，這些函數的調用，是必須要放在synchronized代碼塊里才能夠正常運行的。它們同信號量一樣，大多數情況下屬于炫技，對代碼的可讀性影響較大，不推薦。關于ObjectMonitor相關的幾個函數，只要搞懂下面的圖，就基本ok了。

使用ReentrantLock最容易發生錯誤的就是忘記在finally代碼塊里關閉鎖。大多數同步場景下，使用Lock就足夠了，而且它還有讀寫鎖的概念進行粒度上的控制。我們一般都使用非公平鎖，讓任務自由競爭。非公平鎖性能高于公平鎖性能，非公平鎖能更充分的利用cpu的時間片，盡量的減少cpu空閑的狀態時間。非公平鎖還會造成餓死現象：有些任務一直獲取不到鎖。

synchronized通過鎖升級機制，速度不見得就比lock慢。而且，通過jstack，能夠方便的看到其堆棧，使用還是比較廣泛。

volatile總是能保證變量的讀可見，但它的目標是基本類型和它鎖的基本對象。假如是它修飾的是集合類，比如Map，那么它保證的讀可見是map的引用，而不是map對象，這點一定要注意。

synchronized和volatile都體現在字節碼上(monitorenter、monitorexit)，主要是加入了內存屏障。而Lock，是純粹的java api。

ThreadLocal很方便，每個線程一份數據，也很安全，但要注意內存泄露。假如線程存活時間長，我們要保證每次使用完ThreadLocal，都調用它的remove()方法(具體來說是expungeStaleEntry)，來清除數據。

關于Concurrent包

concurrent包是在AQS的基礎上搭建起來的，AQS提供了一種實現阻塞鎖和一系列依賴FIFO等待隊列的同步器的框架。

線程池

最全的線程池大概有7個參數，想要合理使用線程池，肯定不會不會放過這些參數的優化。

線程池參數

concurrent包最常用的就是線程池，平常工作建議直接使用線程池，Thread類就可以降低優先級了。我們常用的主要有newSingleThreadExecutor、newFixedThreadPool、newCachedThreadPool、調度等，使用Executors工廠類創建。

監控

高并發下的線程池，最好能夠監控起來。可以使用日志、存儲等方式保存下來，對后續的問題排查幫助很大。

通常，可以通過繼承ThreadPoolExecutor，覆蓋beforeExecute、afterExecute、terminated方法，達到對線程行為的控制和監控。

線程池飽和策略

最容易被遺忘的可能就是線程的飽和策略了。也就是線程和緩沖隊列的空間全部用完了，新加入的任務將如何處置。jdk默認實現了4種策略，默認實現的是AbortPolicy，也就是直接拋出異常。下面介紹其他幾種。

DiscardPolicy 比abort更加激進，直接丟掉任務，連異常信息都沒有。

CallerRunsPolicy 由調用的線程來處理這個任務。比如一個web應用中，線程池資源占滿后，新進的任務將會在tomcat線程中運行。這種方式能夠延緩部分任務的執行壓力，但在更多情況下，會直接阻塞主線程的運行。

DiscardOldestPolicy 丟棄隊列最前面的任務，然后重新嘗試執行任務(重復此過程)。

很多情況下，這些飽和策略可能并不能滿足你的需求，你可以自定義自己的策略，比如將任務持久化到一些存儲中。

阻塞隊列

阻塞隊列會對當前的線程進行阻塞。當隊列中有元素后，被阻塞的線程會自動被喚醒，這極大的提高的編碼的靈活性，非常方便。在并發編程中，一般推薦使用阻塞隊列，這樣實現可以盡量地避免程序出現意外的錯誤。阻塞隊列使用最經典的場景就是socket數據的讀取、解析，讀數據的線程不斷將數據放入隊列，解析線程不斷從隊列取數據進行處理。

ArrayBlockingQueue對訪問者的調用默認是不公平的，我們可以通過設置構造方法參數將其改成公平阻塞隊列。

信號量

Semaphore雖然有一些應用場景，但大部分屬于炫技，在編碼中應該盡量少用。

信號量可以實現限流的功能，但它只是常用限流方式的一種。其他兩種是漏桶算法、令牌桶算法。

hystrix的熔斷功能，也有使用信號量進行資源的控制。

Lock && Condition

在Java中，對于Lock和Condition可以理解為對傳統的synchronized和wait/notify機制的替代。concurrent包中的許多阻塞隊列，就是使用Condition實現的。

但這些類和函數對于初中級碼農來說，難以理解，容易產生bug，應該在業務代碼中嚴格禁止。但在網絡編程、或者一些框架類工程中，這些功能是必須的，萬不可將這部分的工作隨便分配給某個小弟。

End

不管是wait、notify，還是同步關鍵字或者鎖，能不用就不用，因為它們會引發程序的復雜性。最好的方式，是直接使用concurrent包所提供的機制，來規避一些編碼方面的問題。

concurrent包中的CAS概念，在一定程度上算是無鎖的一種實現。更專業的有類似disruptor的無鎖隊列框架，但它依然是建立在CAS的編程模型上的。近些年，類似AKKA這樣的事件驅動模型正在走紅，但編程模型簡單，不代表實現簡單，背后的工作依然需要多線程去協調。

以上就是動力節點小編介紹的"Java中多線程的使用場景及注意事項"，希望對大家有幫助，如有疑問，請在線咨詢，有專業老師隨時為您服務。