計算機的使用者一直覺得他們的計算機能夠同時作不少事情。他們認爲當其餘的應用程序在下載文件,管理打印隊列或者緩衝音頻的時候他們能夠繼續在文字處理程序上工做。甚至對於單個應用程序,他們任然期待它能在在同一時間作不少事情。舉個例子,一個流媒體播放程序必須能同時完成如下工做:從網絡上讀取數字音頻,解壓縮數字音頻,管理播放和更新程序顯示。甚至文字處理器也應該能在忙於從新格式化文本和刷新顯示的狀況下同時響應鍵盤和鼠標事件。這樣的軟件就被稱爲併發軟件。
經過Java語言和Java類庫對於基礎併發的支持,Java平臺具備徹底(from the ground up )支持併發編程的能力。從JDK5.0起,Java平臺還引入了高級併發APIs。這個課程不只涵蓋了Java平臺基礎併發內容,還對高級併發APIs有必定的闡述。
進程和線程![Top](http://static.javashuo.com/static/loading.gif)
(本部分
原文連接,
譯文連接,譯者:bjsuo,校對:鄭旭東)
在併發編程中,有兩個基本的執行單元:進程和線程。在java語言中,併發編程最關心的是線程,然而,進程也是很是重要的。
即便在只有單一的執行核心的計算機系統中,也有許多活動的進程和線程。所以,在任何給定的時刻,只有一個線程在實際執行。處理器的處理時間是經過操做系統的時間片在進程和線程中共享的。
如今具備多處理器或有多個執行內核的多處理器的計算機系統愈來愈廣泛,這大大加強了系統併發執行的進程和線程的吞吐量–但在不沒有多個處理器或執行內核的簡單的系統中,併發任然是可能的。
進程
進程具備一個獨立的執行環境。一般狀況下,進程擁有一個完整的、私有的基本運行資源集合。特別地,每一個進程都有本身的內存空間。
進程每每被看做是程序或應用的代名詞,然而,用戶看到的一個單獨的應用程序實際上多是一組相互協做的進程集合。爲了便於進程之間的通訊,大多數操做系統都支持進程間通訊(IPC),如pipes 和sockets。IPC不只支持同一系統上的通訊,也支持不一樣的系統。
Java虛擬機的大多數實現是單進程的。Java應用可使用的ProcessBuilder對象建立額外的進程,多進程應用超出了本課的範圍。
線程
線程有時也被稱爲輕量級的進程。進程和線程都提供了一個執行環境,但建立一個新的線程比建立一個新的進程須要的資源要少。
線程是在進程中存在的 — 每一個進程最少有一個線程。線程共享進程的資源,包括內存和打開的文件。這樣提升了效率,但潛在的問題就是線程間的通訊。
多線程的執行是Java平臺的一個基本特徵。每一個應用都至少有一個線程 – 或幾個,若是算上「系統」線程的話,好比內存管理和信號處理等。可是從程序員的角度來看,啓動的只有一個線程,叫主線程。這個線程有能力建立額外的線程,咱們將在下一節演示。
線程對象![Top](http://static.javashuo.com/static/loading.gif)
同步![Top](http://static.javashuo.com/static/loading.gif)
(本部分
原文連接,
譯文連接,譯者:蘑菇街-小寶,
Greenster,
李任 校對:丁一,鄭旭東,
李任)
線程間的通訊主要是經過共享域和引用相同的對象。這種通訊方式很是高效,不過可能會引起兩種錯誤:線程干擾和內存一致性錯誤。防止這些錯誤發生的方法是同步。
不過,同步會引發線程競爭,當兩個或多個線程試圖同時訪問相同的資源,隨之就致使Java運行時環境執行其中一個或多個線程比原先慢不少,甚至執行被掛起,這就出現了線程競爭。線程飢餓和活鎖都屬於線程競爭的範疇。關於線程競爭的更多信息可參考活躍度一節。
本節內容包括如下這些主題:
- 線程干擾討論了當多個線程訪問共享數據時錯誤是怎麼發生的。
- 內存一致性錯誤討論了不一致的共享內存視圖致使的錯誤。
- 同步方法討論了 一種能有效防止線程干擾和內存一致性錯誤的常見作法。
- 內部鎖和同步討論了更通用的同步方法,以及同步是如何基於內部鎖實現的。
- 原子訪問討論了不能被其餘線程干擾的操做的整體思路。
1. 線程干擾
下面這個簡單的Counter類:
- class Counter {
- private int c = 0;
- public void increment() {
- c++;
- }
- public void decrement() {
- c--;
- }
- public int value() {
- return c;
- }
- }
Counter類被設計成:每次調用increment()方法,c的值加1;每次調用decrement()方法,c的值減1。若是當同一個Counter對象被多個線程引用,線程間的干擾可能會使結果同咱們預期的不一致。
當兩個運行在不一樣的線程中卻做用在相同的數據上的操做交替執行時,就發生了線程干擾。這意味着這兩個操做都由多個步驟組成,而步驟間的順序產生了重疊。
Counter類實例的操做會交替執行,這看起來彷佛不太可能,由於c上的這兩個操做都是單一而簡單的語句。然而,即便一個簡單的語句也會被虛擬機轉換成多個步驟。咱們不去深究虛擬機內部的詳細執行步驟——理解c++這個單一的語句會被分解成3個步驟就足夠了:
- 獲取當前c的值;
- 對獲取到的值加1;
- 把遞增後的值寫回到c;
語句c–也能夠按一樣的方式分解,除了第二步的操做是遞減而不是遞增。
假設線程A調用increment()的同時線程B調用decrement().若是c的初始值爲0,線程A和B之間的交替執行順序多是下面這樣:
- 線程A:獲取c;
- 線程B:獲取c;
- 線程A:對獲取的值加1,結果爲1;
- 線程B:對獲取的值減1,結果爲-1;
- 線程A:結果寫回到c,c如今是1;
- 線程B:結果寫回到c,c如今是-1;
線程A的結果由於被線程B覆蓋而丟失了。這個交替執行的結果只是其中一種可能性。在不一樣的環境下,多是線程B的結果丟失了,也多是不會出任何問題。因爲結果是不可預知的,因此線程干擾的bug很難檢測和修復。
2. 內存一致性錯誤
當不一樣的線程對相同的數據產生不一致的視圖時會發生內存一致性錯誤。內存一致性錯誤的緣由比較複雜,也超出了本教程的範圍。不過幸運的是,一個程序員並不須要對這些緣由有詳細的瞭解。所須要的是避免它們的策略。
避免內存一致性錯誤的關鍵是理解happens-before關係。這種關係只是確保一個特定語句的寫內存操做對另一個特定的語句可見。要說明這個問題,請參考下面的例子。假設定義和初始化了一個簡單int字段:
這個counter字段被A,B兩個線程共享。假設線程A對counter執行遞增:
而後,很快的,線程B輸出counter:
- System.out.println(counter);
若是這兩個語句已經在同一個線程中被執行過,那麼輸出的值應該是「1」。不過若是這兩個語句在不一樣的線程中分開執行,那輸出的值極可能是「0」,由於沒法保證線程A對counter的改動對線程B是可見的——除非咱們在這兩個語句之間已經創建了happens-before關係。
有許多操做會創建happens-before關係。其中一個是同步,咱們將在下面的章節中看到。
咱們已經見過兩個創建happens-before關係的操做。
當一條語句調用Thread.start方法時,和該語句有happens-before關係的每一條語句,跟新線程執行的每一條語句一樣有happens-before關係。建立新線程以前的代碼的執行結果對線新線程是可見的。
當一個線程終止而且當致使另外一個線程中Thread.join返回時,被終止的線程執行的全部語句和在join返回成功以後的全部語句間有happens-before關係。線程中代碼的執行結果對執行join操做的線程是可見的。
要查看創建happens-before關係的操做列表,請參閱java.util.concurrent包的
摘要頁面。
3. 同步方法
Java編程語言提供兩種同步方式:同步方法和同步語句。相對較複雜的同步語句將在下一節中介紹。本節主要關注同步方法。
要讓一個方法成爲同步方法,只須要在方法聲明中加上synchronized關鍵字:
- public class SynchronizedCounter {
- private int c = 0;
-
- public synchronized void increment() {
- c++;
- }
-
- public synchronized void decrement() {
- c--;
- }
-
- public synchronized int value() {
- return c;
- }
- }
若是count是SynchronizedCounter類的實例,那麼讓這些方法成爲同步方法有兩個做用:
首先,相同對象上的同步方法的兩次調用,它們要交替執行是不可能的。 當一個線程正在執行對象的同步方法時,全部其餘調用該對象同步方法的線程會被阻塞(掛起執行),直到第一個線程處理完該對象。
其次,當一個同步方法退出時,它會自動跟該對象同步方法的任意後續調用創建起一種happens-before關係。這確保對象狀態的改變對全部線程是可見的。
注意構造方法不能是同步的——構造方法加synchronized關鍵字會報語法錯誤。同步的構造方法沒有意義,由於當這個對象被建立的時候,只有建立對象的線程能訪問它。
警告:當建立的對象會被多個線程共享時必須很是當心,對象的引用不要過早「暴露」出去。好比,假設你要維護一個叫instances的List,它包含類的每個實例對象。你可能會嘗試在構造方法中加這樣一行:
不過其餘線程就可以在對象構造完成以前使用instances訪問對象。
同步(synchronized)方法使用一種簡單的策略來防止線程干擾和內存一致性錯誤:若是一個對象對多個線程可見,對象域上的全部讀寫操做都是經過synchronized方法來完成的。(一個重要的例外:final域,在對象被建立後不可修改,能被非synchronized方法安全的讀取)。synchronized同步策略頗有效,不過會引發活躍度問題,咱們將在本節後面看到。
4. 內部鎖與同步
同步機制的創建是基於其內部一個叫內部鎖或者監視鎖的實體。(在Java API規範中一般被稱爲監視器。)內部鎖在同步機制中起到兩方面的做用:對一個對象的排他性訪問;創建一種happens-before關係,而這種關係正是可見性問題的關鍵所在。
每一個對象都有一個與之關聯的內部鎖。一般當一個線程須要排他性的訪問一個對象的域時,首先須要請求該對象的內部鎖,當訪問結束時釋放內部鎖。在線程得到內部鎖到釋放內部鎖的這段時間裏,咱們說線程擁有這個內部鎖。那麼當一個線程擁有一個內部鎖時,其餘線程將沒法得到該內部鎖。其餘線程若是去嘗試得到該內部鎖,則會被阻塞。
當線程釋放一個內部鎖時,該操做和對該鎖的後續請求間將創建happens-before關係。
5. 同步方法中的鎖
當線程調用一個同步方法時,它會自動請求該方法所在對象的內部鎖。當方法返回結束時則自動釋放該內部鎖,即便退出是因爲發生了未捕獲的異常,內部鎖也會被釋放。
你可能會問調用一個靜態的同步方法會如何,因爲靜態方法是和類(而不是對象)相關的,因此線程會請求類對象(Class Object)的內部鎖。所以用來控制類的靜態域訪問的鎖不一樣於控制對象訪問的鎖。
6. 同步塊
另一種同步的方法是使用同步塊。和同步方法不一樣,同步塊必須指定所請求的是哪一個對象的內部鎖:
- public void addName(String name) {
- synchronized(this) {
- lastName = name;
- nameCount++;
- }
- nameList.add(name);
- }
在上面的例子中,addName方法須要使lastName和nameCount的更改保持同步,並且要避免同步調用該對象的其餘方法。(在同步代碼中調用其餘方法會產生
Liveness一節所描述的問題。)若是不使用同步塊,那麼必需要定義一個額外的非同步方法,而這個方法僅僅是用來調用nameList.add。
使用同步塊對於更細粒度的同步頗有幫助。例如類MsLunch有兩個實例域c1和c2,他們並不會同時使用(譯者注:即c1和c2是彼此無關的兩個域),全部對這兩個域的更新都須要同步,可是徹底不須要防止c1的修改和c2的修改相互之間干擾(這樣作只會產生沒必要要的阻塞而下降了併發性)。這種狀況下沒必要使用同步方法,可使用和this對象相關的鎖。這裏咱們建立了兩個「鎖」對象(譯者注:起到加鎖效果的普通對象lock1和lock2)。
- public class MsLunch {
- private long c1 = 0;
- private long c2 = 0;
- private Object lock1 = new Object();
- private Object lock2 = new Object();
-
- public void inc1() {
- synchronized(lock1) {
- c1++;
- }
- }
-
- public void inc2() {
- synchronized(lock2) {
- c2++;
- }
- }
- }
使用這種方法時要特別當心,須要十分肯定c1和c2是彼此無關的域。
7. 可重入同步
還記得嗎,一個線程不能得到其餘線程所擁有的鎖。可是它能夠得到本身已經擁有的鎖。容許一個線程屢次得到同一個鎖實現了可重入同步。這裏描述了一種同步代碼的場景,直接的或間接地,調用了一個也擁有同步代碼的方法,且兩邊的代碼使用的是同一把鎖。若是沒有這種可重入的同步機制,同步代碼則須要採起許多額外的預防措施以防止線程阻塞本身。
8. 原子訪問
在編程過程當中,原子操做是指全部操做都同時發生。原子操做不能被中途打斷:要麼全作,要麼不作。原子操做在完成前不會有看得見的反作用。
咱們發現像c++這樣的增量表達式,並無描述原子操做。即便是很是簡單的表達式也可以定義成能被分解爲其餘操做的複雜操做。然而,有些操做你能夠定義爲原子的:
- 對引用變量和大部分基本類型變量(除long和double以外)的讀寫是原子的。
- 對全部聲明爲volatile的變量(包括long和double變量)的讀寫是原子的。
原子操做不會交錯,因而能夠放心使用,沒必要擔憂線程干擾。然而,這並不能徹底消除原子操做上的同步,由於內存一致性錯誤仍可能發生。使用volatile變量能夠下降內存一致性錯誤的風險,由於對volatile變量的任意寫操做,對於後續在該變量上的讀操做創建了happens-before關係。這意味着volatile變量的修改對於其餘線程老是可見的。更重要的是,這同時也意味着當一個線程讀取一個volatile變量時,它不只能看到該變量最新的修改,並且也能看到導致該改變發生的代碼的副效應。
使用簡單的原子變量訪問比經過同步代碼來訪問更高效,可是須要程序員更加謹慎以免內存一致性錯誤。至於這額外的付出是否值得,得看應用的大小和複雜度。
java.util.concurrent包中的一些類提供了一些不依賴同步機制的原子方法。咱們將在高級併發對象這一節中討論它們。
活躍度![Top](http://static.javashuo.com/static/loading.gif)
(本部分
原文地址,
譯文地址,譯者:
李任,鄭旭東 校對:
蘑菇街-小寶)
一個併發應用程序能及時執行的能力稱爲活躍性。本節將介紹最多見的活躍性問題:死鎖(deadlock),以及另外兩個活躍性問題:飢餓(starvation)和活鎖(livelock)。
1. 死鎖
死鎖描述了這樣一種情景,兩個或多個線程永久阻塞,互相等待對方釋放資源。下面是一個例子。
Alphone和Gaston是朋友,都很講究禮節。禮節有一個嚴格的規矩,當你向一個朋友鞠躬時,你必須保持鞠躬的姿式,直到你的朋友有機會回鞠給你。不幸的是,這個規矩沒有算上兩個朋友相互同時鞠躬的可能。
下面的應用例子,DeadLock,模擬了這個可能性。
- static class Friend {
- private final String name;
- public Friend(String name) {
- this.name = name;
- }
- public String getName() {
- return this.name;
- }
- public synchronized void bow(Friend bower) {
- System.out.format("%s: %s"
- + " has bowed to me!%n",
- this.name, bower.getName());
- bower.bowBack(this);
- }
- public synchronized void bowBack(Friend bower) {
- System.out.format("%s: %s"
- + " has bowed back to me!%n",
- this.name, bower.getName());
- }
- }
-
- public static void main(String[] args) {
- final Friend alphonse =
- new Friend("Alphonse");
- final Friend gaston =
- new Friend("Gaston");
- new Thread(new Runnable() {
- public void run() { alphonse.bow(gaston); }
- }).start();
- new Thread(new Runnable() {
- public void run() { gaston.bow(alphonse); }
- }).start();
- }
- }
當DeadLock運行後,兩個線程極有可能阻塞,當它們嘗試調用bowBack方法時。沒有哪一個阻塞會結束,由於每一個線程都在等待另外一個線程退出bow方法。
2. 飢餓和活鎖
飢餓和活鎖並不如死鎖通常廣泛,但它仍然是每一個併發程序設計者可能會遇到的問題。
飢餓
飢餓是指當一個線程不能正常的訪問共享資源而且不能正常執行的狀況。這一般在共享資源被其餘「貪心」的線程長期時發生。舉個例子,假設一個對象提供了一個同步方法,這個方法一般須要執行很長一段時間才返回。若是一個線程常常調用這個方法,那麼其餘須要同步的訪問這個對象的線程就常常會被阻塞。
活鎖
一個線程一般會有會響應其餘線程的活動。若是其餘線程也會響應另外一個線程的活動,那麼就有可能發生活鎖。同死鎖同樣,發生活鎖的線程沒法繼續執行。然而線程並無阻塞——他們在忙於響應對方沒法恢復工做。這就至關於兩個在走廊相遇的人:Alphonse向他本身的左邊靠想讓Gaston過去,而Gaston向他的右邊靠想讓Alphonse過去。可見他們阻塞了對方。Alphonse向他的右邊靠,而Gaston向他的左邊靠,他們仍是阻塞了對方。
保護塊(Guarded Blocks)![Top](http://static.javashuo.com/static/loading.gif)
(本部分
原文鏈接,
譯文鏈接,譯者:Greester,校對:鄭旭東)
多線程之間常常須要協同工做,最多見的方式是使用Guarded Blocks,它循環檢查一個條件(一般初始值爲true),直到條件發生變化才跳出循環繼續執行。在使用Guarded Blocks時有如下幾個步驟須要注意:
假設guardedJoy()方法必需要等待另外一線程爲共享變量joy設值才能繼續執行。那麼理論上能夠用一個簡單的條件循環來實現,但在等待過程當中guardedJoy方法不停的檢查循環條件其實是一種資源浪費。
- public void guardedJoy() {
-
-
- while(!joy) {}
- System.out.println("Joy has been achieved!");
- }
更加高效的方法是調用Object.wait將當前線程掛起,直到有另外一線程發起事件通知(儘管通知的事件不必定是當前線程等待的事件)。
- public synchronized void guardedJoy() {
-
-
- while(!joy) {
- try {
- wait();
- } catch (InterruptedException e) {}
- }
- System.out.println("Joy and efficiency have been achieved!");
- }
注意:必定要在循環裏面調用wait方法,不要想固然的認爲線程喚醒後循環條件必定發生了改變。
和其餘能夠暫停線程執行的方法同樣,wait方法會拋出InterruptedException,在上面的例子中,由於咱們關心的是joy的值,因此忽略了InterruptedException。
爲何guardedJoy是synchronized方法?假設d是用來調用wait的對象,當一個線程調用d.wait,它必需要擁有d的內部鎖(不然會拋出異常),得到d的內部鎖的最簡單方法是在一個synchronized方法裏面調用wait。
當一個線程調用wait方法時,它釋放鎖並掛起。而後另外一個線程請求並得到這個鎖並調用
Object.notifyAll通知全部等待該鎖的線程。
- public synchronized notifyJoy() {
- joy = true;
- notifyAll();
- }
當第二個線程釋放這個該鎖後,第一個線程再次請求該鎖,從wait方法返回並繼續執行。
注意:還有另一個通知方法,notify(),它只會喚醒一個線程。但因爲它並不容許指定哪個線程被喚醒,因此通常只在大規模併發應用(即系統有大量類似任務的線程)中使用。由於對於大規模併發應用,咱們其實並不關心哪個線程被喚醒。
如今咱們使用Guarded blocks建立一個生產者/消費者應用。這類應用須要在兩個線程之間共享數據:生產者生產數據,消費者使用數據。兩個線程經過共享對象通訊。在這裏,線程協同工做的關鍵是:生產者發佈數據以前,消費者不可以去讀取數據;消費者沒有讀取舊數據前,生產者不能發佈新數據。
在下面的例子中,數據經過
Drop對象共享的一系列文本消息:
- public class Drop {
-
-
- private String message;
-
-
-
-
- private boolean empty = true;
-
- public synchronized String take() {
-
-
- while (empty) {
- try {
- wait();
- } catch (InterruptedException e) {}
- }
-
- empty = true;
-
-
- notifyAll();
- return message;
- }
-
- public synchronized void put(String message) {
-
-
- while (!empty) {
- try {
- wait();
- } catch (InterruptedException e) {}
- }
-
- empty = false;
-
- this.message = message;
-
-
- notifyAll();
- }
- }
Producer是生產者線程,發送一組消息,字符串DONE表示全部消息都已經發送完成。爲了模擬現實狀況,生產者線程還會在消息發送時隨機的暫停。
- import java.util.Random;
-
- public class Producer implements Runnable {
- private Drop drop;
-
- public Producer(Drop drop) {
- this.drop = drop;
- }
-
- public void run() {
- String importantInfo[] = {
- "Mares eat oats",
- "Does eat oats",
- "Little lambs eat ivy",
- "A kid will eat ivy too"
- };
- Random random = new Random();
-
- for (int i = 0;
- i < importantInfo.length;
- i++) {
- drop.put(importantInfo[i]);
- try {
- Thread.sleep(random.nextInt(5000));
- } catch (InterruptedException e) {}
- }
- drop.put("DONE");
- }
- }
Consumer是消費者線程,讀取消息並打印出來,直到讀取到字符串DONE爲止。消費者線程在消息讀取時也會隨機的暫停。
- import java.util.Random;
-
- public class Consumer implements Runnable {
- private Drop drop;
-
- public Consumer(Drop drop) {
- this.drop = drop;
- }
-
- public void run() {
- Random random = new Random();
- for (String message = drop.take();
- ! message.equals("DONE");
- message = drop.take()) {
- System.out.format("MESSAGE RECEIVED: %s%n", message);
- try {
- Thread.sleep(random.nextInt(5000));
- } catch (InterruptedException e) {}
- }
- }
- }
ProducerConsumerExample是主線程,它啓動生產者線程和消費者線程。
- public class ProducerConsumerExample {
- public static void main(String[] args) {
- Drop drop = new Drop();
- (new Thread(new Producer(drop))).start();
- (new Thread(new Consumer(drop))).start();
- }
- }
注意:Drop類是用來演示Guarded Blocks如何工做的。爲了不從新發明輪子,當你嘗試建立本身的共享數據對象時,請查看
Java Collections Framework中已有的數據結構。如需更多信息,請參考
Questions and Exercises。
不可變對象![Top](http://static.javashuo.com/static/loading.gif)
(本部分
原文連接,
譯文連接,譯者:Greenster,校對:鄭旭東)
一個對象若是在建立後不能被修改,那麼就稱爲不可變對象。在併發編程中,一種被廣泛承認的原則就是:儘量的使用不可變對象來建立簡單、可靠的代碼。
在併發編程中,不可變對象特別有用。因爲建立後不能被修改,因此不會出現因爲線程干擾產生的錯誤或是內存一致性錯誤。
可是程序員們一般並不熱衷於使用不可變對象,由於他們擔憂每次建立新對象的開銷。實際上這種開銷經常被過度高估,並且使用不可變對象所帶來的一些效率提高也抵消了這種開銷。例如:使用不可變對象下降了垃圾回收所產生的額外開銷,也減小了用來確保使用可變對象不出現併發錯誤的一些額外代碼。
接下來看一個可變對象的類,而後轉化爲一個不可變對象的類。經過這個例子說明轉化的原則以及使用不可變對象的好處。
一個同步類的例子
SynchronizedRGB是表示顏色的類,每個對象表明一種顏色,使用三個整形數表示顏色的三基色,字符串表示顏色名稱。
- public class SynchronizedRGB {
-
-
- private int red;
- private int green;
- private int blue;
- private String name;
-
- private void check(int red,
- int green,
- int blue) {
- if (red < 0 || red > 255
- || green < 0 || green > 255
- || blue < 0 || blue > 255) {
- throw new IllegalArgumentException();
- }
- }
-
- public SynchronizedRGB(int red,
- int green,
- int blue,
- String name) {
- check(red, green, blue);
- this.red = red;
- this.green = green;
- this.blue = blue;
- this.name = name;
- }
-
- public void set(int red,
- int green,
- int blue,
- String name) {
- check(red, green, blue);
- synchronized (this) {
- this.red = red;
- this.green = green;
- this.blue = blue;
- this.name = name;
- }
- }
-
- public synchronized int getRGB() {
- return ((red << 16) | (green << 8) | blue);
- }
-
- public synchronized String getName() {
- return name;
- }
-
- public synchronized void invert() {
- red = 255 - red;
- green = 255 - green;
- blue = 255 - blue;
- name = "Inverse of " + name;
- }
- }
使用SynchronizedRGB時須要當心,避免其處於不一致的狀態。例如一個線程執行了如下代碼:
- SynchronizedRGB color =
- new SynchronizedRGB(0, 0, 0, "Pitch Black");
- ...
- int myColorInt = color.getRGB();
- String myColorName = color.getName();
若是有另一個線程在Statement 1以後、Statement 2以前調用了color.set方法,那麼myColorInt的值和myColorName的值就會不匹配。爲了不出現這樣的結果,必需要像下面這樣把這兩條語句綁定到一塊執行:
- synchronized (color) {
- int myColorInt = color.getRGB();
- String myColorName = color.getName();
- }
這種不一致的問題只可能發生在可變對象上。
定義不可變對象的策略
如下的一些規則是建立不可變對象的簡單策略。並不是全部不可變類都徹底遵照這些規則,不過這不是編寫這些類的程序員們粗枝大葉形成的,極可能的是他們有充分的理由確保這些對象在建立後不會被修改。但這須要很是複雜細緻的分析,並不適用於初學者。
- 不要提供setter方法。(包括修改字段的方法和修改字段引用對象的方法)
- 將類的全部字段定義爲final、private的。
- 不容許子類重寫方法。簡單的辦法是將類聲明爲final,更好的方法是將構造函數聲明爲私有的,經過工廠方法建立對象。
- 若是類的字段是對可變對象的引用,不容許修改被引用對象。
·不提供修改可變對象的方法。
·不共享可變對象的引用。當一個引用被當作參數傳遞給構造函數,而這個引用指向的是一個外部的可變對象時,必定不要保存這個引用。若是必需要保存,那麼建立可變對象的拷貝,而後保存拷貝對象的引用。一樣若是須要返回內部的可變對象時,不要返回可變對象自己,而是返回其拷貝。
將這一策略應用到SynchronizedRGB有如下幾步:
- SynchronizedRGB類有兩個setter方法。第一個set方法只是簡單的爲字段設值(譯者注:刪掉便可),第二個invert方法修改成建立一個新對象,而不是在原有對象上修改。
- 全部的字段都已是私有的,加上final便可。
- 將類聲明爲final的
- 只有一個字段是對象引用,而且被引用的對象也是不可變對象。
通過以上這些修改後,咱們獲得了
ImmutableRGB:
- final public class ImmutableRGB {
-
-
- final private int red;
- final private int green;
- final private int blue;
- final private String name;
-
- private void check(int red,
- int green,
- int blue) {
- if (red < 0 || red > 255
- || green < 0 || green > 255
- || blue < 0 || blue > 255) {
- throw new IllegalArgumentException();
- }
- }
-
- public ImmutableRGB(int red,
- int green,
- int blue,
- String name) {
- check(red, green, blue);
- this.red = red;
- this.green = green;
- this.blue = blue;
- this.name = name;
- }
-
- public int getRGB() {
- return ((red << 16) | (green << 8) | blue);
- }
-
- public String getName() {
- return name;
- }
-
- public ImmutableRGB invert() {
- return new ImmutableRGB(255 - red,
- 255 - green,
- 255 - blue,
- "Inverse of " + name);
- }
- }
高級併發對象![Top](http://static.javashuo.com/static/loading.gif)
(本部分
原文連接,
譯文連接,譯者:
李任)
目前爲止,該教程重點講述了最初做爲Java平臺一部分的低級別API。這些API對於很是基本的任務來講已經足夠,可是對於更高級的任務就須要更高級的API。特別是針對充分利用了當今多處理器和多核系統的大規模併發應用程序。 本節,咱們將着眼於Java 5.0新增的一些高級併發特徵。大多數特徵已經在新的java.util.concurrent包中實現。Java集合框架中也定義了新的併發數據結構。
- 鎖對象提供了能夠簡化許多併發應用的鎖的慣用法。
- Executors爲加載和管理線程定義了高級API。Executors的實現由java.util.concurrent包提供,提供了適合大規模應用的線程池管理。
- 併發集合簡化了大型數據集合管理,且極大的減小了同步的需求。
- 原子變量有減少同步粒度和避免內存一致性錯誤的特徵。
- 併發隨機數(JDK7)提供了高效的多線程生成僞隨機數的方法。
1. 鎖對象
同步代碼依賴於一種簡單的可重入鎖。這種鎖使用簡單,但也有諸多限制。
java.util.concurrent.locks包提供了更復雜的鎖。咱們不會詳細考察這個包,但會重點關注其最基本的接口,鎖。 鎖對象做用很是相似同步代碼使用的隱式鎖。如同隱式鎖,每次只有一個線程能夠得到鎖對象。經過關聯
Condition對象,鎖對象也支持wait/notify機制。 鎖對象之於隱式鎖最大的優點在於,它們有能力收回得到鎖的嘗試。若是當前鎖對象不可用,或者鎖請求超時(若是超時時間已指定),tryLock方法會收回獲取鎖的請求。若是在鎖獲取前,另外一個線程發送了一箇中斷,lockInterruptibly方法也會收回獲取鎖的請求。 讓咱們使用鎖對象來解決咱們在
活躍度中見到的死鎖問題。Alphonse和Gaston已經把本身訓練成能注意到朋友什麼時候要鞠躬。咱們經過要求Friend對象在雙方鞠躬前必須先得到鎖來模擬此次改善。下面是改善後模型的源代碼,Safelock。爲了展現其用途普遍,咱們假設Alphonse和Gaston對於他們新發現的穩定鞠躬的能力是如此入迷,以致於他們沒法不相互鞠躬。
- import java.util.concurrent.locks.Lock;
- import java.util.concurrent.locks.ReentrantLock;
- import java.util.Random;
-
- public class Safelock {
- static class Friend {
- private final String name;
- private final Lock lock = new ReentrantLock();
-
- public Friend(String name) {
- this.name = name;
- }
-
- public String getName() {
- return this.name;
- }
-
- public boolean impendingBow(Friend bower) {
- Boolean myLock = false;
- Boolean yourLock = false;
- try {
- myLock = lock.tryLock();
- yourLock = bower.lock.tryLock();
- } finally {
- if (! (myLock && yourLock)) {
- if (myLock) {
- lock.unlock();
- }
- if (yourLock) {
- bower.lock.unlock();
- }
- }
- }
- return myLock && yourLock;
- }
-
- public void bow(Friend bower) {
- if (impendingBow(bower)) {
- try {
- System.out.format("%s: %s has"
- + " bowed to me!%n",
- this.name, bower.getName());
- bower.bowBack(this);
- } finally {
- lock.unlock();
- bower.lock.unlock();
- }
- } else {
- System.out.format("%s: %s started"
- + " to bow to me, but saw that"
- + " I was already bowing to"
- + " him.%n",
- this.name, bower.getName());
- }
- }
-
- public void bowBack(Friend bower) {
- System.out.format("%s: %s has" +
- " bowed back to me!%n",
- this.name, bower.getName());
- }
- }
-
- static class BowLoop implements Runnable {
- private Friend bower;
- private Friend bowee;
-
- public BowLoop(Friend bower, Friend bowee) {
- this.bower = bower;
- this.bowee = bowee;
- }
-
- public void run() {
- Random random = new Random();
- for (;;) {
- try {
- Thread.sleep(random.nextInt(10));
- } catch (InterruptedException e) {}
- bowee.bow(bower);
- }
- }
- }
-
- public static void main(String[] args) {
- final Friend alphonse =
- new Friend("Alphonse");
- final Friend gaston =
- new Friend("Gaston");
- new Thread(new BowLoop(alphonse, gaston)).start();
- new Thread(new BowLoop(gaston, alphonse)).start();
- }
- }
2. 執行器(Executors)
在以前全部的例子中,Thread對象表示的線程和Runnable對象表示的線程所執行的任務之間是緊耦合的。這對於小型應用程序來講沒問題,但對於大規模併發應用來講,合理的作法是將線程的建立與管理和程序的其餘部分分離開。封裝這些功能的對象就是執行器,接下來的部分將講詳細描述執行器。
3. Executor接口
java.util.concurrent中包括三個Executor接口:
- Executor,一個運行新任務的簡單接口。
- ExecutorService,擴展了Executor接口。添加了一些用來管理執行器生命週期和任務生命週期的方法。
- ScheduledExecutorService,擴展了ExecutorService。支持Future和按期執行任務。
一般來講,指向Executor對象的變量應被聲明爲以上三種接口之一,而不是具體的實現類。
Executor接口
Executor接口只有一個execute方法,用來替代一般建立(啓動)線程的方法。例如:r是一個Runnable對象,e是一個Executor對象。可使用
來代替
但execute方法沒有定義具體的實現方式。對於不一樣的Executor實現,execute方法多是建立一個新線程並當即啓動,但更有多是使用已有的工做線程運行r,或者將r放入到隊列中等待可用的工做線程。(咱們將在線程池一節中描述工做線程。)
ExecutorService接口
ExecutorService接口在提供了execute方法的同時,新加了更加通用的submit方法。submit方法除了和execute方法同樣能夠接受Runnable對象做爲參數,還能夠接受Callable對象做爲參數。使用Callable對象能夠能使任務返還執行的結果。經過submit方法返回的Future對象能夠讀取Callable任務的執行結果,或是管理Callable任務和Runnable任務的狀態。 ExecutorService也提供了批量運行Callable任務的方法。最後,ExecutorService還提供了一些關閉執行器的方法。若是須要支持即時關閉,執行器所執行的任務須要正確處理中斷。
ScheduledExecutorService接口
ScheduledExecutorService擴展ExecutorService接口並添加了schedule方法。調用schedule方法能夠在指定的延時後執行一個Runnable或者Callable任務。ScheduledExecutorService接口還定義了按照指定時間間隔按期執行任務的scheduleAtFixedRate方法和scheduleWithFixedDelay方法。
4. 線程池
在java.util.concurrent包中多數的執行器實現都使用了由工做線程組成的線程池,工做線程獨立於所它所執行的Runnable任務和Callable任務,而且經常使用來執行多個任務。 使用工做線程可使建立線程的開銷最小化。
在大規模併發應用中,建立大量的Thread對象會佔用佔用大量系統內存,分配和回收這些對象會產生很大的開銷。一種最多見的線程池是固定大小的線程池。這種線程池始終有必定數量的線程在運行,若是一個線程因爲某種緣由終止運行了,線程池會自動建立一個新的線程來代替它。須要執行的任務經過一個內部隊列提交給線程,當沒有更多的工做線程能夠用來執行任務時,隊列保存額外的任務。 使用固定大小的線程池一個很重要的好處是能夠實現優雅退化。例如一個Web服務器,每個HTTP請求都是由一個單獨的線程來處理的,若是爲每個HTTP都建立一個新線程,那麼當系統的開銷超出其能力時,會忽然地對全部請求都中止響應。若是限制Web服務器能夠建立的線程數量,那麼它就沒必要當即處理全部收到的請求,而是在有能力處理請求時才處理。 建立一個使用線程池的執行器最簡單的方法是調用
java.util.concurrent.Executors的
newFixedThreadPool方法。Executors類還提供了下列一下方法:
若是上面的方法都不知足須要,能夠嘗試
java.util.concurrent.ThreadPoolExecutor或者
java.util.concurrent.ScheduledThreadPoolExecutor。
5. Fork/Joint
fork/join框架是ExecutorService接口的一種具體實現,目的是爲了幫助你更好地利用多處理器帶來的好處。它是爲那些可以被遞歸地拆解成子任務的工做類型量身設計的。其目的在於可以使用全部可用的運算能力來提高你的應用的性能。 相似於ExecutorService接口的其餘實現,fork/join框架會將任務分發給線程池中的工做線程。fork/join框架的獨特之處在與它使用工做竊取(work-stealing)算法。完成本身的工做而處於空閒的工做線程可以從其餘仍然處於忙碌(busy)狀態的工做線程處竊取等待執行的任務。 fork/join框架的核心是
ForkJoinPool類,它是對AbstractExecutorService類的擴展。ForkJoinPool實現了工做偷取算法,並能夠執行
ForkJoinTask任務。
基本使用方法
使用fork/join框架的第一步是編寫執行一部分工做的代碼。你的代碼結構看起來應該與下面所示的僞代碼相似:
- if (當前這個任務工做量足夠小)
- 直接完成這個任務
- else
- 將這個任務或這部分工做分解成兩個部分
- 分別觸發(invoke)這兩個子任務的執行,並等待結果
你須要將這段代碼包裹在一個ForkJoinTask的子類中。不過,一般狀況下會使用一種更爲具體的的類型,或者是
RecursiveTask(會返回一個結果),或者是
RecursiveAction。 當你的ForkJoinTask子類準備好了,建立一個表明全部須要完成工做的對象,而後將其做爲參數傳遞給一個ForkJoinPool實例的invoke()方法便可。
要清晰,先模糊
想要了解fork/join框架的基本工做原理,接下來的這個例子會有所幫助。假設你想要模糊一張圖片。原始的source圖片由一個整數的數組表示,每一個整數表示一個像素點的顏色數值。與source圖片相同,模糊以後的destination圖片也由一個整數數組表示。 對圖片的模糊操做是經過對source數組中的每個像素點進行處理完成的。處理的過程是這樣的:將每一個像素點的色值取出,與周圍像素的色值(紅、黃、藍三個組成部分)放在一塊兒取平均值,獲得的結果被放入destination數組。由於一張圖片會由一個很大的數組來表示,這個流程會花費一段較長的時間。若是使用fork/join框架來實現這個模糊算法,你就可以藉助多處理器系統的並行處理能力。下面是上述算法結合fork/join框架的一種簡單實現:
- public class ForkBlur extends RecursiveAction {
- private int[] mSource;
- private int mStart;
- private int mLength;
- private int[] mDestination;
-
- private int mBlurWidth = 15;
-
- public ForkBlur(int[] src, int start, int length, int[] dst) {
- mSource = src;
- mStart = start;
- mLength = length;
- mDestination = dst;
- }
-
- protected void computeDirectly() {
- int sidePixels = (mBlurWidth - 1) / 2;
- for (int index = mStart; index < mStart + mLength; index++) {
-
- float rt = 0, gt = 0, bt = 0;
- for (int mi = -sidePixels; mi <= sidePixels; mi++) {
- int mindex = Math.min(Math.max(mi + index, 0),
- mSource.length - 1);
- int pixel = mSource[mindex];
- rt += (float)((pixel & 0x00ff0000) >> 16)
- / mBlurWidth;
- gt += (float)((pixel & 0x0000ff00) >> 8)
- / mBlurWidth;
- bt += (float)((pixel & 0x000000ff) >> 0)
- / mBlurWidth;
- }
-
-
- int dpixel = (0xff000000 ) |
- (((int)rt) << 16) |
- (((int)gt) << 8) |
- (((int)bt) << 0);
- mDestination[index] = dpixel;
- }
- }
接下來你須要實現父類中的compute()方法,它會直接執行模糊處理,或者將當前的工做拆分紅兩個更小的任務。數組的長度能夠做爲一個簡單的閥值來判斷任務是應該直接完成仍是應該被拆分。
- protected static int sThreshold = 100000;
-
- protected void compute() {
- if (mLength < sThreshold) {
- computeDirectly();
- return;
- }
-
- int split = mLength / 2;
-
- invokeAll(new ForkBlur(mSource, mStart, split, mDestination),
- new ForkBlur(mSource, mStart + split, mLength - split,
- mDestination));
- }
若是前面這個方法是在一個RecursiveAction的子類中,那麼設置任務在ForkJoinPool中執行就再直觀不過了。一般會包含如下一些步驟:
(1) 建立一個表示全部須要完成工做的任務。
- ForkBlur fb = new ForkBlur(src, 0, src.length, dst);
(2) 建立將要用來執行任務的ForkJoinPool。
- ForkJoinPool pool = new ForkJoinPool();
(3) 執行任務。
想要瀏覽完成的源代碼,請查看
ForkBlur,其中還包含一些建立destination圖片文件的額外代碼。
標準實現
除了可以使用fork/join框架來實現可以在多處理系統中被並行執行的定製化算法(如前文中的ForkBlur.java例子),在Java SE中一些比較經常使用的功能點也已經使用fork/join框架來實現了。在Java SE 8中,java.util.Arrays類的一系列parallelSort()方法就使用了fork/join來實現。這些方法與sort()系列方法很相似,可是經過使用fork/join框架,藉助了併發來完成相關工做。在多處理器系統中,對大數組的並行排序會比串行排序更快。這些方法到底是如何運用fork/join框架並不在本教程的討論範圍內。想要了解更多的信息,請參見Java API文檔。 其餘採用了fork/join框架的方法還包括java.util.streams包中的一些方法,此包是做爲Java SE 8發行版中
Project Lambda的一部分。想要了解更多信息,請參見
Lambda Expressions一節。
6. 併發集合
java.util.concurrent包囊括了Java集合框架的一些附加類。它們也最容易按照集合類所提供的接口來進行分類:
7. 原子變量
java.util.concurrent.atomic包定義了對單一變量進行原子操做的類。全部的類都提供了get和set方法,可使用它們像讀寫volatile變量同樣讀寫原子類。就是說,同一變量上的一個set操做對於任意後續的get操做存在happens-before關係。原子的compareAndSet方法也有內存一致性特色,就像應用到整型原子變量中的簡單原子算法。 爲了看看這個包如何使用,讓咱們返回到最初用於演示線程干擾的
Counter類:
- class Counter {
- private int c = 0;
- public void increment() {
- c++;
- }
-
- public void decrement() {
- c--;
- }
-
- public int value() {
- return c;
- }
- }
使用同步是一種使Counter類變得線程安全的方法,如
SynchronizedCounter:
- class SynchronizedCounter {
- private int c = 0;
- public synchronized void increment() {
- c++;
- }
- public synchronized void decrement() {
- c--;
- }
- public synchronized int value() {
- return c;
- }
- }
對於這個簡單的類,同步是一種可接受的解決方案。可是對於更復雜的類,咱們可能想要避免沒必要要同步所帶來的活躍度影響。將int替換爲AtomicInteger容許咱們在不進行同步的狀況下阻止線程干擾,如
AtomicCounter:
- import java.util.concurrent.atomic.AtomicInteger;
- class AtomicCounter {
- private AtomicInteger c = new AtomicInteger(0);
- public void increment() {
- c.incrementAndGet();
- }
-
- public void decrement() {
- c.decrementAndGet();
- }
-
- public int value() {
- return c.get();
- }
8. 併發隨機數
在JDK7中,java.util.concurrent包含了一個至關便利的類,ThreadLocalRandom,當應用程序指望在多個線程或ForkJoinTasks中使用隨機數時。
美源星
對於併發訪問,使用TheadLocalRandom代替Math.random()能夠減小競爭,從而得到更好的性能。
你只需調用ThreadLocalRandom.current(), 而後調用它的其中一個方法去獲取一個隨機數便可。下面是一個例子:
- int r = ThreadLocalRandom.current().nextInt(4,77);
blog.chinaunix.net/uid-30065054-id-5753320.htmlhtml
blog.itpub.net/30065054/viewspace-2126308java
www.niuche.com/article/1139447.htmlc++
www.niuche.com/article/1139449.html程序員
mingjia.cngold.org/expert/1304176/news/c789018.htm算法
mingjia.cngold.org/expert/1304176/news/c789000.htmexpress
mingjia.cngold.org/expert/1304176/news/c788983.htm編程
mingjia.cngold.org/expert/1304176/news/c788929.htmapi
mingjia.cngold.org/expert/1304176/news/c788947.htm數組
mingjia.cngold.org/expert/1304176/news/c788918.htm安全
mingjia.cngold.org/expert/1304176/news/c788897.htm
mingjia.cngold.org/expert/1304176/news/c788875.htm
mingjia.cngold.org/expert/1304176/news/c788862.htm
mingjia.cngold.org/expert/1304176/news/c788835.htm
www.wangchao.net.cn/hi/detail_227849.html
mingjia.cngold.org/expert/1304176/news/c789238.htm
www.wangchao.net.cn/hi/detail_228106.html
www.wangchao.net.cn/hi/detail_228108.html
site.leshou.com/s/33270717.html
site.leshou.com/s/33270662.html
site.leshou.com/s/33270579.html
site.leshou.com/s/33270536.html
site.leshou.com/s/33270498.html
site.leshou.com/s/33270383.html
site.leshou.com/s/33270315.html
www.365128.com/user/myx2/22.html
www.365128.com/user/myx2/25.html
www.365128.com/user/myx2/26.html
www.365128.com/user/myx2/27.html
www.365128.com/user/myx2/28.html