1. 程式人生 > >為什麼volatile不能保證原子性而Atomic可以?

為什麼volatile不能保證原子性而Atomic可以?

在上篇《非阻塞同步演算法與CAS(Compare and Swap)無鎖演算法》中講到在Java中long賦值不是原子操作,因為先寫32位,再寫後32位,分兩步操作,而AtomicLong賦值是原子操作,為什麼?為什麼volatile能替代簡單的鎖,卻不能保證原子性?這裡面涉及volatile,是java中的一個我覺得這個詞在Java規範中從未被解釋清楚的神奇關鍵詞,在Sun的JDK官方文件是這樣形容volatile的:

The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes. A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable.

意思就是說,如果一個變數加了volatile關鍵字,就會告訴編譯器和JVM的記憶體模型:這個變數是對所有執行緒共享的、可見的,每次jvm都會讀取最新寫入的值並使其最新值在所有CPU可見。volatile似乎是有時候可以代替簡單的鎖,似乎加了volatile關鍵字就省掉了鎖。但又說volatile不能保證原子性(java程式設計師很熟悉這句話:volatile僅僅用來保證該變數對所有執行緒的可見性,但不保證原子性)。這不是互相矛盾嗎?

不要將volatile用在getAndOperate場合,僅僅set或者get的場景是適合volatile的

不要將volatile用在getAndOperate場合(這種場合不原子,需要再加鎖),僅僅set或者get的場景是適合volatile的

volatile沒有原子性舉例:AtomicInteger自增

例如你讓一個volatile的integer自增(i++),其實要分成3步:1)讀取volatile變數值到local; 2)增加變數的值;3)把local的值寫回,讓其它的執行緒可見。這3步的jvm指令為:

mov    0xc(%r10),%r8d ; Load
inc    %r8d           ; Increment
mov    %r8d,0xc(%r10) ; Store
lock addl $0x0,(%rsp) ; StoreLoad Barrier

注意最後一步是記憶體屏障。

什麼是記憶體屏障(Memory Barrier)?

記憶體屏障(memory barrier)是一個CPU指令。基本上,它是這樣一條指令: a) 確保一些特定操作執行的順序; b) 影響一些資料的可見性(可能是某些指令執行後的結果)。編譯器和CPU可以在保證輸出結果一樣的情況下對指令重排序,使效能得到優化。插入一個記憶體屏障,相當於告訴CPU和編譯器先於這個命令的必須先執行,後於這個命令的必須後執行。記憶體屏障另一個作用是強制更新一次不同CPU的快取。例如,一個寫屏障會把這個屏障前寫入的資料重新整理到快取,這樣任何試圖讀取該資料的執行緒將得到最新值,而不用考慮到底是被哪個cpu核心或者哪顆CPU執行的。

記憶體屏障(memory barrier)和volatile什麼關係?上面的虛擬機器指令裡面有提到,如果你的欄位是volatile,Java記憶體模型將在寫操作後插入一個寫屏障指令,在讀操作前插入一個讀屏障指令。這意味著如果你對一個volatile欄位進行寫操作,你必須知道:1、一旦你完成寫入,任何訪問這個欄位的執行緒將會得到最新的值。2、在你寫入前,會保證所有之前發生的事已經發生,並且任何更新過的資料值也是可見的,因為記憶體屏障會把之前的寫入值都重新整理到快取。

volatile為什麼沒有原子性?

明白了記憶體屏障(memory barrier)這個CPU指令,回到前面的JVM指令:從Load到store到記憶體屏障,一共4步,其中最後一步jvm讓這個最新的變數的值在所有執行緒可見,也就是最後一步讓所有的CPU核心都獲得了最新的值,但中間的幾步(從Load到Store)是不安全的,中間如果其他的CPU修改了值將會丟失。下面的測試程式碼可以實際測試voaltile的自增沒有原子性:

    private static volatile long _longVal = 0;
    
	private static class LoopVolatile implements Runnable {
		public void run() {
			long val = 0;
			while (val < 10000000L) {
				_longVal++;
				val++;
			}
		}
	}
	
	private static class LoopVolatile2 implements Runnable {
		public void run() {
			long val = 0;
			while (val < 10000000L) {
				_longVal++;
				val++;
			}
		}
	}
	
	private  void testVolatile(){
	    Thread t1 = new Thread(new LoopVolatile());
		t1.start();
		
		Thread t2 = new Thread(new LoopVolatile2());
		t2.start();
		
        while (t1.isAlive() || t2.isAlive()) {
	    }

		System.out.println("final val is: " + _longVal);
	}

Output:-------------
	
final val is: 11223828
final val is: 17567127
final val is: 12912109

volatile沒有原子性舉例:singleton單例模式實現

這是一段執行緒不安全的singleton(單例模式)實現,儘管使用了volatile:

public class wrongsingleton {
	private static volatile wrongsingleton _instance = null; 

	private wrongsingleton() {}

	public static wrongsingleton getInstance() {

		if (_instance == null) {
			_instance = new wrongsingleton();
		}

		return _instance;
	}
}

