前言

并發在大型項目中的應用很廣，可以有效提升應用性能，充分使用硬件資源。同時，也是Java面試的主要內容。

重排序

為了充分利用資源，減少中斷，JVM引入了重排序的概念，即：

• 編譯器優化重排序，編譯器在不改變單線程程序語義的前提下，可以重新安排語句的執行順序；
• 處理器指令級并行重排序，現代處理器采用了指令級并行技術將多條指令重疊執行，對于不存在數據依賴性的指令，處理器可以改變其執行順序；
• 內存系統的重排序，由于處理器使用緩存和讀/寫緩沖區，這使加載和存儲操作看上去可能是亂序執行的。

重排序可以提升程序的性能，但是，只能保證串行語句的一致性，不能保證多線程間語義的一致性。比如，指令重排序會導致多線程操作之間的不可見性，多線程下的重排序還會導致數據競爭問題，使有讀寫順序的操作重排，改變了原來的意義。

note*：數據競爭：不同線程間存在讀寫順序的操作，沒有通過同步排序，導致執行結果與預期不符，則成為發生了數據競爭。

happens-before

happens-before規則，是對操作執行結果的一種保證，常規情況下，也是對操作順序的一種保證。
happens-before 關系的定義:

• 如果一個操作 happens-before 另一個操作，那么第一個操作的執行結果就會對第二個操作可見；
• 兩個操作之間如果存在 happens-before 關系,并不意味著 Java 平臺的具體實現就必須按照 happens-before 關系指定的順序來執行。如果重排序之后的執行結果，與按照 happens-before 關系來執行的結果一直,那么 JMM 也允許這樣的重排序。

在 Java 中，對于happens-before 關系，有以下規定：

• 程序順序規則：一個線程中的每一個操作，happens-before于該線程中的任意后續操作
• 監視器鎖規則：對一個鎖的解鎖, happens-before于隨后對這個鎖的加鎖
• volatile變量規則：對一個 volatile 域的寫，happens-before與任意后續對這個volatile域的讀
• 傳遞性：如果 A happens-before B，且 B happens-before C ,那么A happens-before C
• start規則：如果線程A執行操作 ThreadB.start()啟動線程B，那么A線程的ThreadB.start()操作happens-before于線程B中的任意操作
• join規則：如果線程A執行操作ThreadB.join()并成功返回,那么線程B中的任意操作happens-before于線程A從 ThreadB.join()操作成功返回。

as-if-serial語義保證了單線程內重排序之后的執行結果和程序代碼本身應該出現的結果一致，happens-before 關系保證了正確同步的多線程程序的執行結果不會被重排序改變。

順序一致性與JMM模型

順序一致性內存模型是一個理想狀態下的理論參考模型,它為程序員提供了特別強的內存可見性保證,順序一致性模型有兩大特性:

• 一個線程中的所有操作必須按照程序的順序來執行(也就是按照寫的代碼的順序來執行)；
• 不管程序是否同步,所有線程都只能看到一個單一的操作執行順序。也就是說,在順序一致性模型中,每個操作必須是原子性的,而且立刻對所有線程都是可見的。

保證操作對所有線程可見這一點會導致JVM的性能降低，JVM為了程序的性能，引入了重排序的概念，但是出現了線程安全的問題，JMM(Java Memory Model)的出現可以幫助解決這個問題。JMM的約定如下：

• 同步的多線程，也就是臨界區內的操作，JMM允許重排序，但是不允許引入臨界區外的代碼，比如非同步的外部變量，這是同步鎖的前提。
• 未同步的多線程，提供最小安全性：線程讀取到的值,要么是之前某個線程寫入的值,要么是默認值,不會無中生有，涉及共享變量，容易導致線程安全問題。

在外部，Java為我們提供了volatile，final，synchronized，Lock等來實現多線程下的同步；在內部，JMM通過happens-before規則，保證在性能優化的同時，操作的一致性和可見性，并在鎖的幫助下，保證操作的原子性，從而保證正確同步位置的線程安全。

synchronized

synchronized是悲觀鎖的一種實現，是互斥鎖。synchronized可以保證在同一時刻，只有一個線程可以執行某個方法或某個代碼塊，同時synchronized可以保證一個線程的變化可見(可見性)，即可以代替volatile。

Java中每一個對象都可以作為鎖，這是synchronized實現同步的基礎：

