多線程編程學習總結

線程的概念和原理

爲何使用多線程？

爲了更高效的完成任務和利用CPU資源，如今的操做系統設計爲多任務操做系統，而多進程和多線程是實現多任務的方式。

什麼是進程和線程？

進程是指一個內存中運行的應用程序，每一個進程都有本身獨立的一塊內存空間，一個進程中能夠啓動多個線程。進程是OS分配資源的最小單位。 線程是指進程中的一個執行流程，一個進程中能夠運行多個線程。線程老是屬於某個進程，進程中的多個線程共享進程的內存。進程是OS調度的最小單位。

工做原理？

1. 多線程是這樣一種機制，它容許在程序中併發執行多個指令流，每一個指令流都稱爲一個線程，彼此間互相獨立。線程又稱爲輕量級進程，它和進程同樣擁有獨立的執行控制，由操做系統負責調度，區別在於線程沒有獨立的存儲空間，而是和所屬進程中的其它線程共享一個存儲空間，這使得線程間的通訊遠較進程簡單。

2. 具體到java內存模型，因爲Java被設計爲跨平臺的語言，在內存管理上，顯然也要有一個統一的模型。系統存在一個主內存(Main Memory)， Java中全部變量都儲存在主存中，對於全部線程都是共享的。每條線程都有本身的工做內存(Working Memory)——調用棧，工做內存中保存的是主存中某些變量的拷貝，線程對全部變量的操做都是在工做內存中進行，線程之間沒法相互直接訪問，變量傳遞均須要經過主存完成。

3. 多個線程的執行是併發的，也就是在邏輯上「同時」，而無論是不是物理上的「同時」。若是系統只有一個CPU，那麼真正的「同時」是不可能的。多線程和傳統的單線程在程序設計上最大的區別在於，因爲各個線程的控制流彼此獨立，使得各個線程之間的代碼是亂序執行的，將會帶來線程調度，同步等問題。

 

線程狀態轉換

線程的狀態轉換是線程控制的基礎。線程狀態總的可分爲五大狀態：分別是新建、就緒、運行、等待/阻塞、死亡。用一個圖來描述以下： 

一、新建狀態：線程對象已經建立，尚未在其上調用start()方法。

二、就緒狀態：當線程有資格運行，但調度程序尚未把它選定爲運行線程時線程所處的狀態。當start()方法調用時，線程首先進入可運行狀態。在線程運行以後或者從阻塞、等待或睡眠狀態回來後，也返回到就緒狀態。

三、運行狀態：線程調度程序從就緒線程池中選擇一個線程做爲當前線程時線程所處的狀態。這也是線程進入運行狀態的惟一一種方式。

四、等待/阻塞/睡眠狀態：線程不會被分配 CPU 時間，沒法執行；可能阻塞於I/O，或者阻塞於同步鎖。實際上這個三狀態組合爲一種，其共同點是：線程仍舊是活的，可是當前沒有條件運行。換句話說，它是可運行的，可是若是某件事件出現，他可能返回到可運行狀態。

五、死亡態：當線程的run()方法完成時就認爲它死去，調用 stop()或 destroy() 亦有一樣效果，可是不被推薦，前者會產生異常，後者是強制終止，不會釋放鎖。這個線程對象也許是活的，可是，它已經不是一個單獨執行的線程。線程一旦死亡，就不能復生。 若是在一個死去的線程上調用start()方法，會拋出java.lang.IllegalThreadStateException異常。

 

鎖機制

線程鎖機制的本質是解決線程通訊中的互斥問題。 因爲咱們能夠經過 private 關鍵字來保證數據對象只能被方法訪問，因此咱們只需針對方法提出一套機制，這套機制就是 synchronized 關鍵字，它包括兩種用法：synchronized 方法和 synchronized 塊。注意：每一個類實例對應一把鎖，同步和互斥等都是相對多線程而言的。

synchronized 方法

經過在方法聲明中加入 synchronized關鍵字來聲明 synchronized 方法，語法以下：

public synchronized void procData();

