當(dāng)我比較sync.mu,sync.Map和atomic.Valuego 的效率時，預(yù)計它sync.mu的效率低于后兩者。但是當(dāng)我做一個基準(zhǔn)測試時，發(fā)現(xiàn)使用sync.mu. 所以我想知道原因或者可能有最佳實踐。代碼源代碼在這里https://go.dev/play/p/WODF8Tyyw4d簡化如下：Scene1：在map中改變一個隨機(jī)的kv對，sync.muvssync.Map// sync.mu readermu.Lock()tmp := tA[idx]mu.Unlock()// sync.mu writermu.Lock()tA[idx] = datamu.Unlock()// sync.Map readerv, _ := tB.Load(idx)// sync.Map writertB.Store(idx, data)Scene2：換一整張圖，sync.muvsatomic.Value// sync.mu readermu.Lock()tmp := tA[0]mu.Unlock()// sync.mu Writermu.Lock()tA = datamu.Unlock()// atomic.Value readerv := tC.Load().(map[int]int)[0]// atomic.Value writertC.Store(data)結(jié)果goos: darwingoarch: amd64pkg: sync-democpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHzBenchmarkMu-12 1000000000 0.5401 ns/opBenchmarkSyncMap-12 1000000000 0.5504 ns/opBenchmarkMuTotal-12 1000000000 0.5418 ns/opBenchmarkAtomic-12 1000000000 0.5457 ns/opPASSok sync-demo 64.195s
1 回答
慕蓋茨4494581
TA貢獻(xiàn)1850條經(jīng)驗 獲得超11個贊
你沒有比較這種同步結(jié)構(gòu)的效率，因為你也在做 I/0。這段代碼中還有 goroutines 和 waitgroups ……不確定我是否理解
您應(yīng)該考慮比較相同上下文中的相似用法。
例如，增加一個計數(shù)器。您在 sync.Map 中有一個計數(shù)器，atomic.Value 并受互斥鎖保護(hù)。
每種方法都各有利弊，但互斥體只處理同步，而其他結(jié)構(gòu)也處理存儲。
Mutex 應(yīng)該更快，因為它……不那么復(fù)雜。
但是，如果您處理比 uint64 更復(fù)雜的東西，則 atomic.Value 的開銷可能沒問題。
例如，使用互斥鎖你需要一個特定的鎖定/解鎖順序，你可能會在沒有適當(dāng)?shù)臏y試+競爭條件檢測器的情況下發(fā)現(xiàn)一些問題。
而 atomic.Value 會為你處理這個。
我從不使用 sync.Map 但我在使用 atomic.Value 的生產(chǎn)中有非常高效的代碼 - 我對此沒有意見。
正確的基準(zhǔn)需要更多的技術(shù)方法。
- 1 回答
- 0 關(guān)注
- 136 瀏覽
添加回答
舉報
0/150
提交
取消