并發(fā)問題的根源在哪

首先，我們要知道并發(fā)要解決的是什么問題？并發(fā)要解決的是單進程情況下硬件資源無法充分利用的問題。而造成這一問題的主要原因是CPU-內(nèi)存-磁盤三者之間速度差異實在太大。如果將CPU的速度比作火箭的速度，那么內(nèi)存的速度就像火車，而最慘的磁盤，基本上就相當于人雙腿走路。

這樣造成的一個問題，就是CPU快速執(zhí)行完它的任務的時候，很長時間都會在等待磁盤或是內(nèi)存的讀寫。

計算機的發(fā)展有一部分就是如何重復利用資源，解決硬件資源之間效率的不平衡，而后就有了多進程，多線程的發(fā)展。并且演化出了各種為多進程（線程）服務的東西：

CPU增加緩存機制，平衡與內(nèi)存的速度差異 增加了多個概念，CPU時間片，程序計數(shù)器，線程切換等，用以更好得服務并發(fā)場景 編譯器的指令優(yōu)化，希望在內(nèi)部充分利用硬件資源

但是這樣一來，也會帶來新的并發(fā)問題，歸結(jié)起來主要有三個。

由于緩存導致的可見性問題 線程切換帶來的原子性問題 編譯器優(yōu)化帶來的有序性問題

我們分別介紹這幾個：

緩存導致的可見性

CPU為了平衡與內(nèi)存之間的性能差異，引入了CPU緩存，這樣CPU執(zhí)行指令修改數(shù)據(jù)的時候就可以批量直接讀寫CPU緩存的內(nèi)存，一個階段后再將數(shù)據(jù)寫回到內(nèi)存。

但由于現(xiàn)在多核CPU技術的發(fā)展，各個線程可能運行在不同CPU核上面，每個CPU核各有各自的CPU緩存。前面說到對變量的修改通常都會先寫入CPU緩存，再寫回內(nèi)存。這就會出現(xiàn)這樣一種情況，線程1修改了變量A，但此時修改后的變量A只存儲在CPU緩存中。這時候線程B去內(nèi)存中讀取變量A，依舊只讀取到舊的值，這就是可見性問題。

線程切換帶來的原子性

為了更充分得利用CPU，引入了CPU時間片時間片的概念。進程或線程通過爭用CPU時間片，讓CPU可以更加充分得利用。

比如在進行讀寫磁盤等耗時高的任務時，就可以將寶貴的CPU資源讓出來讓其他線程去獲取CPU并執(zhí)行任務。

但這樣的切換也會導致問題，那就是會破壞線程某些任務的原子性。比如java中簡單的一條語句count += 1。

映射到CPU指令有三條，讀取count變量指令，變量加1指令，變量寫回指令。雖然在高級語言（java）看來它就是一條指令，但實際上確是三條CPU指令，并且這三條指令的原子性無法保證。也就是說，可能在執(zhí)行到任意一條指令的時候被打斷，CPU被其他線程搶占了。而這個期間變量值可能會被修改，這里就會引發(fā)數(shù)據(jù)不一致的情況了。所以高并發(fā)場景下，很多時候都會通過鎖實現(xiàn)原子性。而這個問題也是很多并發(fā)問題的源頭。

編譯器優(yōu)化帶來的有序性

因為現(xiàn)在程序員編寫的都是高級語言，編譯器需要將用戶的代碼轉(zhuǎn)成CPU可以執(zhí)行的指令。

同時，由于計算機領域的不斷發(fā)展，編譯器也越來越智能，它會自動對程序員編寫的代碼進行優(yōu)化，而優(yōu)化中就有可能出現(xiàn)實際執(zhí)行代碼順序和編寫的代碼順序不一樣的情況。

而這種破壞程序有序性的行為，在有些時候會出現(xiàn)一些非常微妙且難以察覺的并發(fā)編程bug。

舉個簡單的例子，我們常見的單例模式是這樣的：

