怎么理解數(shù)據(jù)庫高并發(fā)可見性、原子性和有序性問題

這篇文章主要講解了“怎么理解數(shù)據(jù)庫高并發(fā)可見性、原子性和有序性問題”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么理解數(shù)據(jù)庫高并發(fā)可見性、原子性和有序性問題”吧！

    為了合理利用 CPU 的高性能，平衡這三者的速度差異，計(jì)算機(jī)體系機(jī)構(gòu)、操作系統(tǒng)、編譯
程序都做出了貢獻(xiàn)，主要體現(xiàn)為：
1. CPU 增加了緩存，以均衡與內(nèi)存的速度差異；
2. 操作系統(tǒng)增加了進(jìn)程、線程，以分時(shí)復(fù)用 CPU，進(jìn)而均衡 CPU 與 I/O 設(shè)備的速度差
異；
3. 編譯程序優(yōu)化指令執(zhí)行次序，使得緩存能夠得到更加合理地利用。

現(xiàn)在我們幾乎所有的程序都默默地享受著這些成果，但是天下沒有免費(fèi)的午餐，并發(fā)程序
很多詭異問題的根源也在這里。

源頭之一：緩存導(dǎo)致的可見性問題

    在單核時(shí)代，所有的線程都是在一顆 CPU 上執(zhí)行，CPU 緩存與內(nèi)存的數(shù)據(jù)一致性容易解
決。因?yàn)樗芯€程都是操作同一個(gè) CPU 的緩存，一個(gè)線程對(duì)緩存的寫，對(duì)另外一個(gè)線程來
說一定是可見的。例如在下面的圖中，線程 A 和線程 B 都是操作同一個(gè) CPU 里面的緩
存，所以線程 A 更新了變量 V 的值，那么線程 B 之后再訪問變量 V，得到的一定是 V 的
最新值（線程 A 寫過的值）。

                                                                                                      CPU 緩存與內(nèi)存的關(guān)系圖    

一個(gè)線程對(duì)共享變量的修改，另外一個(gè)線程能夠立刻看到，我們稱為可見性。

    多核時(shí)代，每顆 CPU 都有自己的緩存，這時(shí) CPU 緩存與內(nèi)存的數(shù)據(jù)一致性就沒那么容易
解決了，當(dāng)多個(gè)線程在不同的 CPU 上執(zhí)行時(shí)，這些線程操作的是不同的 CPU 緩存。比如
下圖中，線程 A 操作的是 CPU-1 上的緩存，而線程 B 操作的是 CPU-2 上的緩存，很明
顯，這個(gè)時(shí)候線程 A 對(duì)變量 V 的操作對(duì)于線程 B 而言就不具備可見性了。這個(gè)就屬于硬
件程序員給軟件程序員挖的“坑”。

                                                                                                多核 CPU 的緩存與內(nèi)存關(guān)系圖

    下面我們?cè)儆靡欢未a來驗(yàn)證一下多核場(chǎng)景下的可見性問題。下面的代碼，每執(zhí)行一次
add10K() 方法，都會(huì)循環(huán) 10000 次 count+=1 操作。在 calc() 方法中我們創(chuàng)建了兩個(gè)
線程，每個(gè)線程調(diào)用一次 add10K() 方法，我們來想一想執(zhí)行 calc() 方法得到的結(jié)果應(yīng)該
是多少呢？

public class Test {
private long count = 0;
private void add10K() {
int idx = 0;
while(idx++ < 10000) {
count += 1;
}
}
public static long calc() {
final Test test = new Test();
// 創(chuàng)建兩個(gè)線程，執(zhí)行 add() 操作
Thread th2 = new Thread(()->{
test.add10K();
});
Thread th3 = new Thread(()->{
test.add10K();
});
// 啟動(dòng)兩個(gè)線程
th2.start();
th3.start();
// 等待兩個(gè)線程執(zhí)行結(jié)束

th2.join();
th3.join();
return count;
}
}

    直覺告訴我們應(yīng)該是 20000，因?yàn)樵趩尉€程里調(diào)用兩次 add10K() 方法，count 的值就是
20000，但實(shí)際上 calc() 的執(zhí)行結(jié)果是個(gè) 10000 到 20000 之間的隨機(jī)數(shù)。為什么呢？
我們假設(shè)線程 A 和線程 B 同時(shí)開始執(zhí)行，那么第一次都會(huì)將 count=0 讀到各自的 CPU
緩存里，執(zhí)行完 count+=1 之后，各自 CPU 緩存里的值都是 1，同時(shí)寫入內(nèi)存后，我們
會(huì)發(fā)現(xiàn)內(nèi)存中是 1，而不是我們期望的 2。之后由于各自的 CPU 緩存里都有了 count 的
值，兩個(gè)線程都是基于 CPU 緩存里的 count 值來計(jì)算，所以導(dǎo)致最終 count 的值都是小
于 20000 的。這就是緩存的可見性問題。
循環(huán) 10000 次 count+=1 操作如果改為循環(huán) 1 億次，你會(huì)發(fā)現(xiàn)效果更明顯，最終 count
的值接近 1 億，而不是 2 億。如果循環(huán) 10000 次，count 的值接近 20000，原因是兩個(gè)
線程不是同時(shí)啟動(dòng)的，有一個(gè)時(shí)差。

                                                                                        變量 count 在 CPU 緩存和內(nèi)存的分布圖

