并發編程的三個核心問題:

分工 : 高效的拆解任務分給線程

同步 : 線程之間的協作

互斥 : 保證同一時刻只允許一個線程訪問共享資源

這個其實不難理解,做個簡單的比喻,我們團隊做一個項目的時候肯定是先分配任務(分工),然后等到任務完成進行合并對接(同步),在開發過程中,使用版本控制工具訪問,一個代碼只能被一個人修改,否則會報錯,需要meger(互斥).

學習攻略:

跳出來,看全景

鉆進去,看本質

核心: 分工(拆分) - 同步(一個線程執行完成如何通知后續任務的線程開始工作) - 互斥(同一時刻,只允許一個線程訪問共享變量)

全景:

本質 : 知其然知其所以然,有理論做基礎.技術的本質是背后的理論模型

并發編程為啥好難?

我從我的角度看,一個是并發編程的API不是很了解,第二個就是出現了問題不會解決,如果說還有,那就是是在不知道并發編程是用來干啥的?有什么用?

每一中技術的出現都有他出現的必然性,對于并發來說無疑是提高性能,那單線程為啥就不能提高性能,原因就在于CPU,內存和IO設備三者的速度差異太大,舉個例子來說: CPU一天,內存一年,IO一百年; 而木桶理論告訴我們程序的性能是由短板決定,所以只要合理的平衡三者的速度差異,就可以提高性能.

并發編程問題的源頭

緩存導致的可見性: 對于單CPU來說,緩存是可見的,也就是說多個線程同時操作,CPU會從內存讀取數據,線程更新數據到CPU,CPU寫入內存,線程和CPU進行交互,這個操作每個線程之間是可見的.
但是對于多CPU來說,多個線程操作不同的CPU,不同的CPU操作同一個內存,這會導致操作的不可見性,就出現了問題.(說下可見性的概念: 一個線程對共享變量的修改,另一個線程能夠立刻看到,這就是可見性)

線程切換帶來的原子性問題: 原子性是一個或多個操作在CPU執行的過程中不被中斷的特性. 那為什么會中斷呢?原因就在于提高性能,就和現在的計算機一樣,是分時間片來進行任務切換,同時聽歌和敲代碼,看似是同時發生,其實不是,知識任務之間切換的非常快,做到了看似同時進行.
在高級程序中,一個看似簡單的操作可能需要多條CPU指令來完成,不如說count += 1;CPU指令至少三個,從內存中拿到count值到寄存器,在寄存器中進行加一操作,將結果寫入內存,這個過程中可能會發生任務間的切換,比如說另一個線程在寫入內存前有進行了一次++操作,這個時候結果就不是想要的結果了,可能例子不合適,但是這個意思就是這個. 而原子性就是保證高級語言層面保證操作的原子性.

編譯優化的有序性問題: 有序性指的是程序按照代碼的先后順序執行. 看起來沒問題,本來就應該這樣,其實不然,在JVM的知識中有一個叫重排序,就是編譯器為了優化性能,有時會改變程序中語句的先后順序,大部分情況下編譯器調整后的順序是不會影響程序的最終結果,不過也有特殊情況,如下:

public class Singleton {static Singleton instance;static Singleton getInstance(){if (instance == null) {synchronized(Singleton.class) {if (instance == null)instance = new Singleton();}}return instance;} }

上面是經典的雙重檢查創建單例對象,在我們的印象中new的操作應該是: 分配內存,在內存上初始化對象,地址賦值. 實際上優化后是: 分配內存,地址賦值,初始化. 優化后的順序就會出現問題,地址賦值后發生了線程切換,這時候其他線程讀取到了對象不為null,但是實際上只有地址,這個時候訪問成員變量就會出現空指針異常,這個就是編譯優化可能會出現的問題.

