Java編程思想

Java編程思想

順序編程，即程序中的所有事物在任意時刻都只能執(zhí)行一個步驟。并發(fā)編程，程序能夠并行地執(zhí)行程序中的多個部分。

1 定義任務

線程可以驅動任務，因此你需要一種描述任務的方式，這可以由Runnable接口來提供。要想定義任務，只需實現(xiàn)Runnable接口并編寫run()方法，使得該任務可以執(zhí)行你的命令。 
當從Runnable導出一個類時，它必須具有run()方法，但是這個方法并無特殊之處——它不會產生任何內在的線程能力。要實現(xiàn)線程行為，你必須顯式地將一個任務附著到線程上。

2 使用Executor

FixedThreadPool 與 CachedThreadPool

FixedThreadPool, 可以一次性預先執(zhí)行代價高昂的線程分配，因而也就可以限制線程的數(shù)量了。這可以節(jié)省時間，因為你不用為每個任務都固定地付出創(chuàng)建線程的開銷。在事件驅動的系統(tǒng)中，需要線程的事件處理器，通過直接從池中獲取線程，也可以如你所愿地得到服務。你不會濫用可獲得的資源，因為FixedThreadPool使用的Thread對象的數(shù)量是有界的。

注意，在任何線程池中，現(xiàn)有線程在可能的情況下，都會被自動復用。

盡管本書將使用CachedThreadPool，但是也應該考慮在產生線程的代碼中使用FiexedThreadPool。CachedThreadPool在程序執(zhí)行過程中通常會創(chuàng)建與所需數(shù)量相同的線程，然后在它回收舊線程時停止創(chuàng)建新線程，因此它是合理的Executor的首選。只有當這種方式會引發(fā)問題時，你才需要切換到FixedThreadPool。

SingleThreadExecutor就像是線程數(shù)量為1的FixedThreadPool。（它還提供了一種重要的并發(fā)保證，其他線程不會（即沒有兩個線程會）被調用。這會改變任務的加鎖需求） 
如果向SingleThreadExecutor提交了多個任務，那么這些任務將排隊，每個任務都會在下一個任務開始之前運行結束，所有的任務將使用相同的線程。在下面的示例中，你可以看到每個任務都是按照它們被提交的順序，并且是在下一個任務開始之前完成的。因此，SingleThreadExecutor會序列化所有提交給它的任務，并會維護它自己（隱藏）的懸掛任務隊列。

3 從任務中產生返回值

Runnable是執(zhí)行工作的獨立任務，但是它不返回任務值。如果你希望任務在完成時能夠返回一個值，那么可以實現(xiàn)Callable接口而不是Runnable接口。在Java SE5中引入的Callable是一種具有類型參數(shù)的泛型，它的類型參數(shù)表示的是從方法call()（而不是run()）中返回的值，并且必須使用ExecutorService.submit()方法調用它。

4 編碼的變體

另一種可能會看到的慣用法是自管理的Runnable。

這與從Thread繼承并沒有什么特別的差異，只是語法稍微晦澀一些。但是，實現(xiàn)接口使得你可以繼承另一個不同的類，而從Thread繼承將不行。

注意，自管理的Runnable是在構造器中調用的。這個示例相當簡單，因此可能是安全的，但是你應該意識到，在構造器中啟動線程可能會變得很有問題，因為另一個任務可能會在構造器結束之前開始執(zhí)行，這意味著該任務能夠訪問處于不穩(wěn)定狀態(tài)的對象。這是優(yōu)選Executor而不是顯式地創(chuàng)建Thread對象的另一個原因。

5 線程組

線程組持有一個線程集合。線程組的價值可以引用Joshua Bloch的話來總結：“最好把線程組看成是一次不成功的嘗試，你只要忽略它就好了?！?/p>

 如果你花費了大量的時間和精力試圖發(fā)現(xiàn)線程組的價值（就像我一樣），那么你可能會驚異，為什么沒有來自Sun的關于這個主題的官方聲明，多年以來，相同的問題對于Java發(fā)生的其他變化也詢問過無數(shù)遍。諾貝爾經濟學將得主Joseph Stiglitz的生活哲學可以用來解釋這個問題，它被稱為承諾升級理論（The Theory of Escalating Commitment）：“繼續(xù)錯誤的代價由別人來承擔，而承認錯誤的代價由自己承擔。”

