對volatile,看到了個很清楚的解釋,摘錄下來如下:
volatile關鍵字有什么用?
恐怕比較一下volatile和synchronized的不同是最容易解釋清楚的。volatile是變量修飾符,而synchronized則作用于一段代碼或方法;看如下三句get代碼:
- inti1; intgeti1(){returni1;}
- volatile inti2; intgeti2(){returni2;}
- int i3; synchronizedintgeti3(){returni3;}
geti1()得到存儲在當前線程中i1的數值。多個線程有多個i1變量拷貝,而且這些i1之間可以互不相同。換句話說,另一個線程可能已經改
變了它線程內的i1值,而這個值可以和當前線程中的i1值不相同。事實上,Java有個思想叫“主”內存區域,這里存放了變量目前的“準確值”。每個線程
可以有它自己的變量拷貝,而這個變量拷貝值可以和“主”內存區域里存放的不同。因此實際上存在一種可能:“主”內存區域里的i1值是1,線程1里的i1值
是2,線程2里的i1值是3——這在線程1和線程2都改變了它們各自的i1值,而且這個改變還沒來得及傳遞給“主”內存區域或其他線程時就會發生。
而geti2()得到的是“主”內存區域的i2數值。用volatile修飾后的變量不允許有不同于“主”內存區域的變量拷貝。換句話說,一個變量經
volatile修飾后在所有線程中必須是同步的;任何線程中改變了它的值,所有其他線程立即獲取到了相同的值。理所當然的,volatile修飾的變量
存取時比一般變量消耗的資源要多一點,因為線程有它自己的變量拷貝更為高效。
既然volatile關鍵字已經實現了線程間數據同步,又要synchronized干什么呢?呵呵,它們之間有兩點不同。首
先,synchronized獲得并釋放監視器——如果兩個線程使用了同一個對象鎖,監視器能強制保證代碼塊同時只被一個線程所執行——這是眾所周知的事
實。但是,synchronized也同步內存:事實上,synchronized在“主”內存區域同步整個線程的內存。因此,執行geti3()方法做
了如下幾步:
1. 線程請求獲得監視this對象的對象鎖(假設未被鎖,否則線程等待直到鎖釋放)
2. 線程內存的數據被消除,從“主”內存區域中讀入(Java虛擬機能優化此步。。。[后面的不知道怎么表達,汗])
3. 代碼塊被執行
4. 對于變量的任何改變現在可以安全地寫到“主”內存區域中(不過geti3()方法不會改變變量值)
5. 線程釋放監視this對象的對象鎖
因此volatile只是在線程內存和“主”內存間同步某個變量的值,而synchronized通過鎖定和解鎖某個監視器同步所有變量的值。顯然synchronized要比volatile消耗更多資源。
附英文原文:
What does volatile do?
This is probably best explained by comparing the effects that
volatile and synchronized have on a method. volatile is a field
modifier, while synchronized modifies code blocks and methods. So we
can specify three variations of a simple accessor using those two
keywords:
- inti1; intgeti1(){returni1;}
- volatile inti2; intgeti2(){returni2;}
- int i3; synchronizedintgeti3(){returni3;}
geti1() accesses the value currently stored in i1 in the current
thread. Threads can have local copies of variables, and the data does
not have to be the same as the data held in other threads. In
particular, another thread may have updated i1 in it’s thread, but the
value in the current thread could be different from that updated value.
In fact Java has the idea of a “main” memory, and this is the memory
that holds the current “correct” value for variables. Threads can have
their own copy of data for variables, and the thread copy can be
different from the “main” memory. So in fact, it is possible for the
“main” memory to have a value of 1 for i1, for thread1 to have a value
of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and
thread2 have both updated i1 but those updated value has not yet been
propagated to “main” memory or other threads.
On the other hand, geti2() effectively accesses the value of i2 from
“main” memory. A volatile variable is not allowed to have a local copy
of a variable that is different from the value currently held in “main”
memory. Effectively, a variable declared volatile must have it’s data
synchronized across all threads, so that whenever you access or update
the variable in any thread, all other threads immediately see the same
value. Of course, it is likely that volatile variables have a higher
access and update overhead than “plain” variables, since the reason
threads can have their own copy of data is for better efficiency.
Well if volatile already synchronizes data across threads, what is
synchronized for? Well there are two differences. Firstly synchronized
obtains and releases locks on monitors which can force only one thread
at a time to execute a code block, if both threads use the same monitor
(effectively the same object lock). That’s the fairly well known aspect
to synchronized. But synchronized also synchronizes memory. In fact
synchronized synchronizes the whole of thread memory with “main”
memory. So executing geti3() does the following:
1. The thread acquires the lock on the monitor for object this
(assuming the monitor is unlocked, otherwise the thread waits until the
monitor is unlocked).
2. The thread memory flushes all its variables, i.e. it has all of its
variables effectively read from “main” memory (JVMs can use dirty sets
to optimize this so that only “dirty” variables are flushed, but
conceptually this is the same. See section 17.9 of the Java language
specification).
3. The code block is executed (in this case setting the return value to
the current value of i3, which may have just been reset from “main”
memory).
4. (Any changes to variables would normally now be written out to “main” memory, but for geti3() we have no changes.)
5. The thread releases the lock on the monitor for object this.
So where volatile only synchronizes the value of one variable
between thread memory and “main” memory, synchronized synchronizes the
value of all variables between thread memory and “main” memory, and
locks and releases a monitor to boot. Clearly synchronized is likely to
have more overhead than volatile.
摘自:http://bianbian.org/technology/java/88.html