后發(fā)先至：另外一位讀者則給出了一個更奇怪的現(xiàn)象，兩個變量中后執(zhí)行的代碼看起來卻先被調(diào)用了。

加個if問題竟然解了：最后一個反饋留言最令人崩潰，在代碼中隨便加上個判斷語句，不但解決了y=0的問題，性能還非常好。

1難道這就是傳說中的亂序執(zhí)行？

先來看以下讀者回復的代碼：

package main import （“fmt”“sync/atomic”“time”） func main（） {var x int32var y int32 go func（） {for { x = atomic.AddInt32（&x， 1） y = atomic.AddInt32（&y， 1） } }（） time.Sleep（time.Second） fmt.Println（“x=”， x） fmt.Println（“y=”， y）}

在這部分內(nèi)容中，兩個變量x和y都是由原子操作Automic.Add來保證并發(fā)安全的，但是結(jié)果輸出出來我們可以發(fā)現(xiàn)y竟然比x還大？而且每次運行的情況基本都是y更大，只是大多少有所區(qū)別。

x= 49418397y= 49425282成功： 進程退出代碼 0.

看到這個輸出結(jié)果，我第一反應感覺這是亂序執(zhí)行的衍生現(xiàn)象，因為x和y的加1操作彼此是獨立的，雖然編譯器不會優(yōu)化執(zhí)行順序，但是在CPU的執(zhí)行層面有可能會對于前后無依賴的操作打亂順序執(zhí)行。這樣一來就的確有可能出現(xiàn)后面的操作先執(zhí)行的情況。

但是仔細一想這樣的說法應該并不合理，如果是亂序執(zhí)行的原因，那么上面這段代碼的執(zhí)行結(jié)果肯定不會每次結(jié)果都是y更大一些，每次執(zhí)行都是y比x更大只能說明代碼是按照一定順序執(zhí)行的，而且目前的CPU指令流水線的預測功能肯定還沒有牛到能夠完全知曉x與y的值不按照順序提交是沒有作何影響的地步。

2仔細一看還是多并發(fā)競爭問題

再來看以下代碼，

package main import （“fmt”“sync/atomic”“time”） func main（） {var x int32var y int32 go func（） {for { x = atomic.AddInt32（&x， 1） y = atomic.AddInt32（&y， 1） } }（） time.Sleep（time.Second） x1 ：= x y1 ：= y fmt.Println（“x=”， x1） fmt.Println（“y=”， y1）}

只要把fmt.println之前先把x和y的值拷貝出來到x1與y1，再打印x1與y1的值就基本沒有這個誤差了。

x= 51061072y= 51061071成功： 進程退出代碼 0.

這也就是說，fmt.println在執(zhí)行中間，go func中的子gorouine又被調(diào)度了。所以y比x的值大，本質(zhì)又是一個多并發(fā)的競爭問題。而不是亂序執(zhí)行的原因，只是這個問題在Go的開發(fā)模式下也是非常隱蔽。

3崩潰了，單核怎么也是0

再說第二個令人崩潰的讀者反饋，他在單核的云ECS嘗試運行以下代碼，

package main import （“fmt”//“sync/atomic”“time”） func main（） {var x int32var y int32 go func（） {for { x++ y++ } }（） time.Sleep（time.Second） fmt.Println（“x=”， x） fmt.Println（“y=”， y）}

結(jié)果也是0。剛開始我覺得這個讀者反饋有誤，因此我也立刻在阿里云的X86集群與華為云的鯤鵬集群分別申請了一臺單核ECS，不過結(jié)果令人崩潰，無論是ARM還是X86單核平臺運行上述代表的結(jié)果也還是0，不過這還沒完。

4更崩潰了，隨隨便便加個if竟然殺瘋了…。

接下來是最令人崩潰的時刻，我們來看以下代碼：

package main import （“fmt”//“sync/atomic”“time”） func main（） {var x int32var y int32 z ：= 0 go func（） {for { x++//一些無需關(guān)注并發(fā)安全的計算問題 y++if z 》 0 { fmt.Println（“z is”， z）//這一行代碼不會執(zhí)行到 } } }（） time.Sleep（time.Second）//定時執(zhí)行，超過1秒鐘就停止了，無需關(guān)注并發(fā)安全 fmt.Println（“x=”， x） fmt.Println（“y=”， y）}

這段代碼在沒有作何鎖或者互斥體的基礎(chǔ)上竟然解決了y=0的問題，而且令人崩潰的是，這段代碼的執(zhí)行效率竟然還非常驚人，比之前Automic的方式至少快一個數(shù)量級，