也就是說,很多的并發Bug是由可見性,原子性,有序性的原理造成的,從這三個方面去考慮,可以理解診斷很大部分一部分Bug. 緩存導致可見性問題,線程切換帶來的原子性,編譯優化帶來的有序性,本質都是提高程序性能,但是在帶來性能的時候可能也會出現其他問題,所以在運用一項技術的時候一定要清楚它帶來的問題是什么,以及如何實現.

Java內存模型: 解決可見性和有序性問題

可見性的原因是緩存,有序性的原因是編譯優化,那解決的最直接的辦法就是禁用緩存和編譯優化,但是有緩存和編譯優化的目的是提高程序性能,禁用了程序的性能如何保證? 合理的方案是按需禁用緩存和編譯優化,Java內存模型規范了JVM如何提供按需禁用緩存和編譯優化的方法,具體的,這些方法包括volatile,synchronized和final三個關鍵字,以及六項Happens-Before規則

volatile的困惑

volatile關鍵字用來聲明變量,告訴編譯器這個變量的讀寫不能使用CPU緩存,必須從內存中讀寫.

// 以下代碼來源于【參考 1】 class VolatileExample {int x = 0;volatile boolean v = false;public void writer() {x = 42;v = true;}public void reader() {if (v == true) {// 這里 x 會是多少呢？}} }

上面的代碼x的值是多少呢?直覺上應該是42,但是在jdk1.5之前,可能的值是0或者42,1.5之后就是42,為什么?原因是變量x可能被CPU緩存而導致可見性問題,也就是x=42可能不被v=true可見,那Java的內存模型在1.5版本之后是如何解決的呢? 就是Happens-before規則.

Happens-Before規則

Happens-before指的是前一個操作的結果對后續操作是可見的,具體如下.

1. 程序的順序性規則

這個規則說的是在一個線程中,按照程序順序,前面的操作Happens-Before于后續的任意操作. 簡單理解就是: 程序前面對于某個變量的修改一定是對后續操作可見的.也就是前面的代碼x=42對于v=true是可見的.

2. volatile變量規則

這條規則指的是對一個volatile變量的寫操作,Happens-Before于后續對這個volatile變量的讀操作,即volatile變量的寫操作對于讀操作是可見的.

3. 傳遞性

這條規則指的是A Happens-Before C,且B Happens-Before C,那么A Happens-Before C,如下圖:

這樣就很明顯了,x=42 Happens-Before v=true,寫v=true Happens-Before 讀v=true,那也就是說x=42 Happens Before 讀v=true,這樣下來,其他線程就可以看到x=42這個操作了.

4. 管程中鎖的規則

這個規則是指對一個鎖的解鎖Happens-Before與后續對這個鎖的加鎖. 管程是一種通用的同步原語,在Java中指的就是synchronized,synchronized是Java里對管程的實現.管程中的鎖在Java中是隱式實現的,也就是進入同步塊之前,會自動加鎖,而在代碼塊執行完后自動釋放鎖,加鎖以及解鎖都是編譯器幫我們實現的.

