有关 go 互斥锁和自旋锁的性能对比的疑惑

问答 / 190 / 23 / 创建于 1年前 / 更新于 1年前

1. 运行环境

go version go1.18.5 windows/amd64

2. 问题描述？

最近需要做一个本地缓存的需求，缓存数据从 redis 读取，遂考虑到在大量并发的情况下，减少 go 协程切换的消耗，考虑用自旋锁来实现

实现的大概的思路是：

大量并发请求
- 首先获得自旋锁的 goroutine 上锁
- 获得自旋锁的 goroutine 去 redis 读取数据到本地缓存
- 其他未获得自旋锁的 goroutine 原地自旋等待缓存数据
读取的协程读取到数据之后解锁
未获得自旋锁的 goroutine 使用已加载到本地的缓存数据

但是我经过实际测试，发现用自旋锁的速度和用互斥锁的速度要差1~2个数量级，这让我很不理解？

之后我经过大量测试发现：

自旋锁在本地操作（值自增），阻塞操作（sleep 或者 channel recv）时，性能高于互斥锁
在 HTTP 操作时性能和互斥锁相当
在通过 “github.com/go-redis/redis/v8” 操作 redis 获取数据时，自旋锁的性能和互斥锁要差1个数量级

不知道是否有大佬可以解答一番？不吝赐教

3. 您期望得到的结果？

自旋锁的效率应该是高于互斥锁的

4. 您实际得到的结果？

自旋锁在操作 redis 时的效率要远远低于互斥锁

5. 代码实现如下

自旋锁的实现

type SpinLocker uint32

func (sl *SpinLocker) Lock() {
    for !atomic.CompareAndSwapUint32((*uint32)(sl), 0, 1) {
        runtime.Gosched()
    }
}

func (sl *SpinLocker) Unlock() {
    atomic.StoreUint32((*uint32)(sl), 0)
}

一些测试操作的实现

// 本地值自增操作

var localValue int

func operationLocalValue() {
    localValue++
}

// redis 读取缓存操作

var cache struct {
    value string
}

var redisCacheKey string = "go_foo_test_cache"
var redisCacheValue string = "Hello Spin Key"
var redisCtx context.Context = context.Background()
var redisClient *redis.Client = func() *redis.Client {
    client := redis.NewClient(func() *redis.Options {
        opt, err := redis.ParseURL("redis://:@127.0.0.1:6379")
        if err != nil {
            panic(err)
        }
        return opt
    }())
    _, err := client.Ping(redisCtx).Result()
    if err != nil {
        panic(err)
    }
    _, err = client.Set(redisCtx, redisCacheKey, redisCacheValue, time.Hour).Result()
    if err != nil {
        panic(err)
    }
    return client
}()

func loadCacheFromRedis() {
    cv, err := redisClient.Get(redisCtx, redisCacheKey).Result()
    if err != nil {
        panic(err)
    }
    cache.value = cv
}

// sleep 阻塞操作

func blockingGoroutine(d time.Duration) {
    time.Sleep(d)
}

// channel 阻塞操作

var channel chan int = make(chan int)

func channelSender(d time.Duration, max int) {
    t := time.NewTicker(d)
    defer t.Stop()
    c := 0
    for range t.C {
        channel <- 1
        c++
        if c > max {
            return
        }
    }
}

func channelReceiver() {
    <-channel
}

// http 请求操作

func httpServer() {
    http.HandleFunc("/sync/locker/foo", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello Spin Locker"))
    })
    http.ListenAndServe("127.0.0.1:8000", nil)
}

func httpClient() {
    req, err := http.NewRequest("GET", "http://127.0.0.1:8000/sync/locker/foo", nil)
    if err != nil {
        panic(err)
    }
    req.Close = true
    c := http.Client{}
    _, err = c.Do(req)
    if err != nil {
        panic(err)
    }
}

调用处

var spinLocker SpinLocker
var mutex sync.Mutex