如果是這樣的話那么這種代碼方案就非常適合于不需要并發(fā)控制，并且定時需要結(jié)束的計算場景，假如我一個計算任務只能給1秒鐘，能算得出來就算，算不出來就解下一題了，那么if的方案就非常適合了。

x= 407698730y= 407745938成功： 進程退出代碼 0.

在解釋if分支這個非主流的方案之前，我們再來看一下互斥體這種主流并發(fā)同步方案。

互斥體實現(xiàn)如下：

package main import （“fmt”“sync” //“sync/atomic”“time”） func main（） {var x int32var y int32var mutex sync.Mutex go func（） {for { mutex.Lock（） x++ y++ mutex.Unlock（） } }（） time.Sleep（time.Second） x1 ：= x y1 ：= y fmt.Println（“x=”， x1） fmt.Println（“y=”， y1）}

運行結(jié)果如下：

x= 50889322y= 50889322成功： 進程退出代碼 0.

我們可以看到互斥、原子操作等方法最終運行結(jié)果基本都在一個數(shù)量級以內(nèi)上下浮動，幅度不超過10%，對比之下if的方案實在是殺瘋了，直接比上述這種安全的寫法性能好出一個數(shù)量級！隨便加入個if分支，竟然也能解決y=0，而且還是高效解決這到底是為什么？

5關(guān)鍵時刻匯編令人心安，大神一語道破

在我的知識儲備實在無法解釋以上現(xiàn)象的時候，我只能將希望訴諸objdump，將gobuild生成的可執(zhí)行文件來進行反編譯，通過查看匯編語言代碼來尋找問題解釋的蛛絲馬跡。不看不知道一看還真是有驚喜，加了if語句和加鎖等方式一樣全部會加上內(nèi)存寫屏障writeBarrier。具體如下：

未加if的匯編結(jié)果

0000000000499400 《main.main.func1》：499400： eb 00 jmp 499402 《main.main.func1+0x2》499402： eb 00 jmp 499404 《main.main.func1+0x4》499404： eb 00 jmp 499406

《main.main.func1+0x6》499406： eb fa jmp 499402 《main.main.func1+0x2》499408： cc int3499409： cc int349940a： cc int3 49940b： cc int349940c： cc int349940d： cc int3.。。省略0000000000499420 《type..eq.［2］interface {}》：499420： 64 48 8b 0c 25 f8 ff mov %fs:0xfffffffffffffff8，%rcx499427： ff ff499429： 48 3b 61 10 cmp 0x10（%rcx），%rsp 49942d： 0f 86 cf 00 00 00 jbe 499502 《type..eq.［2］interface {}+0xe2》499433： 48 83 ec 50 sub $0x50，%rsp

加了if或者鎖的匯編結(jié)果

wirteBarrier有點類似于文件操作中flush的作用，會強制把數(shù)據(jù)由緩存同步到內(nèi)存當中去，因此我前文中所說兩個變量其中一個加鎖，另一個結(jié)果也能不為0是因為他們在同一緩存行原因解釋也不對，x和y并不是因為在同一個緩存行所以才被一起同步回內(nèi)存的，而是由于wirteBarrier這個屏障所引入的。我們來看下面的代碼。

package main import （“fmt”//“sync/atomic”“time”） func main（） {var x int32var y int32 slice ：= make（［］int， 10， 10） z ：= 0 go func（） {for { x++ y++for index， value ：= range slice { slice［index］ = value + 1 }if z 》 0 { fmt.Println（“z is”， z） } } }（） time.Sleep（time.Second） fmt.Println（“x=”， x） fmt.Println（“y=”， y） fmt.Println（“slice=”， slice）}

他的運行結(jié)果是：

x= 86961625y= 86972610slice= ［86978588 86979075 86979101 86979417 86979435 86979452 86979464 86979771 86979793 86979807］成功： 進程退出代碼 0.

我造出來長度為10整形切片，緩存行一般只有64BYTE，那么這個切片上面的數(shù)據(jù)是不可能在同一緩存行上的，通過這段代碼的執(zhí)行結(jié)果可以看到所有切換的值全部被更新了，因此我們可以了解writeBarrier這個內(nèi)存寫屏障的功能是將之前所有的數(shù)據(jù)全部強制回寫到內(nèi)存當中。

我對于單核ECS中運行的結(jié)果也是y=0的結(jié)果有了一定的認識，由于ECS虛擬機運行的主體也是物理機，而物理機肯定不是單核的，因此不執(zhí)行writeBarrier這個寫屏障語句，數(shù)據(jù)也無法刷回內(nèi)存，雖然程序運行在單核虛擬機上，而虛擬機并不會把匯編指令再做包裝，這也就造成實際的執(zhí)行與多核環(huán)境沒有什么差別。