下面的測試程式碼可以測試出是執行緒不安全的:

public class wrongsingleton {
	private static volatile wrongsingleton _instance = null; 

	private wrongsingleton() {}

	public static wrongsingleton getInstance() {

		if (_instance == null) {
			_instance = new wrongsingleton();
			System.out.println("--initialized once.");
		}

		return _instance;
	}
}

private static void testInit(){
		
		Thread t1 = new Thread(new LoopInit());
		Thread t2 = new Thread(new LoopInit2());
		Thread t3 = new Thread(new LoopInit());
		Thread t4 = new Thread(new LoopInit2());
		t1.start();
		t2.start();
		t3.start();
		t4.start();
		
        while (t1.isAlive() || t2.isAlive() || t3.isAlive()|| t4.isAlive()) {
			
        }

	}
輸出:有時輸出"--initialized once."一次,有時輸出好幾次

原因自然和上面的例子是一樣的。因為volatile保證變數對執行緒的可見性,但不保證原子性

附:正確執行緒安全的單例模式寫法:

@ThreadSafe 
public class SafeLazyInitialization { 
   private static Resource resource; 
   public synchronized static Resource getInstance() { 
      if (resource == null) 
          resource = new Resource(); 
      return resource; 
    } 
} 

另外一種寫法:

@ThreadSafe 
public class EagerInitialization { 
  private static Resource resource = new Resource(); 
  public static Resource getResource() { return resource; } 
}

延遲初始化的寫法:

@ThreadSafe 
public class ResourceFactory { 
	private static class ResourceHolder { 
		public static Resource resource = new Resource(); 
	} 
	public static Resource getResource() { 
		return ResourceHolder.resource ; 
	} 
}

二次檢查鎖定/Double Checked Locking的寫法(反模式)

public class SingletonDemo {
	private static volatile SingletonDemo instance = null;//注意需要volatile
 
	private SingletonDemo() {	}
 
	public static SingletonDemo getInstance() {
		if (instance == null) { //二次檢查,比直接用獨佔鎖效率高
               synchronized (SingletonDemo .class){
			        if (instance == null) {
                               instance = new SingletonDemo (); 
                    }
             }
		}
		return instance;
	}
}

為什麼AtomicXXX具有原子性和可見性?

就拿AtomicLong來說,它既解決了上述的volatile的原子性沒有保證的問題,又具有可見性。它是如何做到的?當然就是上文《非阻塞同步演算法與CAS(Compare and Swap)無鎖演算法》提到的CAS(比較並交換)指令。 其實AtomicLong的原始碼裡也用到了volatile,但只是用來讀取或寫入,見原始碼:

public class AtomicLong extends Number implements java.io.Serializable {
    private volatile long value;

    /**
     * Creates a new AtomicLong with the given initial value.
     *
     * @param initialValue the initial value
     */
    public AtomicLong(long initialValue) {
        value = initialValue;
    }

