多線程和並發性並不是什麽新內容，但是 Java 語言設計中的創新之一就是，它是第一個直接把跨平臺線程模型和正規的內存模型集成到語言中的主流語言。核心類庫包含一個 Thread 類，可以用它來構建、啟動和操縱線程，Java 語言包括了跨線程傳達並發性約束的構造 —— synchronized 和 volatile 。在簡化與平臺無關的並發類的開發的同時，它決沒有使並發類的編寫工作變得更繁瑣，只是使它變得更容易了。

synchronized 快速回顧

把代碼塊聲明為 synchronized，有兩個重要後果，通常是指該代碼具有 原子性（atomicity）和 可見性（visibility）。原子性意味著一個線程一次只能執行由一個指定監控對象（lock）保護的代碼，從而防止多個線程在更新共享狀態時相互沖突。可見性則更為微妙；它要對付內存緩存和編譯器優化的各種反常行為。一般來說，線程以某種不必讓其他線程立即可以看到的方式（不管這些線程在寄存器中、在處理器特定的緩存中，還是通過指令重排或者其他編譯器優化），不受緩存變量值的約束，但是如果開發人員使用了同步，如下面的代碼所示，那麽運行庫將確保某一線程對變量所做的更新先於對現有synchronized

1. synchronized (lockObject) {
2. // update object state
3. }

所以，實現同步操作需要考慮安全更新多個共享變量所需的一切，不能有爭用條件，不能破壞數據（假設同步的邊界位置正確），而且要保證正確同步的其他線程可以看到這些變量的最新值。通過定義一個清晰的、跨平臺的內存模型（該模型在 JDK 5.0 中做了修改，改正了原來定義中的某些錯誤），通過遵守下面這個簡單規則，構建“一次編寫，隨處運行”的並發類是有可能的：

不論什麽時候，只要您將編寫的變量接下來可能被另一個線程讀取，或者您將讀取的變量最後是被另一個線程寫入的，那麽您必須進行同步。

不過現在好了一點，在最近的 JVM 中，沒有爭用的同步（一個線程擁有鎖的時候，沒有其他線程企圖獲得鎖）的性能成本還是很低的。（也不總是這樣；早期 JVM 中的同步還沒有優化，所以讓很多人都這樣認為，但是現在這變成了一種誤解，人們認為不管是不是爭用，同步都有很高的性能成本。）

對 synchronized 的改進

如此看來同步相當好了，是麽？那麽為什麽 JSR 166 小組花了這麽多時間來開發 java.util.concurrent.lock 框架呢？答案很簡單－同步是不錯，但它並不完美。它有一些功能性的限制 —— 它無法中斷一個正在等候獲得鎖的線程，也無法通過投票得到鎖，如果不想等下去，也就沒法得到鎖。同步還要求鎖的釋放只能在與獲得鎖所在的堆棧幀相同的堆棧幀中進行，多數情況下，這沒問題（而且與異常處理交互得很好），但是，確實存在一些非塊結構的鎖定更合適的情況。

ReentrantLock 類

java.util.concurrent.lock 中的 Lock 框架是鎖定的一個抽象，它允許把鎖定的實現作為 Java 類，而不是作為語言的特性來實現。這就為 Lock 的多種實現留下了空間，各種實現可能有不同的調度算法、性能特性或者鎖定語義。 ReentrantLock 類實現了 Lock ，它擁有與 synchronized 相同的並發性和內存語義，但是添加了類似鎖投票、定時鎖等候和可中斷鎖等候的一些特性。此外，它還提供了在激烈爭用情況下更佳的性能。（換句話說，當許多線程都想訪問共享資源時，JVM 可以花更少的時候來調度線程，把更多時間用在執行線程上。）

reentrant 鎖意味著什麽呢？簡單來說，它有一個與鎖相關的獲取計數器，如果擁有鎖的某個線程再次得到鎖，那麽獲取計數器就加1，然後鎖需要被釋放兩次才能獲得真正釋放。這模仿了 synchronized 的語義；如果線程進入由線程已經擁有的監控器保護的 synchronized 塊，就允許線程繼續進行，當線程退出第二個（或者後續） synchronized 塊的時候，不釋放鎖，只有線程退出它進入的監控器保護的第一個 synchronized 塊時，才釋放鎖。

在查看清單 1 中的代碼示例時，可以看到 Lock 和 synchronized 有一點明顯的區別 —— lock 必須在 finally 塊中釋放。否則，如果受保護的代碼將拋出異常，鎖就有可能永遠得不到釋放！這一點區別看起來可能沒什麽，但是實際上，它極為重要。忘記在 finally 塊中釋放鎖，可能會在程序中留下一個定時炸彈，當有一天炸彈爆炸時，您要花費很大力氣才有找到源頭在哪。而使用同步，JVM 將確保鎖會獲得自動釋放。