6 捕獲異常

由于線程的本質特性，使得你不能捕獲從線程中逃逸的異常。一旦異常逃出任務的run()方法，它就會向外傳播到控制臺，除非你采取特殊的步驟捕獲這種錯誤的異常。

7 共享受限資源

可以把單線程程序當作在問題域求解的單一實體，每次只能做一件事情。

8 不正確地訪問資源

因為canceled標志是boolean類型的，所以它是原子性的，即諸如賦值和返回值這樣的簡單操作在發(fā)生時沒有中斷的可能，因此你不會看到這個域處于在執(zhí)行這些簡單操作的過程中的中間狀態(tài)。

有一點很重要，那就是要注意到遞增程序自身也需要多個步驟，并且在遞增過程中任務可能會被純種機制掛起——也就是說，在Java中，遞增不是原子性的操作。因此，如果不保護任務，即使單一的遞增也不是安全的。

9 終結任務
中斷

Executor上調用shutdownNow()，它將發(fā)送一個interrupt()調用給它啟動的所有線程。

Executor 通過調用submit()而不是excutor()來啟動任務，就可以持有該任務的上下文。submit()將返回一個泛型的Future<?>，持有這種Future的關鍵在于你可以在其上調用cancel()，并因此可以使用它來中斷某個特定任務。如果你將true傳遞給cancel()，那么它就會擁有在該線程上調用interrupt()以停止這個線程的權限。因此，cancel()是一個種中斷由Excutor啟動的單個線程的方式。

SleepBlock()是可中斷的阻塞，而IOBlocked和SynchronizedBlocked是不可中斷的阻塞。上面三個類的示例證明I/O和在synchronized塊上的等待是不可中斷的。無論是I/O還是嘗試調用synchronized方法，都不需要任何InterruptedException處理器。 
從關于上面三個類的示例的輸出中可以看到，你能夠中斷對sleep()的調用（或者任何要求拋出InterruptedException的調用）。但是，你不能中斷試圖獲取synchronized鎖或者試圖執(zhí)行I/O操作的線程。這有點令人煩惱，特別是在妊I/O的任務時，因為這意味著IO具有鎖住你的多線程程序的潛在可能。特別是對于基于Web的程序，這更是關乎利害。

對于這類問題，有一個略顯笨拙但是有時確實行之有效的解決方案，即關閉任務在其上發(fā)生阻塞的底層資源：

10 線程之間的協(xié)作
wait()與notifyAll()

wait()使你可以等待某個條件發(fā)生變化，而改變這個條件超出了當前方法的控制能力。通常，這種條件將由另一個任務來改變。你肯定不想在你的任務測試這個條件的同時，不斷地進行空循環(huán)，這被稱為忙等待， 通常是一種不良的周期使用方式。因此wait()會在等等外部世界產生變化的時候將任務掛起，并且只有在notify()或notifyAll() 發(fā)生時，即表示發(fā)生了某些感興趣的事物，這個任務才會被喚醒并去檢查所產生的變化。因此，wait()提供了一種在任務之間對活動同步的方式。

調用sleep()的時候鎖并沒有被 釋放，調用yield()也屬于這種情況，理解這一點很重要。 
wait(), notify()以及notifyAll()有一個比較特殊的方面，那就是這些方法是基類Object的一個部分，而不是屬于Thread的一部分。

錯失的信號。

notify() 與 notifyAll()

在有關Java的線程機制的討論中，有一個令人困惑的描述： notifyAll()將喚醒“所有下在等等的任務”。這是否意味著在程序中任何地方，任何處于wait()狀態(tài)中的任務都將被任何對notifyAll()的調用喚醒呢？有示例說明情況并非如此——事實上，當notifyAll()因某個特定鎖而被調用時，只有等待這個鎖的任務才會被喚醒。

11  死鎖

