atomic和mutex锁使用场景问题
曹大,昨天在直播中提到了atomic和mutex的使用场景问题
下来我测试了下
// sync.Mutex
func test1() {
var wg sync.WaitGroup
var mutex sync.Mutex
count := int64(0)
t := time.Now()
for i := 0; i < 10000; i++ {
wg.Add(1)
go func(i int) {
mutex.Lock()
count++
wg.Done()
mutex.Unlock()
}(i)
}
wg.Wait()
fmt.Printf("test1 花费时间:%d, count的值为:%d \n", time.Now().Sub(t), count)
}
// sync.atomic
func test2() {
var wg sync.WaitGroup
count := int64(0)
t := time.Now()
for i := 0; i < 10000; i++ {
wg.Add(1)
go func(i int) {
atomic.AddInt64(&count, 1)
wg.Done()
}(i)
}
wg.Wait()
fmt.Printf("test2 花费时间:%d, count的值为:%d \n", time.Now().Sub(t), count)
}
执行结果:
test1 花费时间:4573742, count的值为:10000
test2 花费时间:3195538, count的值为:10000
结果显示atomic 的效率会高点。
为什么你建议业务层要尽量使用mutex呢?是因为atomic会对内存块直接加锁,影响系统整体的性能么?
11
收起
正在回答 回答被采纳积分+1
1回答
Xargin
2021-06-23 18:17:49
atomic 是较底层的 api
如果用 atomic 编程需要对并发有比较深的理解,要深入地理解我们课上提了几句的内存重排,memory barrier 等相关知识
用 atomic 编写高性能数据结构还要知道使用这种 api 独有的一些并发问题,比如 ABA 问题
在深入理解这些知识的前提下,才不容易写出 bug,
同步编程这节里提到的一些数据结构就是做无锁处理的,比如 sync.Pool,你可以看看,还是比较复杂的
对于上层应用来说,atomic 太底层了~
个别计数、配置替换的场景用一用问题不大,因为逻辑比较简单
你这里的代码是很简单的计数场景,用 atomic 也没啥问题
恭喜解决一个难题,获得1积分~
来为老师/同学的回答评分吧
0 星