並發編程實戰(一)
並發編程的三個核心問題:
- 分工 : 高效的拆解任務分給線程
- 同步 : 線程之間的協作
- 互斥 : 保證同一時刻只允許一個線程訪問共享資源
這個其實不難理解,做個簡單的比喻,我們團隊做一個項目的時候肯定是先分配任務(分工),然後等到任務完成進行合並對接(同步),在開發過程中,使用版本控制工具訪問,一個代碼只能被一個人修改,否則會報錯,需要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 是共享變量, 初始值 =10
if (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==66Final
final修飾變量是告訴編譯器: 這個變量生而不變,可以可勁兒優化.在 1.5 以後 Java 內存模型對 final 類型變量的重排進行了約束。現在只要我們提供正確構造函數沒有“逸出”，就不會出問題了。下面的例子,在構造函數裏將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;
}
}
}
}
這個是不是很簡單.
上圖展示了如何使用共享的鎖來保護不同對象的臨界區.
解決原子性問題,是要保證中間狀態對外不可見.
並發編程實戰(一)