public class Singleton { private Singleton() {} private static Singleton sInstance; public static Singleton getInstance() { if (sInstance == null) {//第一次驗證是否為null synchronized (Singleton.class) { //加鎖 if (sInstance == null) { //第二次驗證是否為null sInstance = new Singleton(); //創(chuàng)建對象 } } } return sInstance; }}

即通過兩段判斷加鎖來保證單例的成功生成，但在極小的概率下，可能會出現(xiàn)異常情況。原因就出現(xiàn)在sInstance = new Singleton();這一行代碼上。這行代碼，我們理解的執(zhí)行順序應該是這樣：

為Singleton象分配一個內(nèi)存空間。 在分配的內(nèi)存空間實例化對象。 把Instance 引用地址指向內(nèi)存空間。

但在實際編譯的過程中，編譯器有可能會幫我們進行優(yōu)化，優(yōu)化完它的順序可能變成如下：

為Singleton對象分配一個內(nèi)存空間。 把instance 引用地址指向內(nèi)存空間。 在分配的內(nèi)存空間實例化對象。

按照優(yōu)化完的順序，當并發(fā)訪問的時候，可能會出現(xiàn)這樣的情況

A線程進入方法進行第1次instance == null判斷。 此時A線程發(fā)現(xiàn)instance 為null 所以對Singleton.class加鎖。 然后A線程進入方法進行第2次instance == null判斷。 然后A線程發(fā)現(xiàn)instance 為null，開始進行對象實例化。 為對象分配一個內(nèi)存空間。 .把Instance 引用地址指向內(nèi)存空間（而就在這個指令完成后，線程B進入了方法）。 B線程首先進入方法進行第1次instance == null判斷。B線程此時發(fā)現(xiàn)instance 不為null ，所以它會直接返回instance (而此時返回的instance 是A線程還沒有初始化完成的對象)

最終線程B拿到的instance 是一個沒有實例化對象的空內(nèi)存地址，所以導致instance使用的過程中造成程序錯誤。解決辦法很簡單，可以給sInstance對象加上一個關鍵字，volatile，這樣編譯器就不會亂優(yōu)化，有關volatile的具體內(nèi)容后續(xù)再細說。

主要解決辦法

通過上面的介紹，其實可以歸納無論是CPU緩存，線程切換還是編譯器優(yōu)化亂序，出現(xiàn)問題的核心都是因為多個線程要并發(fā)讀寫某個變量或并發(fā)執(zhí)行某段代碼。那么我們可以控制，一次只讓一個線程執(zhí)行變量讀寫就可以了，這就是互斥。

而在某些時候，互斥還不夠，還需要一定的條件。比如一個生產(chǎn)者一個消費者并發(fā)，生產(chǎn)者向隊列存東西，消費者向隊列拿東西。那么生產(chǎn)者寫的時候要保證存的時候隊列不是滿的，消費者要保證拿的時候隊列非空。這種線程與線程間需要通信協(xié)作的情況，稱為同步，同步可以說是更復雜的互斥。

既然知道了并發(fā)編程的根源以及同步和互斥，那我們來看看有哪些解決的思路。其實一共也就三種：

避免共享 Immutability（不變性） 管程及其他工具

下面我們分別說說這三種方案的優(yōu)缺點

避免共享

我們先來說說避免共享，其實避免共享說是線程本地存儲技術，在java中指的一般就是Threadlocal。ThreadLocal會為每個線程提供一個本地副本，每個線程都只會修改自己的ThreadLocal變量。這樣一來就不會出現(xiàn)共享變量，也就不會出現(xiàn)沖突了。

其實現(xiàn)原理是在ThreadLocal內(nèi)部維護一個ThreadLocalMap，每次有線程要獲取對應變量的時候，先獲取當前線程，然后根據(jù)不同線程取不同的值，典型的以空間換時間。

所以ThreadLocal還是比較適用于需要共享資源，且資源占用空間不大的情況。比如一些連接的session啊等等。但是這種模式應用場景也較為有限，比如需要同步情況就難以勝任。

Immutability（不變性）

Immutability在函數(shù)式中用得比較多，函數(shù)式編程的一個主要目的是要寫出無副作用的代碼，有關什么是無副作用可以參考我以前的文章Scala函數(shù)式編程指南（一） 函數(shù)式思想介紹。而無副作用的一個主要特點就是變量都是Immutability即不可變的，即創(chuàng)建對象后不會再修改對象，比如scala默認的變量和數(shù)據(jù)結(jié)構都是不可變的。而在java中，不變性變量即通過final修飾的變量，如String，Long，Double等類型都是Immutability的，它們的內(nèi)部實現(xiàn)都是基于final關鍵字的。

那這又和并發(fā)編程有什么關系呢？其實啊，并發(fā)問題很大部分原因就是因為線程切換破壞了原子性，這又導致線程隨意對變量的讀寫破壞了數(shù)據(jù)的一致性。而不變性就不必擔心這個問題，因為變量都是不變，不可寫只能讀的。在這種編程模式下，你要修改一個變量，那么只能新生成一個。這樣做的好處很明顯，但壞處也是顯而易見，那就是引入了額外的編程復雜度，喪失了代碼的可讀性和易用性。

因為如此，不變性的并發(fā)解決方案其實相對而已沒那么廣泛，其中比較有代表性的算是Actor并發(fā)編程模型，我以前也有討論過，有興趣可以看看Actor模型淺析 一致性和隔離性，這種編程模型和常規(guī)并發(fā)解決方案有很顯著的差異。按我的了解，Acctor模式多用在分布式系統(tǒng)的一些協(xié)調(diào)功能，比如維持集群中多個機器的心跳通信等等。如果在單機并發(fā)環(huán)境下，還是下面要介紹的管程類工具才是利器。

管程及其他工具

其實最早的操作系統(tǒng)中，解決并發(fā)問題用的是信號量，信號量通過兩個原子操作wait(S)，和signal(S)（俗稱P，V操作）來實現(xiàn)訪問資源互斥和同步。比如下面這個小例子：

//整型信號量定義int S;//P操作wait(S){ while(S<=0); S--;}//V操作signal(S){ S++;}

雖然信號量方便有效，但信號量要對每個共享資源都實現(xiàn)對應的P和V操作，這使得并發(fā)編程中可能要出現(xiàn)大量的P，V操作，并且這部分內(nèi)容難以抽象出來。

為了更好地實現(xiàn)同步互斥，于是就產(chǎn)生了管程（即Monitor，也有翻譯為監(jiān)視器），值得一提的是，管程也有幾種模型，分別是：Hasen模型，Hoare模型和MESA模型。其中MESA模型應用最廣泛，java也是參考自MESA模型。這里簡單介紹下管程的理論知識，這部分內(nèi)容參考自進程同步機制-----為進程并發(fā)執(zhí)行保駕護航，希望了解更多管程理論知識的童鞋可以看看。

我們來通過一個經(jīng)典的生產(chǎn)-消費隊列來解釋，如下圖

我們先解釋下圖中右半部分的內(nèi)容，右上角有一個等待調(diào)用的線程隊列，管程中每次只能有一個線程在執(zhí)行任務，所以多個任務需要等待。然后是各個名詞的意思，生產(chǎn)-消費需要往隊列寫入和取出東西，這里的隊列就是共享變量，對共享資源進行操作稱之為過程（入隊和出隊兩個過程）。而向隊列寫入和取出是有條件的，寫入的時候隊列必須是非滿的，取出的時候隊列必須是非空的，這兩個條件被稱為條件變量。

然后再來看看左半部分的內(nèi)容，假設線程T1讀取共享變量（即隊列），此時發(fā)現(xiàn)隊列為空（條件變量之一），那么T1此時需要等待，去哪里等呢？去條件變量隊列不能為空對應的隊列中去等待。此時另一個線程T2向共享變量隊列寫數(shù)據(jù)，通過了條件變量隊列不能滿，那么寫完后就會通知線程T1。但因為管程的限制，管程中只能有一個線程在執(zhí)行，所以T1線程不能立即執(zhí)行，它會回到右上角的線程等待隊列等待（不同的管程模型在這里是有分歧的，比如Hasen模型是立即中斷T2線程讓隊列中下一個線程執(zhí)行）。

解釋完這個圖，管程的概念也就呼之欲出了，

hansen對管程的定義如下：一個管程定義了一個數(shù)據(jù)結(jié)構和能力為并發(fā)進程所執(zhí)行（在該數(shù)據(jù)結(jié)構上）的一組操作，這組操作能同步進程和改變管程中的數(shù)據(jù)。

本質(zhì)上，管程是對共享資源以及對共享資源的操作抽象成變量和方法，要操作共享變量僅能通過管程提供的方法（比如上面的入隊和出隊）間接訪問。所以你會發(fā)現(xiàn)管程其實和面向?qū)ο蟮睦砟钍鞘窒嘟模趈ava中，主要提供了低層次了synchronized關鍵字和wait()，notify()等方法。同時還提供了高層次的ReenTrantLock和Condition來實現(xiàn)管程模型。

以上就是JAVA如何解決并發(fā)問題的詳細內(nèi)容，更多關于JAVA 并發(fā)的資料請關注好吧啦網(wǎng)其它相關文章！