由Edsger Dijkstrar提出的哲學家就餐問題是一個經典的死鎖例證。

要修正死鎖問題，你必須明白，當以下四個條件同時滿足時，就會發(fā)生死鎖：

互斥條件。任務使用的資源中至少有一個是不能共享的。這里，一根Chopstick一次就只能被一個Philosopher使用。

至少有一個任務它必須持有一個資源且正在等待獲取一個當前被別的任務持有的資源。也就是說，要發(fā)生死鎖，Philosopher必須拿著一根Chopstick并且等待另一根。

資源不能被任務搶占，任務必須把資源釋放當作普通事件。Philosopher很有禮貌，他們不會從其他Philosopher那里搶占Chopstick。

必須有循環(huán)等待，這時，一個任務等待其他任務所持有的資源，后者又在等待另一個任務所持有的漿，這樣一直下去，直到有一個任務在等待第一個任務所持有的資源，使得大家都被鎖住。在DeadlockingDiningPhilosophers.java中，因為每個Philosopher都試圖先得到右邊的Chopstick,然后得到左邊的Chopstick，所以發(fā)徨了循環(huán)等待。
所以要防止死鎖的話，只需破壞其中一個即可。防止死鎖最容易的方法是破壞第4個條件。

12 新類庫中的構件
 CountDownLatch

適用場景：它被用來同步一個或多個任務，強制它們等待由其他任務執(zhí)行的一組操作完成。即一個或多個任務需要等待，等待到其它任務，比如一個問題的初始部分，完成為止。

你可以向CountDownLatch對象設置一個初始值，任何在這個對象上調用wait()的方法都將阻塞，直到這個計數(shù)值到達0.其他因結束其工作時，可以在訪對象上調用countDown()來減小這個計數(shù)值。CountDownLatch被設計為只解發(fā)一次，計數(shù)值不能被重置。如果你需要能夠重置計數(shù)值的版本，則可以使用CyclicBarrier。

調用countDown()的任務在產生這個調用時并沒有被阻塞，只有對await()的調用會被阻塞，直至計數(shù)值到達0。

CountDownLatch的典型用法是將一個程序分為n個互相獨立的可解決任務，并創(chuàng)建值為n的CountDownLatch。當每個任務完成時，都會在這個鎖存器上調用countDown()。等待問題被解決的任務在這個鎖存器上調用await()，將它們自己掛起，直至鎖存器計數(shù)結束。

13 CyclicBarrier

適用于這樣的情況：你希望創(chuàng)建一組任務，它們并行地執(zhí)行工作，然后在進行下一下步驟之前等待，直至所有任務都完成（看起來有些像Join()）。它使得所有的并行任務都將在柵欄處列隊，因此可以一致地向前移動。

例如程序賽馬程序：HorseRace.java

14 DelayQueue

DelayQueue是一個無界的BlockingQueue（同步隊列），用于放置實現(xiàn)了Delayed接口的對象，其中的對象只能在其到期時才能從隊列中取走。這種隊列是有序的，即隊頭對象是最先到期的對象。如果沒有到期的對象，那么隊列就沒有頭元素，所以poll()將返回null(也正因為此，我們不能將null放置到這種隊列中)。如上所述，DelayQueue就成為了優(yōu)先級隊列的一種變體。

15 PriorityBlockingQueue

這是一個很基礎的優(yōu)先級隊列，它具有可阻塞的讀取操作。這種隊列的阻塞特性提供了所有必需的同步，所以你應該注意到了，這里不需要任何顯式的同步——不必考慮當你從這種隊列中讀取時，其中是否有元素，因為這個隊列在沒有元素時，將直接阻塞讀取者。

16 使用ScheduledExecutor的室溫控制器

“溫室控制系統(tǒng)”可以被看作是一種并發(fā)問題，每個期望的溫室事件都是一個預定時間運行的任務。 
ScheduledThreadPoolExecutor可以解決這種問題。其中schedule()用來運行一次任務，scheduleAtFixedRate()每隔規(guī)定的時間重復執(zhí)行任務。兩個方法接收delayTime參數(shù)?？梢詫unnable對象設置為在將來的某個時刻執(zhí)行。