// 以 HTTP 为例
func SpinLockerPerformanceOnHttpRequest(gCount int) {
    go httpServer()
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != 100; index++ {
        go func() {
            spinLocker.Lock()
            httpClient()
            spinLocker.Unlock()
            gp.Done()
        }()
    }
    gp.Wait()
}

func MutexLockerPerformanceOnHttpRequest(gCount int) {
    go httpServer()
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != 100; index++ {
        go func() {
            spinLocker.Lock()
            httpClient()
            spinLocker.Unlock()
            gp.Done()
        }()
    }
    gp.Wait()
}

// 以 redis 获取数据为例

func SpinLockerPerformanceOnLoadCacheFromRedis(gCount int) string {
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            spinLocker.Lock()
            loadCacheFromRedis()
            spinLocker.Unlock()
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.value
}

func MutexLockerPerformanceOnLoadCacheFromRedis(gCount int) string {
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            mutex.Lock()
            loadCacheFromRedis()
            mutex.Unlock()
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.value
}

为了免除泛型的影响，没有用泛型来写

经过评论中 singleflight 的提示，发现了我自己在读取 redis 实现的问题，我没有从本地缓存读取，修改后的逻辑如下：

func SpinLockerPerformanceOnLoadCacheFromRedis(gCount int) (string, int32) {
    cache = struct {
        value       string
        holderCount int32
    }{}
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            spinLocker.Lock()
            if len(cache.value) != 0 {
                spinLocker.Unlock()
                goto USE_CACHE
            }
            loadCacheFromRedis()
            spinLocker.Unlock()
        USE_CACHE:
            atomic.AddInt32(&cache.holderCount, 1)
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.value, cache.holderCount
}

func MutexLockerPerformanceOnLoadCacheFromRedis(gCount int) (string, int32) {
    cache = struct {
        value       string
        holderCount int32
    }{}
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            if len(cache.value) != 0 {
                goto USE_CACHE
            }
            mutex.Lock()
            if len(cache.value) != 0 {
                mutex.Unlock()
                goto USE_CACHE
            }
            loadCacheFromRedis()
            mutex.Unlock()
        USE_CACHE:
            atomic.AddInt32(&cache.holderCount, 1)
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.value, cache.holderCount
}

// 新增 singleflight 的形式

func getValueFromRedisByKey(k string) string {
    v, err := redisClient.Get(redisCtx, k).Result()
    if err != nil {
        panic(err)
    }
    return v
}

var gsf singleflight.Group

func SingleFlightPerformanceOnLoadCacheFromRedis(gCount int) (string, int32) {
    cache = struct {
        value       string
        holderCount int32
    }{}
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            _, err, _ := gsf.Do(redisCacheKey, func() (interface{}, error) {
                cache.value = getValueFromRedisByKey(redisCacheKey)
                return cache.value, nil
            })
            if err != nil {
                panic(err)
            }
            atomic.AddInt32(&cache.holderCount, 1)
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.value, cache.holderCount
}

修改后的性能对比

mutex = singleflight 优于 spinlocker
mutex 的效率和 spinlocker 不再有数量级的差距，mutex 的效率是 spinlocker 的 3~4 倍

至此，仍然存有疑惑，为什么自旋锁的性能在这种场景下没有优于互斥锁？

再次测试后的对比

1w 协程内
结论仍然一样
65535 协程时
mutex = spinlocker 优于 singleflight
10w 协程时
mutex 略优于 spinlocker 优于 singleflight

感谢其他大佬提出的 go-redis 配套缓存库 “github.com/go-redis/cache/v8”
不过经过对该库的测试，发现其性能并不如直接使用 mutex
使用方式如下：

func RedisV8CachePerformanceOnLoadCacheFromRedis(gCount int) int32 {
    cacheHandler := redisCache.New(&redisCache.Options{
        Redis:      redisClient,
        LocalCache: redisCache.NewTinyLFU(1000, time.Hour),
    })
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            var v string
            err := cacheHandler.Get(redisCtx, redisCacheKey, &v)
            if err != nil {
                panic(err)
            }
            if v != redisCacheValue {
                panic("result wrong")
            }
            atomic.AddInt32(&cache.holderCount, 1)
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.holderCount
}