清單 1. 用 ReentrantLock 保護代碼塊。

1. Lock lock = new ReentrantLock();
2. lock.lock();
3. try {
4. // update object state
5. }
6. finally {
7. lock.unlock();
8. }

除此之外，與目前的 synchronized 實現相比，爭用下的 ReentrantLock 實現更具可伸縮性。（在未來的 JVM 版本中，synchronized 的爭用性能很有可能會獲得提高。）這意味著當許多線程都在爭用同一個鎖時，使用 ReentrantLock 的總體開支通常要比 synchronized 少得多。

比較 ReentrantLock 和 synchronized 的可伸縮性

Tim Peierls 用一個簡單的線性全等偽隨機數生成器（PRNG）構建了一個簡單的評測，用它來測量 synchronized 和 Lock 之間相對的可伸縮性。這個示例很好，因為每次調用 nextRandom() 時，PRNG 都確實在做一些工作，所以這個基準程序實際上是在測量一個合理的、真實的 synchronized 和 Lock 應用程序，而不是測試純粹紙上談兵或者什麽也不做的代碼（就像許多所謂的基準程序一樣。）

在這個基準程序中，有一個 PseudoRandom 的接口，它只有一個方法 nextRandom(int bound) 。該接口與 java.util.Random 類的功能非常類似。因為在生成下一個隨機數時，PRNG 用最新生成的數字作為輸入，而且把最後生成的數字作為一個實例變量來維護，其重點在於讓更新這個狀態的代碼段不被其他線程搶占，所以我要用某種形式的鎖定來確保這一點。（ java.util.Random 類也可以做到這點。）我們為 PseudoRandom 構建了兩個實現；一個使用 syncronized，另一個使用 java.util.concurrent.ReentrantLock 。驅動程序生成了大量線程，每個線程都瘋狂地爭奪時間片，然後計算不同版本每秒能執行多少輪。圖 1 和 圖 2 總結了不同線程數量的結果。這個評測並不完美，而且只在兩個系統上運行了（一個是雙 Xeon 運行超線程 Linux，另一個是單處理器 Windows 系統），但是，應當足以表現 synchronized 與 ReentrantLock 相比所具有的伸縮性優勢了。

圖 1 和圖 2 中的圖表以每秒調用數為單位顯示了吞吐率，把不同的實現調整到 1 線程 synchronized 的情況。每個實現都相對迅速地集中在某個穩定狀態的吞吐率上，該狀態通常要求處理器得到充分利用，把大多數的處理器時間都花在處理實際工作（計算機隨機數）上，只有小部分時間花在了線程調度開支上。您會註意到，synchronized 版本在處理任何類型的爭用時，表現都相當差，而 Lock 版本在調度的開支上花的時間相當少，從而為更高的吞吐率留下空間，實現了更有效的 CPU 利用。

條件變量

根類 Object 包含某些特殊的方法，用來在線程的 wait() 、 notify() 和 notifyAll() 之間進行通信。這些是高級的並發性特性，許多開發人員從來沒有用過它們 —— 這可能是件好事，因為它們相當微妙，很容易使用不當。幸運的是，隨著 JDK 5.0 中引入 java.util.concurrent ，開發人員幾乎更加沒有什麽地方需要使用這些方法了。

通知與鎖定之間有一個交互 —— 為了在對象上 wait 或 notify ，您必須持有該對象的鎖。就像 Lock 是同步的概括一樣， Lock 框架包含了對 wait 和 notify 的概括，這個概括叫作 條件（Condition） 。 Lock 對象則充當綁定到這個鎖的條件變量的工廠對象，與標準的 wait 和 notify 方法不同，對於指定的 Lock ，可以有不止一個條件變量與它關聯。這樣就簡化了許多並發算法的開發。例如， 條件（Condition） 的 Javadoc 顯示了一個有界緩沖區實現的示例，該示例使用了兩個條件變量，“not full”和“not empty”，它比每個 lock 只用一個 wait 設置的實現方式可讀性要好一些（而且更有效）。 Condition 的方法與 wait 、 notify 和 notifyAll 方法類似，分別命名為 await 、 signal 和 signalAll ，因為它們不能覆蓋 Object 上的對應方法。

這不公平

如果查看 Javadoc，您會看到， ReentrantLock 構造器的一個參數是 boolean 值，它允許您選擇想要一個 公平（fair）鎖，還是一個 不公平（unfair）鎖。公平鎖使線程按照請求鎖的順序依次獲得鎖；而不公平鎖則允許討價還價，在這種情況下，線程有時可以比先請求鎖的其他線程先得到鎖。

