前言

Java并發(fā)編程系列開坑了，Java并發(fā)編程可以說是中高級研發(fā)工程師的必備素養(yǎng)，也是中高級崗位面試必問的問題，本系列就是為了帶讀者們系統(tǒng)的一步一步擊破Java并發(fā)編程各個(gè)難點(diǎn)，打破屏障，在面試中所向披靡，拿到心儀的offer，Java并發(fā)編程系列文章依然采用圖文并茂的風(fēng)格，讓小白也能秒懂。

Java內(nèi)存模型（Java Memory Model）簡稱J M M，作為Java并發(fā)編程系列的開篇，它是Java并發(fā)編程的基礎(chǔ)知識，理解它能讓你更好的明白線程安全到底是怎么一回事。

內(nèi)容大綱

硬件內(nèi)存模型

程序是指令與數(shù)據(jù)的集合，計(jì)算機(jī)執(zhí)行程序時(shí)，是C P U在執(zhí)行每條指令，因?yàn)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(255, 100, 65);">C P U要從內(nèi)存讀指令，又要根據(jù)指令指示去內(nèi)存讀寫數(shù)據(jù)做運(yùn)算，所以執(zhí)行指令就免不了與內(nèi)存打交道，早期內(nèi)存讀寫速度與C P U處理速度差距不大，倒沒什么問題。

C P U緩存

隨著C P U技術(shù)快速發(fā)展，C P U的速度越來越快，內(nèi)存卻沒有太大的變化，導(dǎo)致內(nèi)存的讀寫（IO）速度與C P U的處理速度差距越來越大，為了解決這個(gè)問題，引入了緩存（Cache）的設(shè)計(jì)，在C P U與內(nèi)存之間加上緩存層，這里的緩存層就是指C P U內(nèi)的寄存器與高速緩存（L1,L2,L3）

從上圖中可以看出，寄存器最快，主內(nèi)最慢，越快的存儲(chǔ)空間越小，離C P U越近，相反存儲(chǔ)空間越大速度越慢，離C P U越遠(yuǎn)。

C P U如何與內(nèi)存交互

C P U運(yùn)行時(shí)，會(huì)將指令與數(shù)據(jù)從主存復(fù)制到緩存層，后續(xù)的讀寫與運(yùn)算都是基于緩存層的指令與數(shù)據(jù)，運(yùn)算結(jié)束后，再將結(jié)果從緩存層寫回主存。

上圖可以看出，C P U基本都是在和緩存層打交道，采用緩存設(shè)計(jì)彌補(bǔ)主存與C P U處理速度的差距，這種設(shè)計(jì)不僅僅體現(xiàn)在硬件層面，在日常開發(fā)中，那些并發(fā)量高的業(yè)務(wù)場景都能看到，但是凡事都有利弊，緩存雖然加快了速度，同樣也帶來了在多線程場景存在的緩存一致性問題，關(guān)于緩存一致性問題后面會(huì)說，這里大家留個(gè)印象。

Java內(nèi)存模型

Java內(nèi)存模型（Java Memory Model，J M M），后續(xù)都以J M M簡稱，J M M 是建立在硬件內(nèi)存模型基礎(chǔ)上的抽象模型，并不是物理上的內(nèi)存劃分，簡單說，為了使Java虛擬機(jī)(Java Virtual Machine，J V M)在各平臺(tái)下達(dá)到一致的內(nèi)存交互效果，需要屏蔽下游不同硬件模型的交互差異，統(tǒng)一規(guī)范，為上游提供統(tǒng)一的使用接口。

J M M是保證J V M在各平臺(tái)下對計(jì)算機(jī)內(nèi)存的交互都能保證效果一致的機(jī)制及規(guī)范。

抽象結(jié)構(gòu)

J M M抽象結(jié)構(gòu)劃分為線程本地緩存與主存，每個(gè)線程均有自己的本地緩存，本地緩存是線程私有的，主存則是計(jì)算機(jī)內(nèi)存，它是共享的。

不難發(fā)現(xiàn)J M M與硬件內(nèi)存模型差別不大，可以簡單的把線程類比成Core核心，線程本地緩存類比成緩存層，如下圖所示

雖然內(nèi)存交互規(guī)范好了，但是多線程場景必然存在線程安全問題（競爭共享資源），為了使多線程能正確的同步執(zhí)行，就需要保證并發(fā)的三大特性可見性、原子性、有序性。

可見性

