Java中JMM與volatile關(guān)鍵字的學(xué)習(xí)
JMM
JMM是指Java內(nèi)存模型，不是Java內(nèi)存布局，不是所謂的棧、堆、方法區(qū)。
每個(gè)Java線程都有自己的工作內(nèi)存。操作數(shù)據(jù)，首先從主內(nèi)存中讀，得到一份拷貝，操作完畢后再寫回到主內(nèi)存。
JMM可能帶來(lái)可見性、原子性和有序性問題。
1.可見性：指當(dāng)一個(gè)線程修改了某一個(gè)共享變量的值，其他線程是否能夠立即知道這個(gè)修改。顯然，對(duì)于串行程序來(lái)說(shuō)，可見性問題 是不存在。因?yàn)槟阍谌魏我粋€(gè)操作步驟中修改某個(gè)變量，那么在后續(xù)的步驟中，讀取這個(gè)變量的值，一定是修改后的新值。但是這個(gè)問題在并行程序中就不見得了。如果一個(gè)線程修改了某一個(gè)全局變量，那么其他線程未必可以馬上知道這個(gè)改動(dòng)。
2.原子性：指一個(gè)操作是不可中斷的，即使是多個(gè)線程一起執(zhí)行的時(shí)候，一個(gè)線程操作一旦開始，就不會(huì)被其他線程干擾比如，對(duì)于一個(gè)靜態(tài)全局變量int i，兩個(gè)線程同時(shí)對(duì)它賦值，線程A 給他賦值 1，線程 B 給它賦值為 -1,。那么不管這兩個(gè)線程以何種方式，何種步調(diào)工作，i的值要么是1，要么是-1，線程A和線程B之間是沒有干擾的。這就是原子性的一個(gè)特點(diǎn)，不可被中斷。
3.有序性：對(duì)于一個(gè)線程的執(zhí)行代碼而言，我們總是習(xí)慣地認(rèn)為代碼的執(zhí)行時(shí)從先往后，依次執(zhí)行的。這樣的理解也不能說(shuō)完全錯(cuò)誤，因?yàn)榫鸵粋€(gè)線程而言，確實(shí)會(huì)這樣。但是在并發(fā)時(shí)，程序的執(zhí)行可能就會(huì)出現(xiàn)亂序。給人直觀的感覺就是：寫在前面的代碼，會(huì)在后面執(zhí)行。有序性問題的原因是因?yàn)槌绦蛟趫?zhí)行時(shí)，可能會(huì)進(jìn)行指令重排，重排后的指令與原指令的順序未必一致。
volatile關(guān)鍵字
volatile關(guān)鍵字是Java提供的一種輕量級(jí)同步機(jī)制。它能夠保證可見性和有序性，但是不能保證原子性。
可見性與原子性測(cè)試
class MyData{
int number=0;
//volatile int number=0;
AtomicInteger atomicInteger=new AtomicInteger();
public void setTo60(){
this.number=60;
}
//此時(shí)number前面已經(jīng)加了volatile，但是不保證原子性
public void addPlusPlus(){
number++;
}
public void addAtomic(){
atomicInteger.getAndIncrement();
}
}
//volatile可以保證可見性，及時(shí)通知其它線程主物理內(nèi)存的值已被修改
private static void volatileVisibilityDemo() {
System.out.println("可見性測(cè)試");
MyData myData=new MyData();//資源類
//啟動(dòng)一個(gè)線程操作共享數(shù)據(jù)
new Thread(()->{
System.out.println(Thread.currentThread().getName()+"\t come in");
try {TimeUnit.SECONDS.sleep(3);myData.setTo60();
System.out.println(Thread.currentThread().getName()+"\t update number value: "+myData.number);}catch (InterruptedException e){e.printStackTrace();}
},"AAA").start();
while (myData.number==0){
//main線程持有共享數(shù)據(jù)的拷貝，一直為0
}
System.out.println(Thread.currentThread().getName()+"\t mission is over. main get number value: "+myData.number);
}
可見性：
MyData類是資源類，一開始number變量沒有用volatile修飾，所以程序運(yùn)行的結(jié)果是：
可見性測(cè)試
AAA come in
AAA update number value: 60
雖然"AAA"線程把number修改成了60，但是main線程持有的仍然是最開始的0，所以一直循環(huán)，程序不會(huì)結(jié)束。
如果對(duì)number添加了volatile修飾，運(yùn)行結(jié)果是：
AAA come in
AAA update number value: 60
main mission is over. main get number value: 60
可見某個(gè)線程對(duì)number的修改，會(huì)立刻反映到主內(nèi)存上。
原子性：
volatile并不能保證操作的原子性。這是因?yàn)?，比如一條number++的操作，底層會(huì)形成3條指令。
getfield //讀 iconst_1 //++常量1 iadd //加操作 putfield //寫操作
假設(shè)有3個(gè)線程，分別執(zhí)行number++，都先從主內(nèi)存中拿到最開始的值，number=0，然后三個(gè)線程分別進(jìn)行操作。假設(shè)線程A執(zhí)行完畢，number=1，也立刻通知到了其它線程，但是此時(shí)線程B、C已經(jīng)拿到了number=0，所以結(jié)果就是寫覆蓋，線程B、C將number變成1。
解決的辦法就是：
- 對(duì)
addPlusPlus()方法加鎖。 - 使用
java.util.concurrent.AtomicInteger類。
private static void atomicDemo() {
System.out.println("原子性測(cè)試");
MyData myData=new MyData();
for (int i = 1; i <= 20; i++) {
new Thread(()->{
for (int j = 0; j <1000 ; j++) {
myData.addPlusPlus();
myData.addAtomic();
}
},String.valueOf(i)).start();
}
while (Thread.activeCount()>2){
Thread.yield();
}
System.out.println(Thread.currentThread().getName()+"\t int type finally number value: "+myData.number);
System.out.println(Thread.currentThread().getName()+"\t AtomicInteger type finally number value: "+myData.atomicInteger);
}
結(jié)果：可見，由于volatile不能保證原子性，出現(xiàn)了線程重復(fù)寫的問題，最終結(jié)果比20000小。而AtomicInteger可以保證原子性。
原子性測(cè)試 main int type finally number value: 17542 main AtomicInteger type finally number value: 20000
有序性：
volatile可以保證有序性，也就是防止指令重排序。所謂指令重排序，就是出于優(yōu)化考慮，CPU執(zhí)行指令的順序跟程序員自己編寫的順序不一致。就好比一份試卷，題號(hào)是老師規(guī)定的（代碼是程序員規(guī)定的），但是考生（CPU）可以先做選擇題，也可以先做填空題。
但是有時(shí)候這種情況就會(huì)出現(xiàn)問題：
int x = 11; //語(yǔ)句1 int y = 12; //語(yǔ)句2 x = x + 5; //語(yǔ)句3 y = x * x; //語(yǔ)句4
以上例子，可能出現(xiàn)的執(zhí)行順序有1234、2134、1342，這三個(gè)都沒有問題，最終結(jié)果都是x = 16，y=256。但是如果是4開頭，就有問題了，y=0。這個(gè)時(shí)候就不需要指令重排序。
哪些地方用到過volatile？
單例模式的安全問題
常見的DCL（Double Check Lock）模式雖然加了同步，但是在多線程下依然會(huì)有線程安全問題。
public class SingletonDemo {
private static SingletonDemo singletonDemo=null;
private SingletonDemo(){
System.out.println(Thread.currentThread().getName()+"\t 我是構(gòu)造方法");
}
//DCL模式 Double Check Lock 雙端檢索機(jī)制：在加鎖前后都進(jìn)行判斷
public static SingletonDemo getInstance(){
if (singletonDemo==null){
synchronized (SingletonDemo.class){
if (singletonDemo==null){
singletonDemo=new SingletonDemo();
}
}
}
return singletonDemo;
}
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
new Thread(()->{
SingletonDemo.getInstance();
},String.valueOf(i+1)).start();
}
}
}
這個(gè)漏洞比較tricky，很難捕捉，但是是存在的。instance=new SingletonDemo();可以大致分為三步：
memory = allocate(); //1.分配內(nèi)存 instance(memory); //2.初始化對(duì)象 instance = memory; //3.設(shè)置引用地址
由于Java編譯器允許處理器亂序執(zhí)行，以及JDK1.5之前JMM（Java Memory Medel，即Java內(nèi)存模型）中Cache、寄存器到主內(nèi)存回寫順序的規(guī)定，上面的第二點(diǎn)和第三點(diǎn)的順序是無(wú)法保證的，也就是說(shuō)，執(zhí)行順序可能是1-2-3也可能是1-3-2，如果是后者，并且在3執(zhí)行完畢、2未執(zhí)行之前，被切換到線程B上，這時(shí)候instance因?yàn)橐呀?jīng)在線程A內(nèi)執(zhí)行過了第三點(diǎn)，instance已經(jīng)是非空了，所以線程B直接拿走instance，然后使用，然后順理成章地報(bào)錯(cuò)，而且這種難以跟蹤難以重現(xiàn)的錯(cuò)誤很可能會(huì)隱藏很久。
解決的方法就是對(duì)singletondemo對(duì)象添加上volatile關(guān)鍵字，禁止指令重排。
你知道CAS嗎？
CAS是指Compare And Swap，比較并交換，是一種很重要的同步思想。如果主內(nèi)存的值跟期望值一樣，那么就進(jìn)行修改，否則一直重試，直到一致為止。
public class CASDemo {
public static void main(String[] args) {
AtomicInteger atomicInteger=new AtomicInteger(5);
System.out.println(atomicInteger.compareAndSet(5, 2021)+"\t current data : "+ atomicInteger.get());
//修改失敗
System.out.println(atomicInteger.compareAndSet(5, 1024)+"\t current data : "+ atomicInteger.get());
}
}
第一次修改，期望值為5，主內(nèi)存也為5，主內(nèi)存的值修改成功，為2021；第二次修改，期望值為5，主內(nèi)存實(shí)際值為2021，修改失敗。
CAS底層原理
public final int getAndIncrement(){
return unsafe.getAndAddInt(this,valueOffset,1);
}
查看AtomicInteger.getAndIncrement()方法，發(fā)現(xiàn)其沒有加synchronized也實(shí)現(xiàn)了同步。這是為什么？
AtomicInteger內(nèi)部維護(hù)了volatile int value和private static final Unsafe unsafe兩個(gè)比較重要的參數(shù)。
AtomicInteger.getAndIncrement()調(diào)用了Unsafe.getAndAddInt()方法。Unsafe類的大部分方法都是native的，用來(lái)像C語(yǔ)言一樣從底層操作內(nèi)存。
public final int getAnddAddInt(Object var1,long var2,int var4){
int var5;
do{
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
這個(gè)方法的var1和var2，就是根據(jù)對(duì)象和偏移量得到在主內(nèi)存的快照值var5。然后compareAndSwapInt方法通過var1和var2得到當(dāng)前主內(nèi)存的實(shí)際值。如果這個(gè)實(shí)際值跟快照值相等，那么就更新主內(nèi)存的值為var5+var4。如果不等，那么就一直循環(huán)，一直獲取快照，一直對(duì)比，直到實(shí)際值和快照值相等為止。
比如有A、B兩個(gè)線程，一開始都從主內(nèi)存中拷貝了原值為3，A線程執(zhí)行到var5=this.getIntVolatile，即var5=3。此時(shí)A線程掛起，B修改原值為4，B線程執(zhí)行完畢，由于加了volatile，所以這個(gè)修改是立即可見的。A線程被喚醒，執(zhí)行this.compareAndSwapInt()方法，發(fā)現(xiàn)這個(gè)時(shí)候主內(nèi)存的值不等于快照值3，所以繼續(xù)循環(huán)，重新從主內(nèi)存獲取。
CAS缺點(diǎn)
CAS實(shí)際上是一種自旋鎖
- 一直循環(huán)等待，開銷比較大。
- 只能保證一個(gè)變量的原子操作，多個(gè)變量依然要加鎖。
- 引出ABA問題。
ABA問題
所謂的ABA問題，就是比較并交換的循環(huán)，存在一個(gè)時(shí)間差，而這個(gè)時(shí)間差可能帶來(lái)意想不到的問題。比如線程T1將一個(gè)值從A改為B，然后又從B改為A。當(dāng)線程T2訪問時(shí)，看到的就是A，但是卻不知道這個(gè)A其實(shí)發(fā)生了更改。盡管線程T2 CAS操作成功，但是不代表就沒有問題。
有的需求，比如CAS，只注重頭尾（只看期望值和實(shí)際值），只要首尾一致就接受。但是有的需求，還看重過程，中間不能發(fā)生任何修改，這就引出了AtomicReference：原子引用。
AtomicReference
AtomicInteger對(duì)整數(shù)進(jìn)行原子操作，但是如果對(duì)象是一個(gè)POJO呢？我們這時(shí)就可以使用AtomicReference來(lái)包裝這個(gè)POJO，使其操作原子化。
User user1 = new User("Jack",25);
User user2 = new User("Lucy",21);
AtomicReference<User> atomicReference = new AtomicReference<>();
atomicReference.set(user1);
System.out.println(atomicReference.compareAndSet(user1,user2)); // true
System.out.println(atomicReference.compareAndSet(user1,user2)); //false
AtomicStampedReference和ABA問題的解決
使用AtomicStampedReference類可以解決ABA問題。這個(gè)類維護(hù)了一個(gè)版本號(hào)Stamp，在進(jìn)行CAS操作的時(shí)候，不僅要比較當(dāng)前值，還要比較版本號(hào)。只有兩者都相等，才能執(zhí)行更新操作。
AtomicStampedReference.compareAndSet(expectedReference,newReference,oldStamp,newStamp);
使用實(shí)例：
package thread;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.atomic.AtomicStampedReference;
public class ABADemo {
static AtomicReference<Integer> atomicReference = new AtomicReference<>(100);
static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(100, 1);
public static void main(String[] args) {
System.out.println("======ABA問題的產(chǎn)生======");
new Thread(() -> {
atomicReference.compareAndSet(100, 101);
atomicReference.compareAndSet(101, 100);
}, "t1").start();
new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(atomicReference.compareAndSet(100, 2019) + "\t" + atomicReference.get().toString());
}, "t2").start();
try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println("======ABA問題的解決======");
new Thread(() -> {
int stamp = atomicStampedReference.getStamp();
System.out.println(Thread.currentThread().getName() + "\t第一次版本號(hào)： " + stamp);
try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
atomicStampedReference.compareAndSet(100,101,
atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
System.out.println(Thread.currentThread().getName() + "\t第二次版本號(hào)： " + atomicStampedReference.getStamp());
atomicStampedReference.compareAndSet(101,100,
atomicStampedReference.getStamp(),atomicStampedReference.getStamp()+1);
System.out.println(Thread.currentThread().getName() + "\t第三次版本號(hào)： " + atomicStampedReference.getStamp());
}, "t3").start();
new Thread(() -> {
int stamp = atomicStampedReference.getStamp();
System.out.println(Thread.currentThread().getName() + "\t第一次版本號(hào)： " + stamp);
try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
boolean result=atomicStampedReference.compareAndSet(100,2019,
stamp,stamp+1);
System.out.println(Thread.currentThread().getName()+"\t修改成功與否："+result+" 當(dāng)前最新版本號(hào)"+atomicStampedReference.getStamp());
System.out.println(Thread.currentThread().getName()+"\t當(dāng)前實(shí)際值："+atomicStampedReference.getReference());
}, "t4").start();
}
}
總結(jié)
總結(jié)來(lái)源于GitHub，內(nèi)部帶有源碼和用例圖。
本篇文章就到這里了，希望能夠給你帶來(lái)幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！
相關(guān)文章
Java中的runnable 和 callable 區(qū)別解析
Runnable接口用于定義不需要返回結(jié)果的任務(wù),而Callable接口可以返回結(jié)果并拋出異常,通常與Future結(jié)合使用,Runnable適用于簡(jiǎn)單的后臺(tái)任務(wù)和定時(shí)任務(wù),而Callable適用于并行計(jì)算、異步操作和復(fù)雜任務(wù),選擇使用哪個(gè)接口取決于具體的應(yīng)用場(chǎng)景,感興趣的朋友一起看看吧2025-03-03
這篇文章主要介紹了SpringMVC之異常處理解讀，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2023-03-03
小編做題遇到了大數(shù)的精確計(jì)算，再次認(rèn)識(shí)了bigdecimal關(guān)于Bigdecimal意外的有許多小知識(shí)點(diǎn)和坑，這里特此整理一下為方便以后學(xué)習(xí)，希望能幫助到其他的萌新2021-08-08
使用MyBatis進(jìn)行簡(jiǎn)單的更新與查詢方式
這篇文章主要介紹了使用MyBatis進(jìn)行簡(jiǎn)單的更新與查詢方式，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2022-10-10
Java實(shí)現(xiàn)最小生成樹MST的兩種解法
最小生成樹（MST）指在連通圖的所有生成樹中，所有邊的權(quán)值和最小的生成樹。本文介紹了求最小生成樹的兩種方法：Prim算法和Kruskal算法，需要的可以參考一下2022-05-05
關(guān)于通過java調(diào)用datax,返回任務(wù)執(zhí)行的方法
今天小編就為大家分享一篇關(guān)于通過java調(diào)用datax,返回任務(wù)執(zhí)行的方法，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過來(lái)看看吧2019-08-08
Spring中allowedOriginPatterns和allowedOrigins方法有何不同詳解
這篇文章主要給大家介紹了關(guān)于Spring中allowedOriginPatterns和allowedOrigins方法有何不同,allowedOriginPatterns和allowedOrigins都是用來(lái)設(shè)置允許跨域請(qǐng)求的來(lái)源,需要的朋友可以參考下2023-10-10
Spring?Boot中獲取request的三種方式及請(qǐng)求過程
這篇文章主要介紹了Spring?Boot當(dāng)中獲取request的三種方式,包括請(qǐng)求過程流程分析及response常用API，本文通過實(shí)例代碼給大家介紹的非常詳細(xì)，需要的朋友可以參考下2022-03-03
Java如何通過線程解決生產(chǎn)者/消費(fèi)者問題
這篇文章主要介紹了Java如何通過線程解決生產(chǎn)者/消費(fèi)者問題，幫助大家更好的理解和使用Java，感興趣的朋友可以了解下2020-10-10
這篇文章主要介紹了java 實(shí)現(xiàn)圖片合成，并添加文字的示例，幫助大家更好的利用Java處理圖片，感興趣的朋友可以了解下2020-12-12