golang源码分析：sync.Pool 如何从读写加锁到无锁

最新推荐文章于 2024-06-16 09:36:17 发布

MoeYang

最新推荐文章于 2024-06-16 09:36:17 发布

阅读量533

点赞数

CC 4.0 BY-SA版权

分类专栏： go 文章标签： golang pool mutex cas 数据结构

本文链接：https://blog.youkuaiyun.com/TongWaccs/article/details/111180158

本文深入分析了Golang的sync.Pool源码，从早期依赖互斥锁的并发安全实现，转变为利用双向链表实现的无锁策略。通过这种方式，减少了在高并发场景下的协程调度开销。文章探讨了数据结构的设计，如poolLocal和allPools，并解释了为何使用CAS而非Mutex，因为CAS在锁粒度小、释放快的场景中能提供更好的性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

我们知道，早期的sync.Pool，底层是通过互斥锁实现对共享队列的并发访问的，这里会存在的问题是，尽管是分段锁，高并发场景下频繁进行G的wait和runable状态调度其实开销也不算小

通过互斥锁保证并发安全的sync.Pool数据结构

type Pool struct {
	noCopy noCopy

	local     unsafe.Pointer // local,固定大小per-P池, 实际类型为 [P]poolLocal
	localSize uintptr        // local array 的大小
	//  New 方法在 Get 失败的情况下，选择性的创建一个值, 否则返回nil
	New func() interface{}
}

type poolLocal struct {
	poolLocalInternal

	// 将 poolLocal 补齐至两个缓存行的倍数，防止 false sharing,
	// 每个缓存行具有 64 bytes，即 512 bit
	// 目前我们的处理器一般拥有 32 * 1024 / 64 = 512 条缓存行
	pad [128 - unsafe.Sizeof(poolLocalInternal{})%128]byte
}

// Local per-P Pool appendix.
type poolLocalInternal struct {
	private interface{}   // 只能被局部调度器P使用
	shared  []interface{} // 所有P共享
	Mutex                 // 读写shared前要加锁
}