17 Semaphre

BlockingQueue: 同步隊列，當?shù)谝粋€元素為空或不可用時，執(zhí)行.take()時，等待（阻塞、Blocking）。

SynchronousQueue: 是一種沒有內部容量的阻塞隊列，因此每個put()都必須等待一個take()，反之亦然（即每個take()都必須等待一個put()）。這就好像你在把一個對象交給某人——沒有任何桌子可以放置這個對象，因此只有在這個人伸出手，準備好接收這個對象時，你才能工作。在本例中，SynchronousQueue表示設置在用餐者面前的某個位置，以加強在任何時刻只能上一道菜這個概念。

關于這個示例，需要觀察的一項非常重要的事項，就是使用隊列在任務間通信所帶來的管理復雜度。這個單項技術通過反轉控制極大地簡化了并發(fā)編程的過程：任務沒有直接地互相干涉，而是經由隊列互相發(fā)送對象。接收任務將處理對象，將其當作一個消息來對待，而不是向它發(fā)送消息。如果只要可能就遵循這項技術，那么你構建出健壯的并發(fā)系統(tǒng)的可能性就會大大增加。

18 分發(fā)工作
性能調優(yōu)（Performance Tuning） 比較各類互斥技術（Comparing mutex technologies）

“微基準測試（microbenchmarking）”危險：這個術語通常指在隔離的、脫離上下文環(huán)境的情況下對某個特性進行性能測試。當然，你仍舊必須編寫測試來驗證諸如“Lock比synchronized更快”這樣的斷言，但是你需要在編寫這些測試的進修意識到，在編譯過程中和在運行時實際會發(fā)生什么。

不同的編譯器和運行時系統(tǒng)在這方面會有所差異，因此很難確切了解將會發(fā)生什么，但是我們需要防止編譯器去預測結果的可能性。

使用Lock通常會比使用synchronized要高效許多，而且synchronized的開銷看起來變化范圍太大，而Lock相對比較一致。 
這是否意味著你永遠都不應該使用synchronized關鍵字呢？這里有兩個因素需要考慮：
一是互斥方法的方法體的大小。

二是synchronized關鍵字所產生的代碼與Lock所需的“加鎖-try/finally-解鎖”慣用法所產生的代碼相比，可讀性提高了很多。

代碼被閱讀的次數(shù)遠多于被編寫的次數(shù)。在編程時，與其他人交流相對于與計算機交流而言，要重要得多，因此代碼的可讀性至關重要。因此，以synchronized關鍵字入手，只有在性能調優(yōu)時才替換為Lock對象這種做法，是具有實際意義的。

19 免鎖容器（Lock-free containers）

這些免鎖窗口的通用策略是：對容器的修改可以與讀取操作同時發(fā)生，只要讀取者只能看到完成修改的結果婀。修改是在容器數(shù)據結構的某個部分的一個單獨的副本（有時是整個數(shù)據結構的副本）上執(zhí)行的，并且這個副本在修改過程中是不可視的。只有當修改完成時，被修改的結構都會自動地與主數(shù)據結構進行交換，之后讀取者就可以看到這個修改了。

樂觀鎖

只要你主要是從免鎖容器中讀取，那么它就會比其synchronized對應物快許多，因為獲取和釋放鎖的開銷被省掉了。如果需要向免鎖容器中執(zhí)行少量寫入，那么情況仍舊如此，但是什么算“少量”？這是一個很有意思的問題。

20 總結

線程的一個額外好處是它們提供了輕量級的執(zhí)行上下文切換（大約100條指令），而不是重量級的進程上下文切換（要上千條指令）。因為一個給定進程內的所有線程共享相同的內存空間，輕量級的上下文切換只是改變了程序的執(zhí)行序列和局部變量。進程切換（重量級的上下文切換）必須改變所有內存空間。

本文版權歸黑馬程序員JavaEE學院所有，歡迎轉載，轉載請注明作者出處。謝謝！

作者：黑馬程序員JavaEE培訓學院

首發(fā)：http://java.itheima.com/