當(dāng)一個(gè)線程修改了共享變量的值，其他線程能夠立即得知這個(gè)修改，這就是可見性，如果無法保證，就會(huì)出現(xiàn)緩存一致性的問題，J M M規(guī)定，所有的變量都放在主存中，當(dāng)線程使用變量時(shí)，先從緩存中獲取，緩存未命中，再從主存復(fù)制到緩存，最終導(dǎo)致線程操作的都是自己緩存中的變量。

線程A執(zhí)行流程

• 線程A從緩存獲取變量a
• 緩存未命中，從主存復(fù)制到緩存，此時(shí)a是0
• 線程A獲取變量a，執(zhí)行計(jì)算
• 計(jì)算結(jié)果1，寫入緩存
• 計(jì)算結(jié)果1，寫入主存

線程B執(zhí)行流程

• 線程B從緩存獲取變量a
• 緩存未命中，從主存復(fù)制到緩存，此時(shí)a是1
• 線程B獲取變量a，執(zhí)行計(jì)算
• 計(jì)算結(jié)果2，寫入緩存
• 計(jì)算結(jié)果2，寫入主存

A、B兩個(gè)線程執(zhí)行完后，線程A與線程B緩存數(shù)據(jù)不一致，這就是緩存一致性問題，一個(gè)是1，另一個(gè)是2，如果線程A再進(jìn)行一次+1操作，寫入主存的還是2，也就是說兩個(gè)線程對a共進(jìn)行了3次+1，期望的結(jié)果是3，最終得到的結(jié)果卻是2。

解決緩存一致性問題，就要保證可見性，思路也很簡單，變量寫入主存后，把其他線程緩存的該變量清空，這樣其他線程緩存未命中，就會(huì)去主存加載。

線程A執(zhí)行流程

• 線程A從緩存獲取變量a
• 緩存未命中，從主存復(fù)制到緩存，此時(shí)a是0
• 線程A獲取變量a，執(zhí)行計(jì)算
• 計(jì)算結(jié)果1，寫入緩存
• 計(jì)算結(jié)果1，寫入主存，并清空線程B緩存a變量

線程B執(zhí)行流程

• 線程B從緩存獲取變量a
• 緩存未命中，從主存復(fù)制到緩存，此時(shí)a是1
• 線程B獲取變量a，執(zhí)行計(jì)算
• 計(jì)算結(jié)果2，寫入緩存
• 計(jì)算結(jié)果2，寫入主存，并清空線程A緩存a變量

A、B兩個(gè)線程執(zhí)行完后，線程A緩存是空的，此時(shí)線程A再進(jìn)行一次+1操作，會(huì)從主存加載（先從緩存中獲取，緩存未命中，再從主存復(fù)制到緩存）得到2，最后寫入主存的是3，Java中提供了volatile修飾變量保證可見性（本文重點(diǎn)是J M M，所以不會(huì)對volatile做過多的解讀）。

看似問題都解決了，然而上面描述的場景是建立在理想情況（線程有序的執(zhí)行），實(shí)際中線程可能是并發(fā)（交替執(zhí)行），也可能是并行，只保證可見性仍然會(huì)有問題，所以還需要保證原子性。

原子性

原子性是指一個(gè)或者多個(gè)操作在C P U執(zhí)行的過程中不被中斷的特性，要么執(zhí)行，要不執(zhí)行，不能執(zhí)行到一半，為了直觀的了解什么是原子性，看看下面這段代碼

int a=0;
a++;

• 原子性操作：int a=0只有一步操作，就是賦值
• 非原子操作：a++有三步操作，讀取值、計(jì)算、賦值

如果多線程場景進(jìn)行a++操作，僅保證可見性，沒有保證原子性，同樣會(huì)出現(xiàn)問題。

并發(fā)場景（線程交替執(zhí)行）

• 線程A讀取變量a到緩存，a是0
• 進(jìn)行+1運(yùn)算得到結(jié)果1
• 切換到B線程
• B線程執(zhí)行完整個(gè)流程，a=1寫入主存
• 線程A恢復(fù)執(zhí)行，把結(jié)果a=1寫入緩存與主存
• 最終結(jié)果錯(cuò)誤

并行場（線程同時(shí)執(zhí)行）

• 線程A與線程B同時(shí)執(zhí)行，可能線程A執(zhí)行運(yùn)算+1的時(shí)候，線程B就已經(jīng)全部執(zhí)行完成，也可能兩個(gè)線程同時(shí)計(jì)算完，同時(shí)寫入，不管是那種，結(jié)果都是錯(cuò)誤的。

為了解決此問題，只要把多個(gè)操作變成一步操作，即保證原子性。