源頭之二：線程切換帶來的原子性問題

由于 IO 太慢，早期的操作系統(tǒng)就發(fā)明了多進(jìn)程，即便在單核的 CPU 上我們也可以一邊聽
著歌，一邊寫 Bug，這個(gè)就是多進(jìn)程的功勞。
操作系統(tǒng)允許某個(gè)進(jìn)程執(zhí)行一小段時(shí)間，例如 50 毫秒，過了 50 毫秒操作系統(tǒng)就會(huì)重新選
擇一個(gè)進(jìn)程來執(zhí)行（我們稱為“任務(wù)切換”），這個(gè) 50 毫秒稱為“時(shí)間片”。

                                                                                                    線程切換示意圖

       在一個(gè)時(shí)間片內(nèi)，如果一個(gè)進(jìn)程進(jìn)行一個(gè) IO 操作，例如讀個(gè)文件，這個(gè)時(shí)候該進(jìn)程可以
把自己標(biāo)記為“休眠狀態(tài)”并出讓 CPU 的使用權(quán)，待文件讀進(jìn)內(nèi)存，操作系統(tǒng)會(huì)把這個(gè)休
眠的進(jìn)程喚醒，喚醒后的進(jìn)程就有機(jī)會(huì)重新獲得 CPU 的使用權(quán)了。
這里的進(jìn)程在等待 IO 時(shí)之所以會(huì)釋放 CPU 使用權(quán)，是為了讓 CPU 在這段等待時(shí)間里可
以做別的事情，這樣一來 CPU 的使用率就上來了；此外，如果這時(shí)有另外一個(gè)進(jìn)程也讀文
件，讀文件的操作就會(huì)排隊(duì)，磁盤驅(qū)動(dòng)在完成一個(gè)進(jìn)程的讀操作后，發(fā)現(xiàn)有排隊(duì)的任務(wù)，
就會(huì)立即啟動(dòng)下一個(gè)讀操作，這樣 IO 的使用率也上來了。
是不是很簡(jiǎn)單的邏輯？但是，雖然看似簡(jiǎn)單，支持多進(jìn)程分時(shí)復(fù)用在操作系統(tǒng)的發(fā)展史上
卻具有里程碑意義，Unix 就是因?yàn)榻鉀Q了這個(gè)問題而名噪天下的。
早期的操作系統(tǒng)基于進(jìn)程來調(diào)度 CPU，不同進(jìn)程間是不共享內(nèi)存空間的，所以進(jìn)程要做任
務(wù)切換就要切換內(nèi)存映射地址，而一個(gè)進(jìn)程創(chuàng)建的所有線程，都是共享一個(gè)內(nèi)存空間的，

所以線程做任務(wù)切換成本就很低了?，F(xiàn)代的操作系統(tǒng)都基于更輕量的線程來調(diào)度，現(xiàn)在我
們提到的“任務(wù)切換”都是指“線程切換”。
Java 并發(fā)程序都是基于多線程的，自然也會(huì)涉及到任務(wù)切換，也許你想不到，任務(wù)切換竟
然也是并發(fā)編程里詭異 Bug 的源頭之一。任務(wù)切換的時(shí)機(jī)大多數(shù)是在時(shí)間片結(jié)束的時(shí)候，
我們現(xiàn)在基本都使用高級(jí)語言編程，高級(jí)語言里一條語句往往需要多條 CPU 指令完成，例
如上面代碼中的count += 1，至少需要三條 CPU 指令。

指令 1：首先，需要把變量 count 從內(nèi)存加載到 CPU 的寄存器；
指令 2：之后，在寄存器中執(zhí)行 +1 操作；
指令 3：最后，將結(jié)果寫入內(nèi)存（緩存機(jī)制導(dǎo)致可能寫入的是 CPU 緩存而不是內(nèi)存）。

        操作系統(tǒng)做任務(wù)切換，可以發(fā)生在任何一條CPU 指令執(zhí)行完，是的，是 CPU 指令，而不
是高級(jí)語言里的一條語句。對(duì)于上面的三條指令來說，我們假設(shè) count=0，如果線程 A
在指令 1 執(zhí)行完后做線程切換，線程 A 和線程 B 按照下圖的序列執(zhí)行，那么我們會(huì)發(fā)現(xiàn)
兩個(gè)線程都執(zhí)行了 count+=1 的操作，但是得到的結(jié)果不是我們期望的 2，而是 1。

                                                                                            非原子操作的執(zhí)行路徑示意圖