為什麽我們不讓所有的鎖都公平呢？畢竟，公平是好事，不公平是不好的，不是嗎？（當孩子們想要一個決定時，總會叫嚷“這不公平”。我們認為公平非常重要，孩子們也知道。）在現實中，公平保證了鎖是非常健壯的鎖，有很大的性能成本。要確保公平所需要的記帳（bookkeeping）和同步，就意味著被爭奪的公平鎖要比不公平鎖的吞吐率更低。作為默認設置，應當把公平設置為 false ，除非公平對您的算法至關重要，需要嚴格按照線程排隊的順序對其進行服務。

那麽同步又如何呢？內置的監控器鎖是公平的嗎？答案令許多人感到大吃一驚，它們是不公平的，而且永遠都是不公平的。但是沒有人抱怨過線程饑渴，因為 JVM 保證了所有線程最終都會得到它們所等候的鎖。確保統計上的公平性，對多數情況來說，這就已經足夠了，而這花費的成本則要比絕對的公平保證的低得多。所以，默認情況下 ReentrantLock 是“不公平”的，這一事實只是把同步中一直是事件的東西表面化而已。如果您在同步的時候並不介意這一點，那麽在 ReentrantLock 時也不必為它擔心。

圖 3 和圖 4 包含與 圖 1和 圖 2 相同的數據，只是添加了一個數據集，用來進行隨機數基準檢測，這次檢測使用了公平鎖，而不是默認的協商鎖。正如您能看到的，公平是有代價的。如果您需要公平，就必須付出代價，但是請不要把它作為您的默認選擇。

處處都好？

看起來 ReentrantLock 無論在哪方面都比 synchronized 好 —— 所有 synchronized 能做的，它都能做，它擁有與 synchronized 相同的內存和並發性語義，還擁有 synchronized 所沒有的特性，在負荷下還擁有更好的性能。那麽，我們是不是應當忘記 synchronized ，不再把它當作已經已經得到優化的好主意呢？或者甚至用 ReentrantLock 重寫我們現有的 synchronized 代碼？實際上，幾本 Java 編程方面介紹性的書籍在它們多線程的章節中就采用了這種方法，完全用 Lock 來做示例，只把 synchronized 當作歷史。但我覺得這是把好事做得太過了。

還不要拋棄 synchronized

雖然 ReentrantLock 是個非常動人的實現，相對 synchronized 來說，它有一些重要的優勢，但是我認為急於把 synchronized 視若敝屣，絕對是個嚴重的錯誤。 java.util.concurrent.lock 中的鎖定類是用於高級用戶和高級情況的工具 。一般來說，除非您對 Lock 的某個高級特性有明確的需要，或者有明確的證據（而不是僅僅是懷疑）表明在特定情況下，同步已經成為可伸縮性的瓶頸，否則還是應當繼續使用 synchronized。

為什麽我在一個顯然“更好的”實現的使用上主張保守呢？因為對於 java.util.concurrent.lock 中的鎖定類來說，synchronized 仍然有一些優勢。比如，在使用 synchronized 的時候，不能忘記釋放鎖；在退出 synchronized 塊時，JVM 會為您做這件事。您很容易忘記用 finally 塊釋放鎖，這對程序非常有害。您的程序能夠通過測試，但會在實際工作中出現死鎖，那時會很難指出原因（這也是為什麽根本不讓初級開發人員使用 Lock 的一個好理由。）

另一個原因是因為，當 JVM 用 synchronized 管理鎖定請求和釋放時，JVM 在生成線程轉儲時能夠包括鎖定信息。這些對調試非常有價值，因為它們能標識死鎖或者其他異常行為的來源。 Lock 類只是普通的類，JVM 不知道具體哪個線程擁有 Lock 對象。而且，幾乎每個開發人員都熟悉 synchronized，它可以在 JVM 的所有版本中工作。在 JDK 5.0 成為標準（從現在開始可能需要兩年）之前，使用 Lock 類將意味著要利用的特性不是每個 JVM 都有的，而且不是每個開發人員都熟悉的。

什麽時候選擇用 ReentrantLock 代替 synchronized

既然如此，我們什麽時候才應該使用 ReentrantLock 呢？答案非常簡單 —— 在確實需要一些 synchronized 所沒有的特性的時候，比如時間鎖等候、可中斷鎖等候、無塊結構鎖、多個條件變量或者鎖投票。 ReentrantLock 還具有可伸縮性的好處，應當在高度爭用的情況下使用它，但是請記住，大多數 synchronized 塊幾乎從來沒有出現過爭用，所以可以把高度爭用放在一邊。我建議用 synchronized 開發，直到確實證明 synchronized 不合適，而不要僅僅是假設如果使用 ReentrantLock “性能會更好”。請記住，這些是供高級用戶使用的高級工具。（而且，真正的高級用戶喜歡選擇能夠找到的最簡單工具，直到他們認為簡單的工具不適用為止。）。一如既往，首先要把事情做好，然後再考慮是不是有必要做得更快。