6if為什么會被如此安排

實在中If不但實際達到了內(nèi)存同步的效果，而且還效率更高，看起來非常適合這種沒有強制同步需要的使用場景。不過我們不禁要問為什么編譯器要在出現(xiàn)if語句時顯式調(diào)用內(nèi)存屏障。個人猜測原因有兩個，

if判斷使用真實值是隱含的前提：首先在進行判斷時，使用緩存中的數(shù)據(jù)可能會帶來顯而易見的問題：因為在做判斷時程序員一般是要求用目前變量的實際值而不是緩存值來進行的，這是一個隱含的前提，可能編譯器在優(yōu)化時考慮到了這一點。

指令流水線的原因：我們知道CPU的每個動作都需要用晶體震蕩而觸發(fā)，以加法ADD指令為例，想完成這個執(zhí)行指令需要取指、譯碼、取操作數(shù)、執(zhí)行以及取操作結(jié)果等若干步驟，而每個步驟都需要一次晶體震蕩才能推進，因此在流水線技術(shù)出現(xiàn)之前執(zhí)行一條指令至少需要5到6次晶體震蕩周期才能完成。如下圖：

為了縮短指令執(zhí)行的晶體震蕩周期，芯片設計人員參考了工廠流水線機制的提出了指令流水線的想法，由于取指、譯碼這些模塊其實在芯片內(nèi)部都是獨立的，完成可以在同一時刻并發(fā)執(zhí)行，那么只要將多條指令的不同步驟放在同一時刻執(zhí)行，比如指令1取指，指令2譯碼，指令3取操作數(shù)等等，就可以大幅提高CPU執(zhí)行效率：

以上圖流水線為例 ，在T5時刻之前指令流水線以每周期一條的速度不斷建立，在T5時代以后每個震蕩周期，都可以有一條指令取結(jié)果，平均每條指令就只需要一個震蕩周期就可以完成。這種流水線設計也就大幅提升了CPU的運算速度。

但是if分支會造成流水線的停頓，也就是說指令流水線系統(tǒng)無法確定在指令1執(zhí)行時確定指令7的具體情況。那么在if時加上writeBarrier這種耗時操作其實也就可以理解了，反正if也造拖慢執(zhí)行速度，那編譯器也就不在乎在此時加上另外的耗時操作了。

7Rust為什么令人羨慕

不過在看了一段時間的Rust后，我感覺Rust的優(yōu)勢是可以避免程序員犯很多錯誤，而這其中所謂的錯誤雖然看起來低級，但是如果他們被隱藏在千萬行代碼之中，那么排查起來真是相當費時費力，由于已經(jīng)是所有權(quán)轉(zhuǎn)移了，因此變量的使用不太會出現(xiàn)像Go一樣的錯誤情況，這點我們在上一篇文章中已經(jīng)有所論述了，而且我們來看以下代碼：

use std：：thread;use std：：mpsc;use std：：Duration; fn main（） {let （tx， rx） = mpsc：：channel（）;let tx1 = mpsc：：clone（&tx）; //增加一個發(fā)送者tx1，需要clonelet tx2 =

mpsc：：clone（&tx）; //增加一個發(fā)送者tx2，需要clone thread：：spawn（move || {let vals = vec！［String：：from（“I‘m”），String：：from（“from”），String：：from（“the”），String：：from（“tx it self”）， ］; for val in vals { tx.send（val）.unwrap（）; }}）; thread：：spawn（move || {let vals = vec！

［String：：from（“I’m”），String：：from（“from”），String：：from（“the”），String：：from（“tx1”）， ］; for val in vals { tx1.send（val）.unwrap（）; }}）; thread：：spawn（move || {let vals = vec！［String：：from（“I‘m”），String：：from（“from”），String：：from（“the”），String：：from（“tx2”）， ］; for val in vals { tx2.send（val）.unwrap（）; }}）; for received in rx { //一個通道一個接收者，接收若干個發(fā)送者的信息 println！（“Got： {}”， received）;} }

可見Rust中連管道的多路并發(fā)的管理使用都要通過clone的方式來安全傳遞信息，個人根本想不到用Rust編程怎么能出現(xiàn)像上面例子中Go造成的Bug，因此Rust的學習曲線雖然陡峭，但是感覺Rust程序包往往只掌握原生的框架就可以做得很好了，而不像Python、Java除了原生語言知識以外，還需要學習熟練運用各種第三方的包。

馬超，CSDN博客專家，阿里云MVP、華為云MVP，華為2020年技術(shù)社區(qū)開發(fā)者之星。

編輯：jq