Java中提供了synchronized（同時(shí)滿足有序性、原子性、可見性）可以保證結(jié)果的原子性（注意這里的描述），synchronized保證原子性的原理很簡單，因?yàn)?code style="font-size: 14px;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(255, 100, 65);">synchronized可以對代碼片段上鎖，防止多個(gè)線程并發(fā)執(zhí)行同一段代碼（本文重點(diǎn)是J M M，所以不會(huì)對synchronized做過多的解讀）。

并發(fā)場景（線程A與線程B交替執(zhí)行）

• 線程A獲取鎖成功
• 線程A讀取變量a到緩存，進(jìn)行+1運(yùn)算得到結(jié)果1
• 此時(shí)切換到了B線程
• 線程B獲取鎖失敗，阻塞等待
• 切換回線程A
• 線程A執(zhí)行完所有流程，主存a=1
• 線程A釋放鎖成功，通知線程B獲取鎖
• 線程B獲取鎖成功，讀取變量a到緩存，此時(shí)a=1
• 線程B執(zhí)行完所有流程，主存a=2
• 線程B釋放鎖成功

并行場景

• 線程A獲取鎖成功
• 線程B獲取鎖失敗，阻塞等待
• 線程A讀取變量a到緩存，進(jìn)行+1運(yùn)算得到結(jié)果1
• 線程A執(zhí)行完所有流程，主存a=1
• 線程A釋放鎖成功，通知線程B獲取鎖
• 線程B獲取鎖成功，讀取變量a到緩存，此時(shí)a=1
• 線程B執(zhí)行完所有流程，主存a=2
• 線程B釋放鎖成功

synchronized對共享資源代碼段上鎖，達(dá)到互斥效果，天然的解決了無法保證原子性、可見性、有序性帶來的問題。

雖然在并行場A線程還是被中斷了，切換到了B線程，但它依然需要等待A線程執(zhí)行完畢，才能繼續(xù)，所以結(jié)果的原子性得到了保證。

有序性

在日常搬磚寫代碼時(shí)，可能大家都以為，程序運(yùn)行時(shí)就是按照編寫順序執(zhí)行的，但實(shí)際上不是這樣，編譯器和處理器為了優(yōu)化性能，會(huì)對代碼做重排，所以語句實(shí)際執(zhí)行的先后順序與輸入的代碼順序可能一致，這就是指令重排序。

可能讀者們會(huì)有疑問“指令重排為什么能優(yōu)化性能？”，其實(shí)C P U會(huì)對重排后的指令做并行執(zhí)行，達(dá)到優(yōu)化性能的效果。

重排序前的指令

重排序后的指令

重排序后，對a操作的指令發(fā)生了改變，節(jié)省了一次Load a和Store a，達(dá)到性能優(yōu)化效果，這就是重排序帶來的好處。

重排遵循as-if-serial原則，編譯器和處理器不會(huì)對存在數(shù)據(jù)依賴關(guān)系的操作做重排序，因?yàn)檫@種重排序會(huì)改變執(zhí)行結(jié)果（即不管怎么重排序，單線程程序的執(zhí)行結(jié)果不能被改變），下面這種情況，就屬于數(shù)據(jù)依賴。

int i = 10
int j = 10
//這就是數(shù)據(jù)依賴，int i 與 int j 不能排到 int c下面去
int c = i + j

但也僅僅只是針對單線程，多線程場景可沒這種保證，假設(shè)A、B兩個(gè)線程，線程A代碼段無數(shù)據(jù)依賴，線程B依賴線程A的結(jié)果，如下圖（假設(shè)保證了可見性）

禁止重排場景（i默認(rèn)0）

• 線程A執(zhí)行i = 10
• 線程A執(zhí)行b = true
• 線程B執(zhí)行if( b )通過驗(yàn)證
• 線程B執(zhí)行i = i + 10
• 最終結(jié)果i是20

重排場景（i默認(rèn)0）

• 線程A執(zhí)行b = true
• 線程B執(zhí)行if( b )通過驗(yàn)證
• 線程B執(zhí)行i = i + 10
• 線程A執(zhí)行i = 10
• 最終結(jié)果i是10

為解決重排序，使用Java提供的volatile修飾變量同時(shí)保證可見性、有序性，被volatile修飾的變量會(huì)加上內(nèi)存屏障禁止排序（本文重點(diǎn)是J M M，所以不會(huì)對volatile做過多的解讀）。

三大特性的保證

致謝

非常感謝各位小哥哥小姐姐們能 看到這里，原創(chuàng)不易，文章有幫助可以「點(diǎn)個(gè)贊」或「分享與評論」，都是支持（莫要白嫖）！

愿你我都能奔赴在各自想去的路上，我們下篇文章見！