Lock 框架是同步的兼容替代品，它提供了 synchronized 沒有提供的許多特性，它的實現在爭用下提供了更好的性能。但是，這些明顯存在的好處，還不足以成為用 ReentrantLock 代替 synchronized 的理由。相反，應當根據您是否 需要 ReentrantLock 的能力來作出選擇。大多數情況下，您不應當選擇它 —— synchronized 工作得很好，可以在所有 JVM 上工作，更多的開發人員了解它，而且不太容易出錯。只有在真正需要 Lock 的時候才用它。在這些情況下，您會很高興擁有這款工具。

volatile與Atomic原子性包裝

什麽是原子操作？
所謂原子操作,就是"不可中斷的一個或一系列操作" , 在確認一個操作是原子的情況下，多線程環境裏面，我們可以避免僅僅為保護這個操作在外圍加上性能昂貴的鎖，甚至借助於原子操作，我們可以實現互斥鎖。 很多操作系統都為int類型提供了+-賦值的原子操作版本，比如 NT 提供了 InterlockedExchange 等API， Linux/UNIX也提供了atomic_set 等函數。

關於Java中的原子性？
原子性可以應用於除long和double之外的所有基本類型之上的“簡單操作”。對於讀取和寫入出long double之外的基本類型變量這樣的操作，可以保證它們會被當作不可分（原子）的操作來操作。 因為JVM的版本和其它的問題，其它的很多操作就不好說了，比如說++操作在C++中是原子操作，但在Java中就不好說了。 另外，Java提供了AtomicInteger等原子類。再就是用原子性來控制並發比較麻煩，也容易出問題。

volatile原理是什麽?
Java中volatile關鍵字原義是“不穩定、變化”的意思
使用volatile和不使用volatile的區別在於JVM內存主存和線程工作內存的同步之上。volatile保證變量在線程工作內存和主存之間一致。
其實是告訴處理器, 不要將我放入工作內存, 請直接在主存操作我.

接下來是測試 ：(通過測試能更好的發現和分析問題)
申明了幾種整形的變量，開啟100個線程同時對這些變量進行++操作，發現結果差異很大：
>>Execute End:
>>Atomic: 100000
>>VInteger: 38790
>>Integer: 68749
>>Source i: 99205
>>Source Vi: 99286
也就是說除了Atomic，其他的都是錯誤的。

我們通過一些疑問，來解釋一下。

1：為什麽會產生錯誤的數據？
多線程引起的，因為對於多線程同時操作一個整型變量在大並發操作的情況下無法做到同步，而Atom提供了很多針對此類線程安全問題的解決方案，因此解決了同時讀寫操作的問題。

2：為什麽會造成同步問題？
Java多線程在對變量進行操作的時候，實際上是每個線程會單獨分配一個針對i值的拷貝(獨立內存區域)，但是申明的i值確是在主內存區域中，當對i值修改完畢後，線程會將自己內存區域塊中的i值拷貝到主內存區域中，因此有可能每個線程拿到的i值是不一樣的，從而出現了同步問題。

3：為什麽使用volatile修飾integer變量後，還是不行？
因為volatile僅僅只是解決了存儲的問題，即i值只是保留在了一個內存區域中，但是i++這個操作，涉及到獲取i值、修改i值、存儲i值(i=i+1)，這裏的volatile只是解決了存儲i值得問題，至於獲取和修改i值，確是沒有做到同步。

4：既然不能做到同步，那為什麽還要用volatile這種修飾符？
主要的一個原因是方便，因為只需添加一個修飾符即可，而無需做對象加鎖、解鎖這麽麻煩的操作。但是本人不推薦使用這種機制，因為比較容易出問題(臟數據)，而且也保證不了同步。

5：那到底如何解決這樣的問題？
第一種：采用同步synchronized解決，這樣雖然解決了問題，但是也降低了系統的性能。
第二種：采用原子性數據Atomic變量，這是從JDK1.5開始才存在的針對原子性的解決方案，這種方案也是目前比較好的解決方案了。

6：Atomic的實現基本原理？
首先Atomic中的變量是申明為了volatile變量的，這樣就保證的變量的存儲和讀取是一致的，都是來自同一個內存塊，然後Atomic提供了getAndIncrement方法，該方法對變量的++操作進行了封裝，並提供了compareAndSet方法，來完成對單個變量的加鎖和解鎖操作，方法中用到了一個UnSafe的對象，現在還不知道這個UnSafe的工作原理(似乎沒有公開源代碼)。Atomic雖然解決了同步的問題，但是性能上面還是會有所損失，不過影響不大，網上有針對這方面的測試，大概50million的操作對比是250ms : 850ms，對於大部分的高性能應用，應該還是夠的了。

Java中的synchronized、volatile、ReenTrantLock、AtomicXXX