• 普通同步方法(實例方法)，鎖是當前實例對象 ，進入同步代碼前要獲得當前實例的鎖；
• 靜態同步方法，鎖是當前類的class對象 ，進入同步代碼前要獲得當前類對象的鎖；
• 同步方法塊，鎖是括號里面的對象，對給定對象加鎖，進入同步代碼庫前要獲得給定對象的鎖。

synchronized通過阻塞的方式保證了線程安全，并且每次加鎖釋放鎖，都會降低性能，所以，有效控制synchronized操作的長度，選用更合適的同步機制是并發編程的關鍵。

volatile

volatile是輕量級的線程同步方式。JMM對多線程的happens-before規則保證了，volatile變量操作對線程們可見性，并能防止重排序，但是相比synchronized，volatile并不能保證操作的原子性。

volatile通過在讀寫操作前后添加內存屏障，完成了數據的及時可見性：

• LoadLoad屏障，兩次讀取間加入屏障；
• StoreStore屏障，兩次寫入間加入屏障；
• LoadStore屏障，讀取寫入間加入屏障；
• StoreLoad屏障，寫入讀取間加入屏障。

內存屏障保證了volatile及時將更新從緩存刷新到主存中，總線嗅探技術保證了其他CPU或線程能及時知道數據的修改。其他處理器通過嗅探總線上傳播過來的數據監測自己緩存的值是否過期了，如果過期了，就將其置為無效，而當處理器對這個數據進行修改時，會重新從內存中把數據讀取到緩存中進行處理。

在這種情況下，不同的CPU之間就可以感知其他CPU對變量的修改，并重新從內存中加載更新后的值，因此可以解決可見性問題。

volatile使用場景：

• 純賦值操作，不適合++這種底層多指令的操作；
• 觸發器，通過volatile將volatile變量操作之前的共享變量操作刷新到共享內存。

note*，在32位的JVM下，long、double的讀寫操作不是原子性的，需要通過volatile修飾才能保證操作的原子性，從JDK5開始，保證了操作的原子性。

CAS

CAS是一種典型的樂觀鎖。CAS嚴格來說不是鎖，只是邏輯上的一種概念。樂觀鎖的主要步驟分為：沖突檢測和數據更新。

CAS(Compare And Swap)，即比較并交換,是解決多線程并行情況下使用鎖造成性能損耗的一種機制。CAS操作包含三個操作數——內存位置（V）、預期原值（A）和新值(B)。如果內存位置的值與預期原值相匹配，那么處理器會自動將該位置值更新為新值。否則，處理器不做任何操作。無論哪種情況，它都會在CAS指令之前返回該位置的值。CAS有效地說明了“我認為位置V應該包含值A；如果包含該值，則將B放到這個位置；否則，不要更改該位置，只告訴我這個位置現在的值即可”。這其實和樂觀鎖的沖突檢查+數據更新的原理是一樣的。

可以簡單理解為，如果將要更新的變量的值和線程從該位置取出值相同，則更新該值，對于比較失敗的，重新進行計算，這樣就可以防止多個線程同時對變量做出修改，保證了操作的原子性。

CAS存在著3大問題：

• ABA問題：如果目標值，經歷A->B->A的變化，CAS并不能發現，從而判定錯誤的問題。可以通過版本號等方式，在變量前面追加上版本號，每次變量更新的時候把版本號加一，那么A－B－A 就會變成1A-2B－3A；
• 循環時間長開銷大：自旋CAS如果長時間不成功，會給CPU帶來非常大的執行開銷，如果JVM能支持處理器提供的pause指令那么效率會有一定的提升，pause指令有兩個作用，第一它可以延遲流水線執行指令（de-pipeline）,使CPU不會消耗過多的執行資源，延遲的時間取決于具體實現的版本，在一些處理器上延遲時間是零。第二它可以避免在退出循環的時候因內存順序沖突（memory order violation）而引起CPU流水線被清空（CPU pipeline flush），從而提高CPU的執行效率；
• 只能保證一個共享變量的原子操作：從Java1.5開始JDK提供了AtomicReference類來保證引用對象之間的原子性，可以把多個變量放在一個對象里來進行CAS操作。

note*：CAS的主要考點是ABA問題。

參考文章

【并發編程】【JDK源碼】CAS與synchronized
[Java 并發]為什么會有重排序?和 happens-before 有啥關系
CAS操作確保原子性