synchronized 方法原理：多個線程訪問同一個 synchronized 方法時，必須得到調用該方法的類實例的鎖才能執行，不然所屬線程阻塞，方法一旦執行，就獨佔該鎖，直到從該方法返回時纔將鎖釋放，此後被阻塞的線程方能得到該鎖，從新進入可執行狀態。這種機制確保了同一時刻對於每個類實例，其全部聲明爲 synchronized 的成員函數中至多隻有一個處於可執行狀態（由於至多隻有一個可以得到該類實例對應的鎖），從而有效避免了類成員變量的訪問衝突（只要全部可能訪問類成員變量的方法均被聲明爲 synchronized）。

在 Java 中，不光是類實例，每個類也對應一把鎖，這樣咱們也可將類的靜態成員函數聲明爲 synchronized ，以控制其對類的靜態成員變量的訪問。

synchronized 方法的缺陷：若將一個大的方法聲明爲synchronized 將會大大影響效率，典型地，若將線程類的方法 run() 聲明爲 synchronized ，因爲在線程的整個生命期內它一直在運行，所以將致使它對本類任何 synchronized 方法的調用都永遠不會成功。固然咱們能夠經過將訪問類成員變量的代碼放到專門的方法中，將其聲明爲 synchronized ，並在主方法中調用來解決這一問題，可是 Java 爲咱們提供了更好的解決辦法，那就是 synchronized 塊。

synchronized 塊

經過 synchronized關鍵字來聲明synchronized 塊，語法以下：

(syncObject) {
    }

synchronized 塊是這樣一個代碼塊，其中的代碼必須得到對象 syncObject （如前所述，能夠是類實例或類）的鎖方能執行，具體機制同前所述。因爲能夠針對任意代碼塊，且可任意指定上鎖的對象，故靈活性較高。  

阻塞機制

阻塞機制的本質是爲了解決線程通訊的同步問題。鎖和阻塞機制解決線程通訊中的互斥和同步問題。

爲了解決對共享存儲區的訪問衝突，引入了鎖機制，考察多個線程對共享資源的訪問，顯然鎖機制已經不夠了，由於在任意時刻所要求的資源不必定已經準備好了被訪問，反過來，同一時刻準備好了的資源也可能不止一個。爲了解決這種狀況下的訪問控制問題，引入了對阻塞機制的支持。

阻塞指的是暫停一個線程的執行以等待某個條件發生（如某資源就緒）。Java 提供了大量方法來支持阻塞，下面讓咱們逐一分析。

1. sleep()方法：sleep()容許指定以毫秒爲單位的一段時間做爲參數，它使得線程在指定的時間內進入阻塞狀態，不能獲得CPU 時間，指定的時間一過，線程從新進入可執行狀態。典型地，sleep() 被用在等待某個資源就緒的情形：測試發現條件不知足後，讓線程阻塞一段時間後從新測試，直到條件知足爲止。

2. suspend()和resume()方法：兩個方法配套使用，suspend()使得線程進入阻塞狀態，而且不會自動恢復，必須其對應的resume() 被調用，才能使得線程從新進入可執行狀態。典型地，suspend() 和 resume() 被用在等待另外一個線程產生的結果的情形：測試發現結果尚未產生後，讓線程阻塞，另外一個線程產生告終果後，調用resume()使其恢復。

1. yield() 方法：yield() 使得線程放棄當前分得的 CPU 時間，可是不使線程阻塞，即線程仍處於可執行狀態，隨時可能再次分得 CPU 時間。調用 yield() 的效果等價於調度程序認爲該線程已執行了足夠的時間從而轉到另外一個線程。

2. wait() 和 notify() 方法：兩個方法配套使用，wait() 使得線程進入阻塞狀態，它有兩種形式，一種容許指定以毫秒爲單位的一段時間做爲參數，另外一種沒有參數，前者當對應的 notify() 被調用或者超出指定時間時線程從新進入可執行狀態，後者則必須對應的 notify() 被調用。

 

阻塞方法比較

1. 2和4區別的核心在於，前面敘述的全部方法，阻塞時都不會釋放佔用的鎖（若是佔用了的話），而這一對方法則相反。上述的核心區別致使了一系列的細節上的區別。

2. 首先，前面敘述的全部方法都隸屬於Thread 類，可是這一對卻直接隸屬於 Object 類，也就是說，全部對象都擁有這一對方法。由於這一對方法阻塞時要釋放佔用的鎖，而鎖是任何對象都具備的，調用任意對象的 wait() 方法致使線程阻塞，而且該對象上的鎖被釋放。而調用任意對象的notify()方法則致使因調用該對象的 wait() 方法而阻塞的線程中隨機選擇的一個解除阻塞（但要等到得到鎖後才真正可執行）。