debug 其源代码，发现 Cache.getBytes 这个方法存在“缓存穿透”的问题，不知是否是我使用的方法不对，如果不对，请指出

经过大佬提示，应该用 Cache.Once 方法，修改后如下：

func RedisV8CacheOncePerformanceOnLoadCacheFromRedis(gCount int) int32 {
    cacheHandler := redisCache.New(&redisCache.Options{
        Redis:      redisClient,
        LocalCache: redisCache.NewTinyLFU(1000, time.Hour),
    })
    gp := sync.WaitGroup{}
    gp.Add(gCount)
    for index := 0; index != gCount; index++ {
        go func() {
            var v string
            err := cacheHandler.Once(&redisCache.Item{
                Ctx:   redisCtx,
                Key:   redisCacheKey,
                Value: &v,
                Do: func(i *redisCache.Item) (interface{}, error) {
                    return i.Value, nil
                },
            })
            if err != nil {
                panic(err)
            }
            if v != redisCacheValue {
                panic("result wrong")
            }
            atomic.AddInt32(&cache.holderCount, 1)
            gp.Done()
        }()
    }
    gp.Wait()
    return cache.holderCount
}

实际性能和 singleflight 的结论差不多，结论如下：

// PerformanceOnLoadCacheFromRedis

// 100 g
// - MutexLocker
// 3.853s 35118op       33606 ns/op        1618 B/op         101 allocs/op
// - go-redis/cache/v8 Once
// 2.828s 966op       1283387 ns/op      205865 B/op         439 allocs/op
// - SpinLocker
// 4.404s 350op       4841889 ns/op        1861 B/op         107 allocs/op

// 65535 g
// - MutexLocker
// 4.696s 72op      17069562 ns/op     1054311 B/op       65564 allocs/op
// - go-redis/cache/v8 Once
// 3.588s 46op      26429683 ns/op     9519285 B/op      264817 allocs/op
// - SpinLocker
// 3.669s 73op      18067181 ns/op     1168958 B/op       65810 allocs/op

// 10w g
// - MutexLocker
// 3.417s 42op      25607279 ns/op     1604059 B/op      100029 allocs/op
// - go-redis/cache/v8 Once
// 3.533s 32op      35686584 ns/op    14245437 B/op      402675 allocs/op
// - SpinLocker
// 3.543s 45op      25656558 ns/op     1701715 B/op      100233 allocs/op

但仍然没有解决“为什么在这个场景下，自旋锁的性能不如互斥锁”的疑问

具体的压力测试代码在这里

讨论数量: 23

xing393939

247 声望

for !atomic.CompareAndSwapUint32((*uint32)(sl), 0, 1) {
        runtime.Gosched()
}

非大佬，你这个写的看着不像是自旋呃，而是让出协程，再次执行的时间取决于go的调度。按你说的场景，感觉可以用singleflight包

1年前评论

Mericustar （楼主）

你好，感谢你的解答

我这里的自旋锁的实现方式是参考这里的 implementation-of-golang-spin-lock - ofstack

采用文中较简单方式的自旋锁，没有使用第二种可重入的自旋锁（因为用不到）

singleflight 这个包我记下了，回头可以去研究研究

另外，runtime.Gosched() 源码的意思是让出 CPU，这块如果不让出 CPU 的话是会有 “所有 M 耗尽都在执行 G，新的 G 无法被 M 执行” 的情况出现

singleflight 我看了下源代码，Do 方法跟我的思路差不多，只是它将底层的细节封装起来了，而我这里是将业务侵入到了这个 Do 的内部平铺开了写的

singleflight 实际测了一下，性能非常可观，比 mutex 还要快一个数量级，可以再好好研究研究

对比了我自己的 mutex 逻辑和 singleflight 的逻辑，发现铺平逻辑差不多，性能也应该相当甚至于更好（因为我没用 wg），遂发现了我自己实现的问题，我自己的 mutex 逻辑没有从本地缓存读取，重新修改之后现在性能和 singleflight 持平

renxiaotu

359 声望

既然你都用github.com/go-redis/redis/v8了

