Java并發編程之驗證volatile不能保證原子性

通過系列文章的學習，凱哥已經介紹了volatile的三大特性。1：保證可見性 2：不保證原子性 3：保證順序。那么怎么來驗證可見性呢？本文凱哥(凱哥Java:kaigejava)將通過代碼演示來證明為什么說volatile不能夠保證共享變量的原子性操作。

我們來舉個現實生活中的例子：

中午去食堂打飯，假設你非常非常的饑餓，需要一葷兩素再加一份米飯。如果食堂打飯的阿姨再給你打一個菜的時候，被其他人打斷了，給其他人打飯，然后再回過頭給你打飯。你選一葷兩素再加一份米飯打完的過程被打斷了四次耗時30分鐘。你想想你自己的感受。是不是要瘋了，要暴走了！其實，如果把從你點菜到阿姨給你打完飯這個過程，看著計算機的一個線程執行過程的話，那么在你點菜到你拿到飯菜這個過程是一個完整的，不能被打斷的，這就是所謂的原子性。如果被多次打斷的話想想你的心理，就知道程序如果在執行過程被打斷后的結果了。

原子性操作的定義：

所謂的原子性操作就是線程對變量的操作一旦開始，就會一直運行直到結束。中介不會因為其他原因而切換到另一個線程。操作是不可分割的，在執行完畢之前是不會被其他任務或是事件中斷的。一個操作或者是多個操作要么執行都成功要么執行都失敗(可以結合數據庫的原子性理解)。

怎么證明volatile修飾的共享變量就不能保證原子性呢？

模擬場景：

共享變量volatile int number=0；執行number++操作。使用多個線程多次調用。看看使用volatile修飾的number在執行結束后的結果是否是我們預期的結果。

我們分別用10個線程執行100次，50個線程執行1000次以及50個線程執行一百萬次來看看結果。

先來看看變量是用volatil修飾的

再來看看主線程里面：

按照上面咱們規定的線程數量運行次數來看看咱們預期結果和實際運行結果：

我們分別用10個線程執行100次，50個線程執行1000次以及50個線程執行一百萬次來

從上面表格中我們可以看到，即時共享變量用volatile修飾了。但是隨著線程數量或者執行次數的增加，實際運行結果與預期結果相差越來越大。如果預期結果和運行結果一致則說明保證了原子性，但是從結果來看不是這樣的。從而證明了volatile的第二個特性：不能保證原子性。

為什么從i++的運行結果上就能看出不保證原子性呢？

我們來分析：

正常來說200個線程,每個線程執行了1000次。最后應該輸出的是：200*1000=20000.二十萬。但是實際結果卻不是二十萬次。那說明了什么呢？請看下圖：

說明:

主內存中有共享變量number的值是0，現在有4個CPU帶著4個線程都從主內存中copy變量到自己的工作區。這個是CPU1先競爭到然后再線程1的工作區中執行了number++.執行后將number的值更新成了1，寫回到主內存中了。這個時候正要或者正在通知其他CPU主內存中的number值變化了。CPU2和CPU3都收到通知了，將自己工作區的變量置為無效，重新從主內存獲取到number=1的值。這個時候CPU4執行的也快，在還沒有收到CPU1的通知的時候，就將自己運行后的number++的值也寫回到了主內存中。其實這個時候，cpu1線程1的操作還在進行中，但是因為cpu4線程4的操作打斷了線程1的操作。第一輪運行結果應該是4，但是因為線程4把線程1執行打斷了，將線程1執行結果覆蓋了。所以實際執行后的效果有可能是3或者2但是不可能是4.

從上分析結果，我們更能理解到volatile修飾的共享變量不能保證原子性了。因為有可能被其他線程打斷執行。

怎么解決原子性問題呢？可以使用juc包下的atomic包下的對象就可以了。

Volatile的有序性證明，歡迎學習下一篇：《Java并發編程之驗證volatile指令重排-理論篇》

總結

以上是生活随笔為你收集整理的java volatile 原子性_Java中volatile不能保证原子性的证明的全部內容，希望文章能夠幫你解決所遇到的問題。

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