3. 其次，前面敘述的全部方法均可在任何位置調用，可是這一對方法卻必須在 synchronized 方法或塊中調用，理由也很簡單，只有在synchronized 方法或塊中當前線程才佔有鎖，纔有鎖能夠釋放。一樣的道理，調用這一對方法的對象上的鎖必須爲當前線程所擁有，這樣纔有鎖能夠釋放。所以，這一對方法調用必須放置在這樣的 synchronized 方法或塊中，該方法或塊的上鎖對象就是調用這一對方法的對象。若不知足這一條件，則程序雖然仍能編譯，但在運行時會出現 IllegalMonitorStateException 異常。

 

wait() 和 notify() 方法的上述特性決定了它們常常和synchronized 方法或塊一塊兒使用，將它們和操做系統的進程間通訊機制做一個比較就會發現它們的類似性：synchronized方法或塊提供了相似於操做系統原語的功能，它們的結合用於解決各類複雜的線程間通訊問題。

 

關於 wait() 和 notify() 方法

1. 調用 notify() 方法致使解除阻塞的線程是從因調用該對象的 wait() 方法而阻塞的線程中隨機選取的，咱們沒法預料哪個線程將會被選擇，因此編程時要特別當心，避免因這種不肯定性而產生問題。

2. 除了 notify()，還有一個方法 notifyAll() 也可起到相似做用，惟一的區別在於，調用 notifyAll() 方法將把因調用該對象的wait()方法而阻塞的全部線程一次性所有解除阻塞。固然，只有得到鎖的那一個線程才能進入可執行狀態。

談到阻塞，就不能不談一談死鎖，略一分析就能發現，suspend() 方法和不指定超時期限的 wait() 方法的調用均可能產生死鎖。遺憾的是，Java 並不在語言級別上支持死鎖的避免，咱們在編程中必須當心地避免死鎖。

以上咱們對 Java 中實現線程阻塞的各類方法做了一番分析，咱們重點分析了 wait() 和 notify() 方法，由於它們的功能最強大，使用也最靈活，可是這也致使了它們的效率較低，較容易出錯。實際使用中咱們應該靈活使用各類方法，以便更好地達到咱們的目的。

 

關於join()方法

join()方法可用於讓當前線程阻塞，以等待特定線程(調用join的線程)的消亡。不容許線程對象在本身的可執行體中調用本身線程的join。  

線程優先級

線程的優先級表明該線程的重要程度，當有多個線程同時處於可執行狀態並等待得到 CPU 時間時，線程調度系統根據各個線程的優先級來決定給誰分配 CPU 時間，優先級高的線程有更大的機會得到 CPU 時間，優先級低的線程也不是沒有機會，只是機會要小一些罷了。

你能夠調用 Thread 類的方法 getPriority() 和 setPriority()來存取線程的優先級，線程的優先級界於1(MIN_PRIORITY)和10(MAX_PRIORITY)之間，缺省是5(NORM_PRIORITY)。  

守護線程與用戶線程

線程能夠分爲用戶線程(User)和守護線程(Daemon)： 守護線程是一類特殊的線程，它和普通線程的區別在於它並非應用程序的核心部分，當一個應用程序的全部非守護線程終止運行時，即便仍然有守護線程在運行，應用程序也將終止，反之，只要有一個非守護線程在運行，應用程序就不會終止。守護線程通常被用於在後臺爲其它線程提供服務。 能夠經過調用方法 isDaemon() 來判斷一個線程是不是守護線程，也能夠調用方法 setDaemon() 來將一個線程設爲守護線程。

我的對Daemon線程更直觀的理解是：不管User仍是Daemon線程，都具備可執行序列，擁有本身的工做棧，區別在於：Daemon線程會隨着其父線程結束而結束，它不屬於程序本體。另外一層意思，父線程的結束取決於其全部子User線程，而與daemon線程無關。它們之間的不一樣決定了它們用於不一樣的場景，守護線程通常爲其餘線程提供服務，如垃圾回收器。

須要注意的是setDaemon()方法必須在線程對象沒有調用start()方法以前調用，不然沒效果。  

