java編程的總結與思考
編寫優質的并發代碼是一件難度極高的事情。Java語言從第一版本開始內置了對多線程的支持，這一點在當年是非常了不起的，但是當我們對并發編程有了更深刻的認識和更多的實踐后，實現并發編程就有了更多的方案和更好的選擇。本文是對并發編程的一點總結和思考，
為什么需要并發
并發其實是一種解耦合的策略，它幫助我們把做什么(目標)和什么時候做(時機)分開。這樣做可以明顯改進應用程序的吞吐量(獲得更多的CPU調度時間)和結構(程序有多個部分在協同工作)。做過Java Web開發的人都知道，Java Web中的Servlet程序在Servlet容器的支持下采用單實例多線程的工作模式，Servlet容器幫助你處理了并發請求的問題。
誤解和正解
最常見的對并發編程的誤解有以下這些：
A. 并發總能改進性能。(真相：并發在CPU有很多空閑時間時能明顯改進程序的性能，但當線程數量較多的時候，線程間頻繁的調度切換反而會讓系統的性能下降)
B. 編寫并發程序無需修改原有的設計。(真相：目的與時機的解耦往往會對系統結構產生巨大的影響)
C. 在使用Web或EJB容器時不用關注并發問題。(真相：只有了解了容器在做什么，才能更好的使用容器)
下面的這些說法才是對并發編程比較客觀的認識：
A. 編寫并發程序會在代碼上增加額外的開銷。
B. 正確的并發是非常復雜的，即使對于很簡單的問題。
C. 并發中的缺陷因為不易重現也不容易被發現。
D. 并發往往需要對設計策略從根本上進行修改。
并發編程的原則和技巧
1. 單一職責原則：分離并發相關代碼和其他代碼(并發相關代碼有自己的開發、修改和調優生命周期)。
2. 限制數據作用域：兩個線程修改共享對象的同一字段時可能會相互干擾，導致不可預期的行為，解決方案之一是構造臨界區，但是必須限制臨界區的數量。
3. 使用數據副本：數據副本是避免共享數據的好方法，復制出來的對象只是以只讀的方式對待。Java 5的java.util.concurrent包中增加一個名為CopyOnWriteArrayList的類，它是List接口的子類型，所以你可以認為它是ArrayList的線程安全的版本，它使用了寫時復制的方式創建數據副本進行操作來避免對共享數據并發訪問而引發的問題。
4. 線程應盡可能獨立：讓線程存在于自己的世界中，不與其他線程共享數據。有過Java Web開發經驗的人都知道，Servlet就是以單實例多線程的方式工作，和每個請求相關的數據都是通過Servlet子類的service方法(或者是doGet或doPost方法)的參數傳入的。只要Servlet中的代碼只使用局部變量，Servlet就不會導致同步問題。Spring MVC的控制器也是這么做的，從請求中獲得的對象都是以方法的參數傳入而不是作為類的成員，很明顯Struts 2的做法就正好相反，因此Struts 2中作為控制器的Action類都是每個請求對應一個實例。
下面的這些說法才是對并發客觀的認識：
-編寫并發程序會在代碼上增加額外的開銷 -正確的并發是非常復雜的，即使對于很簡單的問題 -并發中的缺陷因為不易重現也不容易被發現
-并發往往需要對設計策略從根本上進行修改并發編程的原則和技巧 單一職責原則 分離并發相關代碼和其他代碼(并發相關代碼有自己的開發、修改和調優生命周期)。限制數據作用域 兩個線程修改共享對象的同一字段時可能會相互干擾，導致不可預期的行為，解決方案之一是構造臨界區，但是必須限制臨界區的數量。使用數據副本 數據副本是避免共享數據的好方法，復制出來的對象只是以只讀的方式對待。
Java 5的java.util.concurrent包中增加一個名為CopyOnWriteArrayList的類，它是List接口的子類型，所以你可以認為它是ArrayList的線程安全的版本，它使用了寫時復制的方式創建數據副本進行操作來避免對共享數據并發訪問而引發的問題。線程應盡可能獨立 讓線程存在于自己的世界中，不與其他線程共享數據。有過Java Web開發經驗的人都知道，Servlet就是以單實例多線程的方式工作，和每個請求相關的數據都是通過Servlet子類的service方法(或者是doGet或doPost方法)的參數傳入的。只要Servlet中的代碼只使用局部變量，Servlet就不會導致同步問題。
springMVC的控制器也是這么做的，從請求中獲得的對象都是以方法的參數傳入而不是作為類的成員，很明顯Struts 2的做法就正好相反，因此Struts 2中作為控制器的Action類都是每個請求對應一個實例。 Java 5以前的并發編程 Java的線程模型建立在搶占式線程調度的基礎上，也就是說： 所有線程可以很容易的共享同一進程中的對象。能夠引用這些對象的任何線程都可以修改這些對象。為了保護數據，對象可以被鎖住。 Java基于線程和鎖的并發過于底層，而且使用鎖很多時候都是很萬惡的，因為它相當于讓所有的并發都變成了排隊等待。
在Java 5以前，可以用synchronized關鍵字來實現鎖的功能，它可以用在代碼塊和方法上，表示在執行整個代碼塊或方法之前線程必須取得合適的鎖。對于類的非靜態方法(成員方法)而言，這意味這要取得對象實例的鎖，對于類的靜態方法(類方法)而言，要取得類的Class對象的鎖，對于同步代碼塊，程序員可以指定要取得的是那個對象的鎖。 不管是同步代碼塊還是同步方法，每次只有一個線程可以進入，如果其他線程試圖進入(不管是同一同步塊還是不同的同步塊)，JVM會將它們掛起(放入到等鎖池中)。這種結構在并發理論中稱為臨界區(critical section)。
這里我們可以對Java中用synchronized實現同步和鎖的功能做一個總結： 只能鎖定對象，不能鎖定基本數據類型被鎖定的對象數組中的單個對象不會被鎖定同步方法可以視為包含整個方法的synchronized(this) { … }代碼塊靜態同步方法會鎖定它的Class對象內部類的同步是獨立于外部類的 synchronized修飾符并不是方法簽名的組成部分，所以不能出現在接口的方法聲明中非同步的方法不關心鎖的狀態，它們在同步方法運行時仍然可以得以運行 synchronized實現的鎖是可重入的鎖。在JVM內部，為了提高效率，同時運行的每個線程都會有它正在處理的數據的緩存副本，當我們使用synchronzied進行同步的時候，真正被同步的是在不同線程中表示被鎖定對象的內存塊(副本數據會保持和主內存的同步，現在知道為什么要用同步這個詞匯了吧)，簡單的說就是在同步塊或同步方法執行完后，對被鎖定的對象做的任何修改要在釋放鎖之前寫回到主內存中;在進入同步塊得到鎖之后，被鎖定對象的數據是從主內存中讀出來的，持有鎖的線程的數據副本一定和主內存中的數據視圖是同步的 。 在Java最初的版本中，就有一個叫Volatile的關鍵字，它是一種簡單的同步的處理機制，因為被volatile修飾的變量遵循以下規則： 變量的值在使用之前總會從主內存中再讀取出來。對變量值的修改總會在完成之后寫回到主內存中。使用volatile關鍵字可以在多線程環境下預防編譯器不正確的優化假設(編譯器可能會將在一個線程中值不會發生改變的變量優化成常量)，但只有修改時不依賴當前狀態(讀取時的值)的變量才應該聲明為volatile變量。
不變模式也是并發編程時可以考慮的一種設計。讓對象的狀態是不變的，如果希望修改對象的狀態，就會創建對象的副本并將改變寫入副本而不改變原來的對象，這樣就不會出現狀態不一致的情況，因此不變對象是線程安全的。Java中我們使用頻率極高的String類就采用了這樣的設計。如果對不變模式不熟悉，可以閱讀閻宏博士的《Java與模式》一書的第34章。說到這里你可能也體會到final關鍵字的重要意義了。 Java 5的并發編程 不管今后的Java向著何種方向發展或者滅亡，Java 5絕對是Java發展史中一個極其重要的版本，這個版本提供的各種語言特性我們不在這里討論(有興趣的可以閱讀我的另一篇文章《Java的第20年：從Java版本演進看編程技術的發展》)，但是我們必須要感謝Doug Lea在Java 5中提供了他里程碑式的杰作java.util.concurrent包，它的出現讓Java的并發編程有了更多的選擇和更好的工作方式。Doug Lea的杰作主要包括以下內容： 更好的線程安全的容器線程池和相關的工具類可選的非阻塞解決方案顯示的鎖和信號量機制下面我們對這些東西進行一一解讀。 原子類 Java 5中的java.util.concurrent包下面有一個atomic子包，其中有幾個以Atomic打頭的類，例如AtomicInteger和AtomicLong。
它們利用了現代處理器的特性，可以用非阻塞的方式完成原子操作，代碼如下所示： /** ID序列生成器 */ public class IdGenerator { private final AtomicLong sequenceNumber = new AtomicLong(0); public long next() { return sequenceNumber.getAndIncrement(); } } 顯示鎖 基于synchronized關鍵字的鎖機制有以下問題： 鎖只有一種類型，而且對所有同步操作都是一樣的作用鎖只能在代碼塊或方法開始的地方獲得，在結束的地方釋放線程要么得到鎖，要么阻塞，沒有其他的可能性 Java 5對鎖機制進行了重構，提供了顯示的鎖，這樣可以在以下幾個方面提升鎖機制： 可以添加不同類型的鎖，例如讀取鎖和寫入鎖可以在一個方法中加鎖，在另一個方法中解鎖可以使用tryLock方式嘗試獲得鎖，如果得不到鎖可以等待、回退或者干點別的事情，當然也可以在超時之后放棄操作顯示的鎖都實現了java.util.concurrent.Lock接口，主要有兩個實現類： ReentrantLock – 比synchronized稍微靈活一些的重入鎖 ReentrantReadWriteLock – 在讀操作很多寫操作很少時性能更好的一種重入鎖對于如何使用顯示鎖，只有一點需要提醒，解鎖的方法unlock的調用最好能夠在finally塊中，因為這里是釋放外部資源最好的地方，當然也是釋放鎖的最佳位置，因為不管正常異常可能都要釋放掉鎖來給其他線程以運行的機會。 CountDownLatch CountDownLatch是一種簡單的同步模式，它讓一個線程可以等待一個或多個線程完成它們的工作從而避免對臨界資源并發訪問所引發的各種問題。
下面借用別人的一段代碼(我對它做了一些重構)來演示CountDownLatch是如何工作的。 import java.util.concurrent.CountDownLatch; /** * 工人類 * @author 駱昊 * */ class Worker { private String name; // 名字 private long workDuration; // 工作持續時間 /** * 構造器 */ public Worker(String name, long workDuration) { this.name = name; this.workDuration = workDuration; } /** * 完成工作 */ public void doWork() { System.out.println(name + " begins to work..."); try { Thread.sleep(workDuration); // 用休眠模擬工作執行的時間 } catch(InterruptedException ex) { ex.printStackTrace(); } System.out.println(name + " has finished the job..."); } } /** * 測試線程 * @author 駱昊 * */ class WorkerTestThread implements Runnable { private Worker worker; private CountDownLatch cdLatch; public WorkerTestThread(Worker worker, CountDownLatch cdLatch) { this.worker = worker; this.cdLatch = cdLatch; } ConcurrentHashMap ConcurrentHashMap是HashMap在并發環境下的版本，大家可能要問，既然已經可以通過Collections.synchronizedMap獲得線程安全的映射型容器，為什么還需要ConcurrentHashMap呢?因為通過Collections工具類獲得的線程安全的HashMap會在讀寫數據時對整個容器對象上鎖，這樣其他使用該容器的線程無論如何也無法再獲得該對象的鎖，也就意味著要一直等待前一個獲得鎖的線程離開同步代碼塊之后才有機會執行。實際上，HashMap是通過哈希函數來確定存放鍵值對的桶(桶是為了解決哈希沖突而引入的)，修改HashMap時并不需要將整個容器鎖住，只需要鎖住即將修改的“桶”就可以了。HashMap的數據結構如下圖所示。
此外，ConcurrentHashMap還提供了原子操作的方法，如下所示： putIfAbsent：如果還沒有對應的鍵值對映射，就將其添加到HashMap中。 remove：如果鍵存在而且值與當前狀態相等(equals比較結果為true)，則用原子方式移除該鍵值對映射 replace：替換掉映射中元素的原子操作 CopyOnWriteArrayList CopyOnWriteArrayList是ArrayList在并發環境下的替代品。CopyOnWriteArrayList通過增加寫時復制語義來避免并發訪問引起的問題，也就是說任何修改操作都會在底層創建一個列表的副本，也就意味著之前已有的迭代器不會碰到意料之外的修改。這種方式對于不要嚴格讀寫同步的場景非常有用，因為它提供了更好的性能。記住，要盡量減少鎖的使用，因為那勢必帶來性能的下降(對數據庫中數據的并發訪問不也是如此嗎?如果可以的話就應該放棄悲觀鎖而使用樂觀鎖)，CopyOnWriteArrayList很明顯也是通過犧牲空間獲得了時間(在計算機的世界里，時間和空間通常是不可調和的矛盾，可以犧牲空間來提升效率獲得時間，當然也可以通過犧牲時間來減少對空間的使用)。 可以通過下面兩段代碼的運行狀況來驗證一下CopyOnWriteArrayList是不是線程安全的容器。 上面的代碼會在運行時產生ArrayIndexOutOfBoundsException，試一試將上面代碼25行的ArrayList換成CopyOnWriteArrayList再重新運行。 List list = new CopyOnWriteArrayList<>(); undefinedQueue 隊列是一個無處不在的美妙概念，它提供了一種簡單又可靠的方式將資源分發給處理單元(也可以說是將工作單元分配給待處理的資源，這取決于你看待問題的方式)。實現中的并發編程模型很多都依賴隊列來實現，因為它可以在線程之間傳遞工作單元。 Java 5中的BlockingQueue就是一個在并發環境下非常好用的工具，在調用put方法向隊列中插入元素時，如果隊列已滿，它會讓插入元素的線程等待隊列騰出空間;在調用take方法從隊列中取元素時，如果隊列為空，取出元素的線程就會阻塞。
可以用BlockingQueue來實現生產者-消費者并發模型(下一節中有介紹)，當然在Java 5以前也可以通過wait和notify來實現線程調度，比較一下兩種代碼就知道基于已有的并發工具類來重構并發代碼到底好在哪里了。 基于wait和notify的實現 使用BlockingQueue后代碼優雅了很多。 并發模型 在繼續下面的探討之前，我們還是重溫一下幾個概念： 概念 解釋臨界資源 并發環境中有著固定數量的資源互斥 對資源的訪問是排他式的饑餓 一個或一組線程長時間或永遠無法取得進展死鎖 兩個或多個線程相互等待對方結束活鎖 想要執行的線程總是發現其他的線程正在執行以至于長時間或永遠無法執行重溫了這幾個概念后，我們可以探討一下下面的幾種并發模型。 生產者-消費者 一個或多個生產者創建某些工作并將其置于緩沖區或隊列中，一個或多個消費者會從隊列中獲得這些工作并完成之。這里的緩沖區或隊列是臨界資源。當緩沖區或隊列放滿的時候，生產這會被阻塞;而緩沖區或隊列為空的時候，消費者會被阻塞。生產者和消費者的調度是通過二者相互交換信號完成的。 讀者-寫者 當存在一個主要為讀者提供信息的共享資源，它偶爾會被寫者更新，但是需要考慮系統的吞吐量，又要防止饑餓和陳舊資源得不到更新的問題。
在這種并發模型中，如何平衡讀者和寫者是最困難的，當然這個問題至今還是一個被熱議的問題，恐怕必須根據具體的場景來提供合適的解決方案而沒有那種放之四海而皆準的方法(不像我在國內的科研文獻中看到的那樣)。 哲學家進餐 1965年，荷蘭計算機科學家圖靈獎得主Edsger Wybe Dijkstra提出并解決了一個他稱之為哲學家進餐的同步問題。這個問題可以簡單地描述如下：五個哲學家圍坐在一張圓桌周圍，每個哲學家面前都有一盤通心粉。由于通心粉很滑，所以需要兩把叉子才能夾住。相鄰兩個盤子之間放有一把叉子如下圖所示。哲學家的生活中有兩種交替活動時段：即吃飯和思考。當一個哲學家覺得餓了時，他就試圖分兩次去取其左邊和右邊的叉子，每次拿一把，但不分次序。如果成功地得到了兩把叉子，就開始吃飯，吃完后放下叉子繼續思考。 把上面問題中的哲學家換成線程，把叉子換成競爭的臨界資源，上面的問題就是線程競爭資源的問題。如果沒有經過精心的設計，系統就會出現死鎖、活鎖、吞吐量下降等問題。 下面是用信號量原語來解決哲學家進餐問題的代碼，使用了Java 5并發工具包中的Semaphore類(代碼不夠漂亮但是已經足以說明問題了)。 //import java.util.concurrent.ExecutorService; //import java.util.concurrent.Executors; import java.util.concurrent.Semaphore; 現實中的并發問題基本上都是這三種模型或者是這三種模型的變體。 測試并發代碼 對并發代碼的測試也是非常棘手的事情，棘手到無需說明大家也很清楚的程度，所以這里我們只是探討一下如何解決這個棘手的問題。
我們建議大家編寫一些能夠發現問題的測試并經常性的在不同的配置和不同的負載下運行這些測試。不要忽略掉任何一次失敗的測試，線程代碼中的缺陷可能在上萬次測試中僅僅出現一次。具體來說有這么幾個注意事項： 不要將系統的失效歸結于偶發事件，就像拉不出屎的時候不能怪地球沒有引力。先讓非并發代碼工作起來，不要試圖同時找到并發和非并發代碼中的缺陷。編寫可以在不同配置環境下運行的線程代碼。編寫容易調整的線程代碼，這樣可以調整線程使性能達到最優。讓線程的數量多于CPU或CPU核心的數量，這樣CPU調度切換過程中潛在的問題才會暴露出來。
讓并發代碼在不同的平臺上運行。通過自動化或者硬編碼的方式向并發代碼中加入一些輔助測試的代碼。 Java 7的并發編程 Java 7中引入了TransferQueue，它比BlockingQueue多了一個叫transfer的方法，如果接收線程處于等待狀態，該操作可以馬上將任務交給它，否則就會阻塞直至取走該任務的線程出現。可以用TransferQueue代替BlockingQueue，因為它可以獲得更好的性能。 剛才忘記了一件事情，Java 5中還引入了Callable接口、Future接口和FutureTask接口，通過他們也可以構建并發應用程序，代碼如下所示。 Callable接口也是一個單方法接口，顯然這是一個回調方法，類似于函數式編程中的回調函數，在Java 8 以前，Java中還不能使用Lambda表達式來簡化這種函數式編程。和Runnable接口不同的是Callable接口的回調方法call方法會返回一個對象，這個對象可以用將來時的方式在線程執行結束的時候獲得信息。上面代碼中的call方法就是將計算出的10000個0到1之間的隨機小數的平均值返回，我們通過一個Future接口的對象得到了這個返回值。目前最新的Java版本中，Callable接口和Runnable接口都被打上了@FunctionalInterface的注解，也就是說它可以用函數式編程的方式(Lambda表達式)創建接口對象。 下面是Future接口的主要方法： get()：獲取結果。如果結果還沒有準備好，get方法會阻塞直到取得結果;當然也可以通過參數設置阻塞超時時間。 cancel()：在運算結束前取消。 isDone()：可以用來判斷運算是否結束。 Java 7中還提供了分支/合并(fork/join)框架，它可以實現線程池中任務的自動調度，并且這種調度對用戶來說是透明的。
為了達到這種效果，必須按照用戶指定的方式對任務進行分解，然后再將分解出的小型任務的執行結果合并成原來任務的執行結果。這顯然是運用了分治法(divide-and-conquer)的思想。下面的代碼使用了分支/合并框架來計算1到10000的和，當然對于如此簡單的任務根本不需要分支/合并框架，因為分支和合并本身也會帶來一定的開銷，但是這里我們只是探索一下在代碼中如何使用分支/合并框架，讓我們的代碼能夠充分利用現代多核CPU的強大運算能力。 伴隨著Java 7的到來，Java中默認的數組排序算法已經不再是經典的快速排序(雙樞軸快速排序)了，新的排序算法叫TimSort，它是歸并排序和插入排序的混合體，TimSort可以通過分支合并框架充分利用現代處理器的多核特性，從而獲得更好的性能(更短的排序時間)。
【java編程的總結與思考】相關文章：
java編程基礎07-26
java編程術語03-09
Java編程語言02-10
java教程之Java編程基礎04-18
java語法基本編程04-01
java編程語言分析07-11
Java語言編程簡介03-04
Java編程環境的搭建06-03
java面向接口編程08-01