怎么理解數據庫高并發可見性、原子性和有序性問題

這篇文章主要講解了“怎么理解數據庫高并發可見性、原子性和有序性問題”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么理解數據庫高并發可見性、原子性和有序性問題”吧！

    為了合理利用 CPU 的高性能，平衡這三者的速度差異，計算機體系機構、操作系統、編譯
程序都做出了貢獻，主要體現為：
1. CPU 增加了緩存，以均衡與內存的速度差異；
2. 操作系統增加了進程、線程，以分時復用 CPU，進而均衡 CPU 與 I/O 設備的速度差
異；
3. 編譯程序優化指令執行次序，使得緩存能夠得到更加合理地利用。

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

源頭之一：緩存導致的可見性問題

    在單核時代，所有的線程都是在一顆 CPU 上執行，CPU 緩存與內存的數據一致性容易解
決。因為所有線程都是操作同一個 CPU 的緩存，一個線程對緩存的寫，對另外一個線程來
說一定是可見的。例如在下面的圖中，線程 A 和線程 B 都是操作同一個 CPU 里面的緩
存，所以線程 A 更新了變量 V 的值，那么線程 B 之后再訪問變量 V，得到的一定是 V 的
最新值（線程 A 寫過的值）。

                                                                                                      CPU 緩存與內存的關系圖    

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

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

                                                                                                多核 CPU 的緩存與內存關系圖

    下面我們再用一段代碼來驗證一下多核場景下的可見性問題。下面的代碼，每執行一次
add10K() 方法，都會循環 10000 次 count+=1 操作。在 calc() 方法中我們創建了兩個
線程，每個線程調用一次 add10K() 方法，我們來想一想執行 calc() 方法得到的結果應該
是多少呢？

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();
// 創建兩個線程，執行 add() 操作
Thread th2 = new Thread(()->{
test.add10K();
});
Thread th3 = new Thread(()->{
test.add10K();
});
// 啟動兩個線程
th2.start();
th3.start();
// 等待兩個線程執行結束

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

    直覺告訴我們應該是 20000，因為在單線程里調用兩次 add10K() 方法，count 的值就是
20000，但實際上 calc() 的執行結果是個 10000 到 20000 之間的隨機數。為什么呢？
我們假設線程 A 和線程 B 同時開始執行，那么第一次都會將 count=0 讀到各自的 CPU
緩存里，執行完 count+=1 之后，各自 CPU 緩存里的值都是 1，同時寫入內存后，我們
會發現內存中是 1，而不是我們期望的 2。之后由于各自的 CPU 緩存里都有了 count 的
值，兩個線程都是基于 CPU 緩存里的 count 值來計算，所以導致最終 count 的值都是小
于 20000 的。這就是緩存的可見性問題。
循環 10000 次 count+=1 操作如果改為循環 1 億次，你會發現效果更明顯，最終 count
的值接近 1 億，而不是 2 億。如果循環 10000 次，count 的值接近 20000，原因是兩個
線程不是同時啟動的，有一個時差。

                                                                                        變量 count 在 CPU 緩存和內存的分布圖

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

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

                                                                                                    線程切換示意圖

       在一個時間片內，如果一個進程進行一個 IO 操作，例如讀個文件，這個時候該進程可以
把自己標記為“休眠狀態”并出讓 CPU 的使用權，待文件讀進內存，操作系統會把這個休
眠的進程喚醒，喚醒后的進程就有機會重新獲得 CPU 的使用權了。
這里的進程在等待 IO 時之所以會釋放 CPU 使用權，是為了讓 CPU 在這段等待時間里可
以做別的事情，這樣一來 CPU 的使用率就上來了；此外，如果這時有另外一個進程也讀文
件，讀文件的操作就會排隊，磁盤驅動在完成一個進程的讀操作后，發現有排隊的任務，
就會立即啟動下一個讀操作，這樣 IO 的使用率也上來了。
是不是很簡單的邏輯？但是，雖然看似簡單，支持多進程分時復用在操作系統的發展史上
卻具有里程碑意義，Unix 就是因為解決了這個問題而名噪天下的。
早期的操作系統基于進程來調度 CPU，不同進程間是不共享內存空間的，所以進程要做任
務切換就要切換內存映射地址，而一個進程創建的所有線程，都是共享一個內存空間的，

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

指令 1：首先，需要把變量 count 從內存加載到 CPU 的寄存器；
指令 2：之后，在寄存器中執行 +1 操作；
指令 3：最后，將結果寫入內存（緩存機制導致可能寫入的是 CPU 緩存而不是內存）。

        操作系統做任務切換，可以發生在任何一條CPU 指令執行完，是的，是 CPU 指令，而不
是高級語言里的一條語句。對于上面的三條指令來說，我們假設 count=0，如果線程 A
在指令 1 執行完后做線程切換，線程 A 和線程 B 按照下圖的序列執行，那么我們會發現
兩個線程都執行了 count+=1 的操作，但是得到的結果不是我們期望的 2，而是 1。

                                                                                            非原子操作的執行路徑示意圖

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

    源頭之三：編譯優化帶來的有序性問題

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

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

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

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

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

                                                                    雙重檢查創建單例的異常執行路徑

感謝各位的閱讀，以上就是“怎么理解數據庫高并發可見性、原子性和有序性問題”的內容了，經過本文的學習后，相信大家對怎么理解數據庫高并發可見性、原子性和有序性問題這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！