我們潛意識(shí)里面覺得 count+=1 這個(gè)操作是一個(gè)不可分割的整體，就像一個(gè)原子一樣，線
程的切換可以發(fā)生在 count+=1 之前，也可以發(fā)生在 count+=1 之后，但就是不會(huì)發(fā)生
在中間。我們把一個(gè)或者多個(gè)操作在 CPU 執(zhí)行的過程中不被中斷的特性稱為原子性。
指令 1：首先，需要把變量 count 從內(nèi)存加載到 CPU 的寄存器；
指令 2：之后，在寄存器中執(zhí)行 +1 操作；
指令 3：最后，將結(jié)果寫入內(nèi)存（緩存機(jī)制導(dǎo)致可能寫入的是 CPU 緩存而不是內(nèi)存）。
CPU 能保證的原子操作是 CPU 指令級(jí)別的，而不是高級(jí)語言的操作符，這是違背我們直
覺的地方。因此，很多時(shí)候我們需要在高級(jí)語言層面保證操作的原子性。

    源頭之三：編譯優(yōu)化帶來的有序性問題

    那并發(fā)編程里還有沒有其他有違直覺容易導(dǎo)致詭異 Bug 的技術(shù)呢？有的，就是有序性。顧
名思義，有序性指的是程序按照代碼的先后順序執(zhí)行。編譯器為了優(yōu)化性能，有時(shí)候會(huì)改
變程序中語句的先后順序，例如程序中：“a=6；b=7；”編譯器優(yōu)化后可能變
成“b=7；a=6；”，在這個(gè)例子中，編譯器調(diào)整了語句的順序，但是不影響程序的最終
結(jié)果。不過有時(shí)候編譯器及解釋器的優(yōu)化可能導(dǎo)致意想不到的 Bug。
在 Java 領(lǐng)域一個(gè)經(jīng)典的案例就是利用雙重檢查創(chuàng)建單例對(duì)象，例如下面的代碼：在獲取實(shí)
例 getInstance() 的方法中，我們首先判斷 instance 是否為空，如果為空，則鎖定
Singleton.class 并再次檢查 instance 是否為空，如果還為空則創(chuàng)建 Singleton 的一個(gè)實(shí)
例。

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

假設(shè)有兩個(gè)線程 A、B 同時(shí)調(diào)用 getInstance() 方法，他們會(huì)同時(shí)發(fā)現(xiàn) instance ==
null ，于是同時(shí)對(duì) Singleton.class 加鎖，此時(shí) JVM 保證只有一個(gè)線程能夠加鎖成功
（假設(shè)是線程 A），另外一個(gè)線程則會(huì)處于等待狀態(tài)（假設(shè)是線程 B）；線程 A 會(huì)創(chuàng)建一
個(gè) Singleton 實(shí)例，之后釋放鎖，鎖釋放后，線程 B 被喚醒，線程 B 再次嘗試加鎖，此
時(shí)是可以加鎖成功的，加鎖成功后，線程 B 檢查 instance == null 時(shí)會(huì)發(fā)現(xiàn)，已經(jīng)創(chuàng)
建過 Singleton 實(shí)例了，所以線程 B 不會(huì)再創(chuàng)建一個(gè) Singleton 實(shí)例。

這看上去一切都很完美，無懈可擊，但實(shí)際上這個(gè) getInstance() 方法并不完美。問題出
在哪里呢？出在 new 操作上，我們以為的 new 操作應(yīng)該是：
1. 分配一塊內(nèi)存 M；
2. 在內(nèi)存 M 上初始化 Singleton 對(duì)象；
3. 然后 M 的地址賦值給 instance 變量。
但是實(shí)際上優(yōu)化后的執(zhí)行路徑卻是這樣的：
1. 分配一塊內(nèi)存 M；
2. 將 M 的地址賦值給 instance 變量；
3. 最后在內(nèi)存 M 上初始化 Singleton 對(duì)象。

優(yōu)化后會(huì)導(dǎo)致什么問題呢？我們假設(shè)線程 A 先執(zhí)行 getInstance() 方法，當(dāng)執(zhí)行完指令 2
時(shí)恰好發(fā)生了線程切換，切換到了線程 B 上；如果此時(shí)線程 B 也執(zhí)行 getInstance() 方
法，那么線程 B 會(huì)發(fā)現(xiàn)instance != null，所以直接返回 instance，而此時(shí)的
instance 是沒有初始化過的，如果我們這個(gè)時(shí)候訪問 instance 的成員變量就可能觸發(fā)空
指針異常。

                                                                    雙重檢查創(chuàng)建單例的異常執(zhí)行路徑

感謝各位的閱讀，以上就是“怎么理解數(shù)據(jù)庫高并發(fā)可見性、原子性和有序性問題”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)怎么理解數(shù)據(jù)庫高并發(fā)可見性、原子性和有序性問題這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！