为什么不顺便用配套的github.com/go-redis/cache/v8？

我这边对 github.com/go-redis/cache/v8 做了一些测试，其性能并不如直接使用 mutex，debug 了下其源代码，发现我直接启动大量 goroutine 用 Cache.Get 方法，其底层的 getBytes 方法在并发访问下会有缓存穿透的问题

renxiaotu （作者）

@Mericustar 感谢你的测试，怪不得用go-redis/redis的人这么多但用go-redis/cache的人这么少

@Mericustar 我看了下你的代码，没有看懂你的需求，你能详细描述下你的需求吗？

@renxiaotu 你好，谢谢你的热心。我的需求是这样子，存在其他进程不定时的对 redis 中的同一个 key 写入一些数据，我当前需求的进程会并发的接收外界请求获取这个 key 的值，我想首次获取时只放一个 goroutine 去实际的操作 redis 然后将这个值缓存在本地，其他 goroutine 只需要等待第一个拿到缓存的 goroutine 拿到的缓存即可

@Mericustar 针对这个需求go-redis/cache有一个Once的方法

@renxiaotu Once 这个方法，我刚才也试了一下，它会先 set，并不符合我的需求，它看上去更符合相同进程下对 redis set/get 操作并提供缓存

这个是官方对于Once方法的示例，同一个实例同一时间只会有一个调用，其它调用会等待首个调用执行完成并获取其结果

func Example_advancedUsage() {
    ring := redis.NewRing(&redis.RingOptions{
        Addrs: map[string]string{
            "server1": ":6379",
            "server2": ":6380",
        },
    })

    mycache := cache.New(&cache.Options{
        Redis:      ring,
        LocalCache: cache.NewTinyLFU(1000, time.Minute),
    })

    obj := new(Object)
    err := mycache.Once(&cache.Item{
        Key:   "mykey",
        Value: obj, // destination
        Do: func(*cache.Item) (interface{}, error) {
            return &Object{
                Str: "mystring",
                Num: 42,
            }, nil
        },
    })
    if err != nil {
        panic(err)
    }
    fmt.Println(obj)
    // Output: &{mystring 42}
}

啊，不好意思，重新看了一下 Once 是怎么写的，它在 Cache.Do 方法里面用互斥锁阻塞住了，然后先去执行 Cache.getBytes，没有问题就返回了，取不到会去 set 一下，这块是我看岔了，我看成了它取完了就去 set 一下

感觉这样子互斥锁的做法，其实跟我直接用互斥锁的做法是一样的，这块其实和 singleflight 的 Do 的结论一样，我是吧业务代码侵入到了这个互斥锁的结构里面来写的，而这个和 singleflight 的 Do 方法都是屏蔽了互斥锁的细节

事实上Once用的就是singleflight，只是帮你封装好了

file

搜嘎，原来这个 Do 就是 singleflight 的 Do 方法

@Mericustar 有兴趣的话你可以仿照singleflight自己用自旋锁实现一个，就能看出实际使用时自旋锁和互斥锁差距如何了，我简单的模拟了下，结果是自旋锁比较快

@renxiaotu singleflight 一楼的老哥已经提过了，自旋锁的实现我也是按照这里的第一种非重入自旋锁来实现的，实现出来的测试效果在问题中也有写：redis 操作不如互斥锁，HTTP 操作和互斥锁相当，本地操作如：原子操作/阻塞操作都要比互斥锁好，感觉只要不和操作系统打交道自旋锁的性能要更好一些

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容，与人为善，比聪明更重要！

帮助

有关 go 互斥锁和自旋锁的性能对比的疑惑

1. 运行环境

2. 问题描述？

3. 您期望得到的结果？

4. 您实际得到的结果？

5. 代码实现如下

推荐文章：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息

有关 go 互斥锁和自旋锁的性能对比的疑惑

1. 运行环境

2. 问题描述？

3. 您期望得到的结果？

4. 您实际得到的结果？

5. 代码实现如下

推荐文章：

社区赞助商

关于 LearnKu

资源推荐

服务提供商

其他信息

请登录