當我比較sync.mu,sync.Map和atomic.Valuego 的效率時，預計它sync.mu的效率低于后兩者。但是當我做一個基準測試時，發現使用sync.mu. 所以我想知道原因或者可能有最佳實踐。代碼源代碼在這里https://go.dev/play/p/WODF8Tyyw4d簡化如下：Scene1：在map中改變一個隨機的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)結果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貢獻1850條經驗 獲得超11個贊
你沒有比較這種同步結構的效率，因為你也在做 I/0。這段代碼中還有 goroutines 和 waitgroups ……不確定我是否理解
您應該考慮比較相同上下文中的相似用法。
例如，增加一個計數器。您在 sync.Map 中有一個計數器，atomic.Value 并受互斥鎖保護。
每種方法都各有利弊，但互斥體只處理同步，而其他結構也處理存儲。
Mutex 應該更快，因為它……不那么復雜。
但是，如果您處理比 uint64 更復雜的東西，則 atomic.Value 的開銷可能沒問題。
例如，使用互斥鎖你需要一個特定的鎖定/解鎖順序，你可能會在沒有適當的測試+競爭條件檢測器的情況下發現一些問題。
而 atomic.Value 會為你處理這個。
我從不使用 sync.Map 但我在使用 atomic.Value 的生產中有非常高效的代碼 - 我對此沒有意見。
正確的基準需要更多的技術方法。
- 1 回答
- 0 關注
- 131 瀏覽
添加回答
舉報
0/150
提交
取消