線程組機制

1. 線程組是一個 Java 特有的概念，在 Java 中，線程組是類ThreadGroup 的對象，每一個線程都隸屬於惟一一個線程組，這個線程組在線程建立時指定並在線程的整個生命期內都不能更改。你能夠經過調用包含 ThreadGroup 類型參數的 Thread 類構造函數來指定線程屬的線程組，若沒有指定，則線程缺省地隸屬於名爲 system 的系統線程組。

2. 在 Java 中，除了預建的系統線程組外，全部線程組都必須顯式建立。在 Java 中，除系統線程組外的每一個線程組又隸屬於另外一個線程組，你能夠在建立線程組時指定其所隸屬的線程組，若沒有指定，則缺省地隸屬於系統線程組。這樣，全部線程組組成了一棵以系統線程組爲根的樹。

3. Java 容許咱們對一個線程組中的全部線程同時進行操做，好比咱們能夠經過調用線程組的相應方法來設置其中全部線程的優先級，也能夠啓動或阻塞其中的全部線程。

4. Java 的線程組機制的另外一個重要做用是線程安全。線程組機制容許咱們經過分組來區分有不一樣安全特性的線程，對不一樣組的線程進行不一樣的處理，還能夠經過線程組的分層結構來支持不對等安全措施的採用。Java 的 ThreadGroup 類提供了大量的方法來方便咱們對線程組樹中的每個線程組以及線程組中的每個線程進行操做。

 

ThreadLocal

java.lang.ThreadLocal是local variable（線程局部變量）。它爲每個使用該變量的線程都提供一個變量值的副本，使每個線程均可以獨立地改變本身的副本，而不會和其它線程的副本衝突。從線程的角度看，就好像每個線程都徹底擁有該變量。ThreadLocal本質是一個線程安全的hashMap，key爲threadName，Value爲線程內的變量。

• Synchronized用於線程間的數據共享，而ThreadLocal則用於線程間的數據隔離。

• ThreadLocal使用場合主要解決多線程中數據因併發產生不一致問題。ThreadLocal爲每一個線程的中併發訪問的數據對象提供一個副本，經過訪問副原本運行業務，這樣的結果是耗費了內存，但大大減小了線程同步所帶來性能消耗，也減小了線程併發控制的複雜度。

• ThreadLocal不能使用原子類型，只能使用Object類型。ThreadLocal的使用比synchronized要簡單得多。

• ThreadLocal和Synchonized都用於解決多線程併發訪問。可是ThreadLocal與synchronized有本質的區別。synchronized是利用鎖的機制，使變量或代碼塊在某一時該只能被一個線程訪問。而ThreadLocal爲每個線程都提供了變量的副本，使得每一個線程在某一時間訪問到的並非同一個對象，這樣就隔離了多個線程對數據的數據共享。而Synchronized卻正好相反，它用於在多個線程間通訊時可以得到數據共享。

• 固然ThreadLocal並不能替代synchronized,它們處理不一樣的問題域。Synchronized用於實現鎖機制，比ThreadLocal更加複雜。

 

小結

• 咱們一塊兒學習了 Java 多線程編程的方方面面，包括建立線程，以及對多個線程進行調度、管理。咱們深入認識到了多線程編程的複雜性，以及線程切換開銷帶來的多線程程序的低效性，這也促使咱們認真地思考一個問題：咱們是否須要多線程？什麼時候須要多線程？

• 多線程的核心在於多個代碼塊併發執行，本質特色在於各代碼塊之間的代碼是亂序執行的。咱們的程序是否須要多線程，就是要看這是否也是它的內在特色。

• 假如咱們的程序根本不要求多個代碼塊併發執行，那天然不須要使用多線程；假如咱們的程序雖然要求多個代碼塊併發執行，可是卻不要求亂序，則咱們徹底能夠用一個循環來簡單高效地實現，也不須要使用多線程；只有當它徹底符合多線程的特色時，多線程機制對線程間通訊和線程管理的強大支持纔能有用武之地，這時使用多線程纔是值得的。

 

參考資料： http://programming.iteye.com/blog/158568 http://lavasoft.blog.51cto.com/62575/51926

http://www.cnblogs.com/oubo/archive/2012/01/05/2394637.html