寫在前面
上一篇文章原子性問題的宏觀理解 帶領大家了解了鎖和資源的模型，有了這篇文章的鋪墊，相信理解這一篇文章就非常輕松了
當我們要保護單個資源並對其進行修改其實很簡單，只需按照下圖分三步走
- 創建受保護資源 R 的鎖
- 加鎖進入臨界區
- 解鎖走出臨界區
上圖的關鍵是「R1 的鎖保護 R1」的指向關系是否正確
如果都是保護單個資源這樣簡單，程序猿的世界該有多美好，可惜並不是，通常我們需要保護多個資源
保護多個資源
保護多個沒有關系的資源
如果多個資源沒有關系，那就是保護一個資源模型的復制，同樣非常簡單，且看下圖:
比如現實中銀行取款和修改密碼操作。
銀行取款操作對應的資源是「余額」, 修改密碼操作對應的資源是「密碼」，余額和密碼兩個資源完全沒有關系，所以各自用自家的鎖保護自家的資源就好了
如果多個資源沒有關系，程序猿的世界該有多美好，可惜並不是，我們保護的資源多數情況都有關聯關系
保護多個關系的資源
拿經典的銀行轉賬案例來說明，賬戶 A 給賬戶 B 轉賬，賬戶 A 余額減少 100 元，賬戶 B 余額增加 100 元，這個操作要是原子性的，那么資源「A 余額」和資源「B 余額」就這樣"有了關系"，先來看程序:
class Account {
private int balance;
// 轉賬
synchronized void transfer(
Account target, int amt){
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
用 synchronized 直接保護 transfer 方法，然后操作資源「A 余額」和資源「B 余額」就可以了
⚠️: 真的是這樣嗎？
先停止向下看，在你的筆記本上按照文章開頭的三步走來畫個圖看一看，是否和下圖一樣呢？
我們通常容易忽略鎖和資源的指向關系，我們想當然的用鎖 this 來保護 target 資源了，也就沒有起到保護作用
假設 A，B，C 賬戶初始余額都是 200 原，A 向 B 轉賬 100，B 向 C 轉賬 100
我們期盼最終的結果是:
賬戶 A 余額: 100 元
賬戶 B 余額: 200 元
賬戶 C 余額: 300 元
假線程 1「A 向 B 轉賬」與線程 2「B 向 C 轉賬」兩個操作同時執行，根據 JMM 模型可知，線程 1 和線程 2 讀取線程 B 當前的余額都是 200 元:
- 線程 1 執行 transfer 方法鎖定的是 A 的實例(A.this)，並沒有鎖定 B 的實例
- 線程 2 執行 transfer 方法鎖定的是 B 的實例(B.this)，並沒有鎖定 C 的實例
所以線程 1 和線程 2 可以同時進入 transfer 臨界區，上面你認為對的模型其實就會變成這個樣子:
還記得 happens-before 規則 這篇文章提到的監視器鎖規則和傳遞性規則嗎？
監視器鎖規則
對一個鎖的解鎖 happens-before 於隨后對這個鎖的加鎖
傳遞性規則
如果 A happens-before B, 且 B happens-before C, 那么 A happens-before C
資源 B.balance 存在於兩個"臨界區"中，所以這個"臨界區"對 B.balance 來說形同虛設，也就不滿足監視器鎖規則，進而導致傳遞性規則也不生效，說白了，前序線程的更改結果對后一個線程不可見
這樣最終導致:
-
**賬戶 B 的余額可能是 100: ** 線程 1 寫 B.balance 100(balance = 300) 先於 線程 2 寫 B.balance(balance = 100)，也就是說線程 1 的結果會被線程 2 覆蓋，導致最終賬戶 B 的余額為 100
-
賬戶 B 的余額可能是 300: 與上述情況相反，線程 1 寫 B.balance 100(balance = 300) 后於 線程 2 寫 B.balance(balance = 100)，也就是說線程 2 的結果線程 1 覆蓋，導致最終賬戶 B 的余額為 300
就是不能得到我們理想結果 200，感覺生活無比的艱難，那怎么辦呢？
正確姿勢
上面的問題就是為資源創建的鎖不能保護所有關聯的資源，那我們就想辦法解決這個問題，來看下面代碼:
class Account {
private int balance;
// 轉賬
void transfer(Account target, int amt){
synchronized(Account.class) {
if (this.balance > amt) {
this.balance -= amt;
target.balance += amt;
}
}
}
}
我們將 this 鎖變為 Account.class 鎖，Account.class 是虛擬機加載 Account 類時創建的，肯定是唯一的(雙親委派模型解釋了為何該對象是唯一的)， 所有 Account 對象都共享 Account.class, 也就是說，Account.class 鎖能保護所有 Account 對象，我們將上面程序再用模型解釋一下
總結
到這里關於鎖和資源的關系你應該了解的更加透徹了，單個資源和多個無關聯資源的情形都很好處理，為各自資源創建相應的鎖就好，如果多個資源有關聯，為了讓鎖起到保護作用，我們需要將鎖的粒度變大，比如將 this 鎖變成了 Account.class 鎖。
轉賬業務非常常見，並發量非常大，如果我們將鎖的粒度都提升到 Account.class 這個級別(分久必合)，假設每次轉賬業務都很耗時，那么顯然這個鎖的性能是比較低的，所以接下來的文章，我們還會繼續優化這個模型，選擇合適的鎖粒度，同時能保護多個有關聯的資源，
我們的鎖粒度雖然大，但是我們保障了賬戶的安全，所以並發編程可以先保證事情做對，遇到瓶頸了，慢慢優化改變相應的模型就好了，當然熟練理解這個模型以后，一步到位的並發編程模型當然是極好的......
靈魂追問
- 還記得 happens-before 的幾個原則嗎？
- 偏向鎖，輕量鎖，重量鎖是不是和我們這節內容有異曲同工之處呢？
- 提前想一下，我們如何來優化這個模型呢？
附加說明
如果你對這篇文章理解有些困難，可以按照下面的順序回憶前序文章相關內容
- 這次走進並發的世界，請不要錯過
- 學並發編程，透徹理解這三個核心是關鍵
- 並發Bug之源有三，請睜大眼睛看清它們
- 可見性有序性，Happens-before來搞定
- 解決原子性問題？你首先需要的是宏觀理解
- 面試並發volatile關鍵字時，我們應該具備哪些談資？
推薦閱讀
- 每天用SpringBoot，還不懂RESTful API返回統一數據格式是怎么實現的？
- 雙親委派模型：大廠高頻面試題，輕松搞定
- EasyExcel 讀取 excel 真的很easy
- 紅黑樹，超強動靜圖詳解，簡單易懂
提高效率工具
歡迎持續關注公眾號：「日拱一兵」
- 前沿 Java 技術干貨分享
- 高效工具匯總 | 回復「工具」
- 面試問題分析與解答
- 技術資料領取 | 回復「資料」
以讀偵探小說思維輕松趣味學習 Java 技術棧相關知識，本着將復雜問題簡單化，抽象問題具體化和圖形化原則逐步分解技術問題，技術持續更新，請持續關注......
