摘要： 一、前言 go語言類似Java JUC包也提供了一些列用于多線程之間進(jìn)行同步的措施，比如低級的同步措施有 鎖、CAS、原子變量操作類。相比Java來說go提供了獨(dú)特的基于通道的同步措施。本節(jié)我們先來看看go中CAS操作 二、CAS操作 go中的Cas操作與java中類似，都是借用了CPU提供的原子性指令來實(shí)現(xiàn)。
十余年的梨林網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。全網(wǎng)整合營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整梨林建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)公司從事“梨林網(wǎng)站設(shè)計(jì)”,“梨林網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
go語言類似Java JUC包也提供了一些列用于多線程之間進(jìn)行同步的措施，比如低級的同步措施有 鎖、CAS、原子變量操作類。相比Java來說go提供了獨(dú)特的基于通道的同步措施。本節(jié)我們先來看看go中CAS操作
go中的Cas操作與java中類似，都是借用了CPU提供的原子性指令來實(shí)現(xiàn)。CAS操作修改共享變量時(shí)候不需要對共享變量加鎖，而是通過類似樂觀鎖的方式進(jìn)行檢查，本質(zhì)還是不斷的占用CPU 資源換取加鎖帶來的開銷（比如上下文切換開銷）。下面一個(gè)例子使用CAS來實(shí)現(xiàn)計(jì)數(shù)器
go中CAS操作具有原子性，在解決多線程操作共享變量安全上可以有效的減少使用鎖所帶來的開銷，但是這是使用cpu資源做交換的。
我簡單列舉了并發(fā)編程的大綱，需要詳細(xì)的私信“555”~~
go語言的map多協(xié)程訪問時(shí)需要加鎖
支持==和!=操作就可以做key，實(shí)際上只有function、map、slice三個(gè)kind不支持作為key，因?yàn)橹荒芎蚽il比較不能和另一個(gè)值比較。布爾、整型、浮點(diǎn)、復(fù)數(shù)、字符串、指針、channel等都可以做key。
struct能不能做key要看每一個(gè)字段，如果所有字段都可以做key，那這個(gè)struct就可以。有一個(gè)字段不能做key，這個(gè)struct就不能做key。array也是，元素類型能做key，那這個(gè)array就可以。
例如：
type Foo map[struct {
B bool
I int
F float64
C complex128
S string
P *Foo
Ch chan Foo
}]bool
每一個(gè)字段都可以做key，F(xiàn)oo就可以做key。再如：
type Foo map[struct {
Fn func() Foo
M map[*Foo]int
S []Foo
}]bool
有一個(gè)字段不能做key、Foo就不允許做key，而這三個(gè)字段都不能。
字段是遞歸檢查的：
type Foo map[struct {
Sub struct {
M map[*Foo]bool
}
}]bool
Sub的M字段不能做key，Sub就不能做key，F(xiàn)oo也就不能做key。
總之想把一個(gè)數(shù)據(jù)結(jié)構(gòu)用于map的key，就不能包含function、map和slice。
sync.Map是1.9才推薦的并發(fā)安全的map，除了互斥量以外，還運(yùn)用了原子操作，所以在這之前，有必要了解下 Go語言——原子操作
go1.10\src\sync\map.go
entry分為三種情況：
從read中讀取key，如果key存在就tryStore。
注意這里開始需要加鎖，因?yàn)樾枰僮鱠irty。
條目在read中，首先取消標(biāo)記，然后將條目保存到dirty里。（因?yàn)闃?biāo)記的數(shù)據(jù)不在dirty里）
最后原子保存value到條目里面，這里注意read和dirty都有條目。
總結(jié)一下Store：
這里可以看到dirty保存了數(shù)據(jù)的修改，除非可以直接原子更新read，繼續(xù)保持read clean。
有了之前的經(jīng)驗(yàn)，可以猜測下load流程：
與猜測的 區(qū)別 ：
由于數(shù)據(jù)保存兩份，所以刪除考慮：
先看第二種情況。加鎖直接刪除dirty數(shù)據(jù)。思考下貌似沒什么問題，本身就是臟數(shù)據(jù)。
第一種和第三種情況唯一的區(qū)別就是條目是否被標(biāo)記。標(biāo)記代表刪除，所以直接返回。否則CAS操作置為nil。這里總感覺少點(diǎn)什么，因?yàn)闂l目其實(shí)還是存在的，雖然指針nil。
看了一圈貌似沒找到標(biāo)記的邏輯，因?yàn)閯h除只是將他變成nil。
之前以為這個(gè)邏輯就是簡單的將為標(biāo)記的條目拷貝給dirty，現(xiàn)在看來大有文章。
p == nil，說明條目已經(jīng)被delete了，CAS將他置為標(biāo)記刪除。然后這個(gè)條目就不會(huì)保存在dirty里面。
這里其實(shí)就跟miss邏輯串起來了，因?yàn)閙iss達(dá)到閾值之后，dirty會(huì)全量變成read，也就是說標(biāo)記刪除在這一步最終刪除。這個(gè)還是很巧妙的。
真正的刪除邏輯：
很繞。。。。
重慶分公司
重慶分公司