synchronized (this) { // 此處自動加鎖// x 是共享變量, 初始值 =10if (this.x < 12) {this.x = 12; } } // 此處自動解鎖

5. 線程start()規則

這個是線程啟動的,指的是主線程A啟動子線程B,子線程B能夠看到主線程在啟動子線程B前的操作.

Thread B = new Thread(()->{// 主線程調用 B.start() 之前// 所有對共享變量的修改，此處皆可見// 此例中，var==77 }); // 此處對共享變量 var 修改 var = 77; // 主線程啟動子線程 B.start();

6. 線程join()規則

這條規則是關于線程等待的.它是指主席愛能成A通過調用子線程B的join方法,子線程B執行完成之后,主線程可以看到子線程中的操作.這里指的是對共享變量的操作.

Thread B = new Thread(()->{// 此處對共享變量 var 修改var = 66; }); // 例如此處對共享變量修改， // 則這個修改結果對線程 B 可見 // 主線程啟動子線程 B.start(); B.join() // 子線程所有對共享變量的修改 // 在主線程調用 B.join() 之后皆可見 // 此例中，var==66

Final

final修飾變量是告訴編譯器: 這個變量生而不變,可以可勁兒優化.在 1.5 以后 Java 內存模型對 final 類型變量的重排進行了約束?，F在只要我們提供正確構造函數沒有“逸出”，就不會出問題了。下面的例子,在構造函數里將this賦值給全局變量global.obj,這就是逸出(逸出就是對象還沒有構造完成,就被發布出去),線程global.obj讀取到x有可能讀到0.

// 以下代碼來源于【參考 1】 final int x; // 錯誤的構造函數 public FinalFieldExample() { x = 3;y = 4;// 此處就是講 this 逸出，global.obj = this; }

在 Java 語言里面，Happens-Before 的語義本質上是一種可見性，A Happens-Before B 意味著 A 事件對 B 事件來說是可見的，無論 A 事件和 B 事件是否發生在同一個線程里。例如 A 事件發生在線程 1 上，B 事件發生在線程 2 上，Happens-Before 規則保證線程 2 上也能看到 A 事件的發生。

互斥鎖: 解決原子性問題

前面看了Java的內存模型,解決了可見性和編譯優化的重排序問題,哪還有一個原子性如何解決?答案就是使用互斥鎖實現.

先探究源頭,long在32位機器上操作可能出現Bug,原因是線程的切換,那只要保證同一時刻只有一個線程執行,就可以了,這就是互斥.

互斥鎖模型:

Java中如何實現這種互斥鎖呢?

Java語言提供的鎖技術: synchronized

java中的synchronized關鍵字就是鎖的一種實現,synchronized關鍵字可以用來修飾方法,也可以用來修飾代碼塊,如下:

class X {// 修飾非靜態方法synchronized void foo() {// 臨界區}// 修飾靜態方法synchronized static void bar() {// 臨界區}// 修飾代碼塊Object obj = new Object()；void baz() {synchronized(obj) {// 臨界區}} }

先說一下那個加鎖和釋放鎖,synchronized并沒有顯示的進行這一操作,而是編譯器會在synchronized修飾的方法或代碼塊前后自動加鎖lock()和解鎖unlock(),不需要編程人員手動加鎖和釋放鎖(省的忘記,程序員很忙的).

synchronized鎖的規則是什么: 當修飾靜態方法的時候,鎖定的是當前的類對象. 修飾非靜態方法和代碼塊的時候,鎖定的是當前的對象this.如下

class X {// 修飾靜態方法synchronized(X.class) static void bar() {// 臨界區} }class X {// 修飾非靜態方法synchronized(this) void foo() {// 臨界區} }

案例深入理解:

下面的代碼可以解決多線程問題嗎?

class SafeCalc {long value = 0L;long get() {return value;}synchronized void addOne() {value += 1;} }

答案是并不可以,原因是雖然對addOne進行了加鎖操作(對一個鎖的解鎖Happens-Before于后續對這個鎖的加鎖),保證了后續addOne的操作的共享變量是可以看到前面addOne操作后的共享變量的值,但是get方法卻沒有,多個線程get方法可能獲取到的值相同,addOne()之后就會亂套,所以并不能解決.那下面的代碼可以解決問題嗎?

class SafeCalc {long value = 0L;synchronized long get() {return value;}synchronized void addOne() {value += 1;} }

這種是可以解決多線程問題,也就是可以解決多個線程操作同一個對象的并發問題.那如果要解決多個線程操作不同對象的并發問題呢?

鎖和受保護資源的關系

受保護資源和鎖之間的關聯關系是N:1的關系.也就是說一個鎖可以保護多個受保護的資源,這個就是現實生活中的包場,但是我覺得這個也要分情況,多個受保護的資源和鎖之間一定要有關系,不然鎖不起作用就麻煩了,舉個例子來說就是自己家門的鎖肯定保護自己東西,不能用自己家門的鎖去保護別人家的東西.

下面的例子:

class SafeCalc {static long value = 0L;synchronized long get() {return value;}synchronized static void addOne() {value += 1;} }

分析如圖:

所以說addOne對value的修改對臨界區get()沒有可見性保證,會導致并發問題.將get方法也改為靜態的就可以解決了.

synchronized 是 Java 在語言層面提供的互斥原語，其實 Java 里面還有很多其他類型的鎖，但作為互斥鎖，原理都是相通的：鎖，一定有一個要鎖定的對象，至于這個鎖定的對象要保護的資源以及在哪里加鎖 / 解鎖，就屬于設計層面的事情了。

互斥鎖: 如何用一把鎖保護多個資源

受保護的資源和鎖之間合理的關聯關系應該是N:1的關系.使用一把鎖保護多個資源也是分情況的,在于多個資源之間存不存在關系,這是要分情況討論的.

保護沒有關聯關系的多個資源

舉個例子來說明,Account類有兩個成員變量,分別是賬戶余額balance和賬戶密碼password. 取款和查看余額會訪問balance,創建一個final對象balLock來作為balance的鎖;更改密碼和查看密碼會操作password,創建一個final對象pwLock來作為password的鎖.不同的資源用不同的鎖保護.代碼示例如下:

class Account {// 鎖：保護賬戶余額private final Object balLock= new Object();// 賬戶余額 private Integer balance;// 鎖：保護賬戶密碼private final Object pwLock= new Object();// 賬戶密碼private String password;// 取款void withdraw(Integer amt) {synchronized(balLock) {if (this.balance > amt){this.balance -= amt;}}} // 查看余額Integer getBalance() {synchronized(balLock) {return balance;}}// 更改密碼void updatePassword(String pw){synchronized(pwLock) {this.password = pw;}} // 查看密碼String getPassword() {synchronized(pwLock) {return password;}} }

那還有沒有其他的解決方案? 可以使用this來進行加鎖,但是這種情況性能會很差,因為password和balance使用同一把鎖,操作也就串行了,使用兩把鎖,password和balance的操作是可以并行的,用不同的鎖對受保護資源進行精細化關系,能夠提升性能.這個叫細粒度鎖

保護有關聯關系的多個資源

如果多個資源之間有關聯關系,那就比較復雜,經典的轉賬問題.看下面代碼可能發生并發問題嗎?

class Account {private int balance;// 轉賬synchronized void transfer(Account target, int amt){if (this.balance > amt) {this.balance -= amt;target.balance += amt;}} }

開起來沒問題,其實不然,只對當前對象進行了加鎖,那目標對象的訪問呢?也就是說當前的對象是無法保護target.balance的.

上面的案例兩個人之間的轉賬或許沒有問題,但是涉及三個人呢?

這個時候B的余額可能為100,也可能為300,看哪個執行在后了.那應該如何解決這種有關聯的資源呢,找公共的鎖就可以,也就是要鎖能覆蓋所有受保護資源,解決方案其實不少,如下

class Account {private Object lock；private int balance;private Account();// 創建 Account 時傳入同一個 lock 對象public Account(Object lock) {this.lock = lock;} // 轉賬void transfer(Account target, int amt){// 此處檢查所有對象共享的鎖synchronized(lock) {if (this.balance > amt) {this.balance -= amt;target.balance += amt;}}} }

這個解決方案缺點在于需要傳入共享的lock,還有一種方案

class Account {private int balance;// 轉賬void transfer(Account target, int amt){synchronized(Account.class) {if (this.balance > amt) {this.balance -= amt;target.balance += amt;}}} }

這個是不是很簡單.

上圖展示了如何使用共享的鎖來保護不同對象的臨界區.

解決原子性問題,是要保證中間狀態對外不可見.

轉載于:https://www.cnblogs.com/wadmwz/p/10504164.html

總結

以上是生活随笔為你收集整理的并发编程实战(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。