    /**
     * Creates a new AtomicLong with initial value {@code 0}.
     */
    public AtomicLong() {
    }

其CAS原始碼核心程式碼為:

int compare_and_swap (int* reg, int oldval, int newval) 
{
  ATOMIC();
  int old_reg_val = *reg;
  if (old_reg_val == oldval) 
     *reg = newval;
  END_ATOMIC();
  return old_reg_val;
}

虛擬機器指令為:

mov    0xc(%r11),%eax       ; Load
mov    %eax,%r8d            
inc    %r8d                 ; Increment
lock cmpxchg %r8d,0xc(%r11) ; Compare and exchange

因為CAS是基於樂觀鎖的,也就是說當寫入的時候,如果暫存器舊值已經不等於現值,說明有其他CPU在修改,那就繼續嘗試。所以這就保證了操作的原子性。

ConcurrencyCAS

相關推薦

為什麼volatile不能保證原子Atomic可以?

在上篇《非阻塞同步演算法與CAS(Compare and Swap)無鎖演算法》中講到在Java中long賦值不是原子操作,因為先寫32位,再寫後32位,分兩步操作,而AtomicLong賦值是原子操作,為什麼?為什麼volatile能替代簡單的鎖,卻不能保證原子性?這裡面涉及volatile,是java中的

為什麼volatile不能保證原子Atomic可以?(r)

在上篇《非阻塞同步演算法與CAS(Compare and Swap)無鎖演算法》中講到在Java中long賦值不是原子操作,因為先寫32位,再寫後32位,分兩步操作,而AtomicLong賦值是原子操作,為什麼?為什麼volatile能替代簡單的鎖,卻不能保證原子性?

深入理解Atomic原子操作和volatile原子

log tile 修飾 深入 clas 同時 結果 一個 body 原子操作可以理解為: 一個數,很多線程去同時修改它,不加sync同步鎖,就可以保證修改結果是正確的 Atomic正是采用了CAS算法,所以可以在多線程環境下安全地操作對象。 volatile是Java的關鍵

volatile不能保證原子,也就不能保證執行緒安全

volatile只能保證變數的可見性,無法保證對變數的操作的原子性。 還是以最常用的i++來說吧,包含3個步驟 1,從記憶體讀取i當前的值 2,加1 3,把修改後的值重新整理到記憶體 對於普通變數來說多執行緒下1,2之間被中斷,其

volatile為什麼不能保證原子的思考

1、故事的起因:         前幾天有人問過關於volatile關鍵字的一些問題, 想起了自己剛接觸這個關鍵字時候存在的疑惑,趕上今天有時間就整理了一些自己的想法。         首先,需要明確的一點是,volatile關鍵字修飾的變數可以保證該變數操作的有序性和可

volatile 可以保證可見,但不能保證原子

轉自:http://blog.csdn.net/shukebai/article/details/51163068 在Java執行緒併發處理中,有一個關鍵字volatile的使用目前存在很大的混淆,以為使用這個關鍵字,在進行多執行緒併發處理的時候就可以萬事大吉。 J

Java併發程式設計之驗證volatile不能保證原子

Java併發程式設計之驗證volatile不能保證原子性 通過系列文章的學習,凱哥已經介紹了volatile的三大特性。1:保證可見性 2:不保證原子性 3:保證順序。那麼怎麼來驗證可見性呢?本文凱哥(凱哥Java:kaigejava)將通過程式碼演示來證明為什麼說volatile不能夠保證共享變數的原子性操

Volatile保證原子(二)

Volatile不保證原子性 前言 通過前面對JMM的介紹,我們知道,各個執行緒對主記憶體中共享變數的操作都是各個執行緒各自拷貝到自己的工作記憶體進行操作後在寫回到主記憶體中的。 這就可能存在一個執行緒AAA修改了共享變數X的值,但是還未寫入主記憶體時,另外一個執行緒BBB又對主記憶體中同一共享變數X進行操作

Java關鍵字volatile原子,變數可見

The volatile keyword also ensures visibility across the application. If you declare a field to be volatile, this means that as soon as a write occurs for t

編寫安全程式碼:小心volatile原子誤解

這時,exit_flag都需要使用volatile來修飾。不然對於執行緒1的程式碼,如果編譯器發現線上程1的程式碼中沒有任何地方修改exit_flag,有可能會將exit_flag放入暫存器快取。這樣,在每次的條件檢查的時候,都是從暫存器中讀取,而非exit_flag對應的記憶體。這樣將導致每次讀取的值都為0

volatile是非原子 AtomicInteger原子

import java.util.concurrent.atomic.AtomicInteger; /*  * volatile不是原子性的,它只保證變數在多執行緒中可見,操作時並不是執行緒安全的  * AtomicInteger 是原子性的  */ public clas

atomic保證記憶體變數的原子

import java.util.concurrent.atomic.AtomicInteger; /** * *atomic保證原子性的操作 */ public class TestAtomic { /** * 原子性 * AtomicInteger 可以保證原子操

volatile不能保證程式執行的原子以及只能一定程度上保證有序性

多執行緒併發程式設計如何正確的執行程式: 1、原子性:執行過程要麼成功要麼失敗,比如經典的銀行轉賬問題。 2、可見性:多執行緒併發時,一個執行緒修改了工作記憶體中的值(主存中的值),會立刻改變主存相應地址的值,其它執行緒工作記憶體的值無效,重新獲取主存的值。 3、有序性:程

Java線程安全 關於原子volatile的試驗

har length rgs 無法 over pub boolean 即使 dex 1. 變量遞增試驗 1 static /*volatile*/ int shared=0;//volatile也無法保證++操作的原子性 2 static synchr

Java-JUC(二):volatile對Java內存模型中的可見原子、有序性影響

UC volatil 可見 模型 原子性 有序性 juc 內存模型 volatile Java內存模型 Java內存模型-可見性 Java內存模型-原子性 Java內存模型-有序性 volatile-是否具有可見性? volatile

java併發程式設計之利用CAS保證操作的原子

import java.util.ArrayList; import java.util.List; import java.util.concurrent.atomic.AtomicInteger; public class Counter { private AtomicInteger at

volatile分析i++和++i非原子問題

目錄 1、可見性(Visibility) 2、原子性(Atomicity) 3、Java記憶體模型的抽象結構( JMM ) 4、volatile   5、 多執行緒下的i++問題 5、自定義實現i++原子操作 5.1   

Java併發程式設計:volatile關鍵字解析-原子,可見,有序性

volatile這個關鍵字可能很多朋友都聽說過,或許也都用過。在Java 5之前,它是一個備受爭議的關鍵字,因為在程式中使用它往往會導致出人意料的結果。在Java 5之後,volatile關鍵字才得以重獲生機。   volatile關鍵字雖然從字面上理解起來比較簡單,但是要用好不是一件容易的事情

synchronized和volatile——原子和可見

<div class="htmledit_views"> <h1 style="color:rgb(51,51,51);font-family:Arial;line-height:26px;text-align:center

redis實現秒殺功能例子(採用lua的原子保證資料的一致性)

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.core.RedisTemplate; import org.spring