前言 sync包提供了常见的并发编程工具，比如最常见的Mutex、WaitGroup等。这些工具都非常简洁，几乎0学习成本。本篇将从源码角度简单看看这些工具的实现原理，以在未来有需求的时候，理解甚至是手动实现功能更强大的，更复杂的并发编程工具。 sync.Mutex sync.Mutex是golang中的互斥锁，但是注意它仅仅具有互斥访问的功能，没有其他功能，比如不支持可重入、不可自定义公平/非公平。 公平性 对于公平性，Mutex采取了综合两者的做法： normal mode（非公平模式，利于高效率运行）：锁释放时，优先让同时新来尝试获取锁的线程获取到锁，而不是等待队列中的线程，运行成本低，只需数次CAS就能获取到锁。这是默认的模式 starvation mode（公平模式，避免高并发下线程饿死）：锁释放时，优先让等待队列的线程获取到锁，而不是新来的线程。当等待队列队头线程等待超过1ms进入公平模式 如果当前为公平模式，那么当等待队列唯一的队头线程获取到锁，或者队头线程等待时间不足1ms，又会自动回到非公平模式。 可重入性 在开始源码之前，关于为什么golang的官方互斥锁不考虑支持可重入性我想简单讨论下。Russ Cox在讨论里核心观点在于：互斥锁的目的是保护程序的不变性（即invariant，关于什么是程序的不变性可以参考这篇）。因此当线程获取到互斥锁以及释放锁的那一刻，程序都应该是invariant的，在持有锁的期间，程序可以随便破坏invariant，只要保证释放锁的那一刻恢复了invariant即可。从这个观点来说，如果锁是可重入的，就会有这样的情况发生： func G() { mu.Lock() // 破坏invariant ... F() // 恢复invariant ... mu.Unlock() } func F() { mu.Lock() // 此时持有锁，程序应该是invariant的 // 继续执行下去可能会导致bug，因为F认为持有锁的那一刻程序是invariant的 // 但F不知道invariant已经被G破坏 ... mu.Unlock() } 也就是说，Russ Cox给互斥锁功能上的定义是保持程序的invariant，因此可重入锁的想法就是错的。但也有别的观点认为他对互斥锁的定义是错的，互斥锁本身就是为了避免多线程访问修改变量，invariant是开发者的责任，与你用不用互斥锁无关，互斥锁只是帮助你实现invariant的，并且出于编程上的方便，可重入锁可以make your life easier！况且很多语言其实都支持可重入锁。 另外关于invariant，本人也不认为是互斥锁的责任，比如在单线程的程序中，你需要维护(a==b)==true这个invariant，而且由于单线程你根本不需要锁，那么只要你会改变a或者改变b，就肯定会有某些时刻会出现invariant被破坏的情况，但这些情况一般是函数内部的瞬时发生的，而函数执行前后都是保持invariant的就没问题，可以看到与锁无关。因此锁只是个实现invariant的工具之一，它只需要关注底层并发的事情，不需要给他下“保持程序的invariant”这样的高层抽象定义。 后面我们会利用sync包现有的工具，尝试实现一个可重入锁。 源码 Mutex结构体： const ( mutexLocked = 1 << iota // 锁是否被线程持有 mutexWoken // 是否有被唤醒的线程正在等待获取锁 mutexStarving // 是否处于饥饿模式 ) type Mutex struct { state int32 // 低三位分别对应上述三个状态，高位记录等待队列的线程数 sema uint32 // 给底层同步原语使用的信号量 } Lock方法： func (m *Mutex) Lock() { // Fast path: 使用CAS快速加锁 if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) { if race.Enabled { race.Acquire(unsafe.Pointer(m)) } return } // Slow path: CAS加锁失败，说明锁被其他线程占有，当前应该被阻塞 m.lockSlow() } lockSlow方法： ...

前言 本文基于go1.21，不同版本的Context内部实现可能会有细微差别 使用场景 为什么需要Context，首先思考一个场景：客户端去请求某个服务，这个服务依赖于多个可并行执行的下游服务，为了提高这个服务的响应速度，自然会为每个下游服务开启一个协程去执行。 倘若在执行的过程中，客户端取消了对这个服务的请求，下游服务也应该被停掉。但是go不提供直接关闭协程的方法，我们可以使用chan来协作式地关闭这些子协程：在服务代码中创建一个no buffer的chan并传递给这些子协程，通过子协程read chan+父亲协程close chan来达到通知子协程关闭的效果。 我们将这个场景扩展一下： 在这个场景中，child svc1又依赖于两个下游服务，并且某次请求中child svc1因为某些原因会取消对下游服务的请求（不影响其他服务节点的正常运行），老样子，在child svc1中创建一个chan并通过这个chan去关闭下游协程就好了。child svc1的代码可能会这么写： func childSvc1(upstream <-chan) { downstream := make(chan struct{}, 0) defer close(downstream) go childSvc1_1(downstream) go childSvr1_2(downstream) for { select { case <-upstream: close(downstream) return default: // 处理业务... // 因为某些原因需要取消下游服务 close(downstream) } } } 可以看到这段小snippet还能勉强阅读，但是从使用语义上来说，chan本身是用于传递数据的，这种read+close来关闭协程的方式就是某种hack手段，对于有一定规模的项目来说，这样的使用方式可读性将会非常差并且容易出错。因此我们需要一个带有“取消下游”语义的库来完成这种任务。 Context则很好地充当了这样的角色，它不但能控制下游的生命的生命周期，还自带超时控制、取消传递、并发安全、数据传递等功能： 取消传递：父Context的取消会自动传递到所有子孙Context，使得子孙Context也自动取消 超时控制：通过 context.WithTimeout 和 context.WithDeadline，提供自动超时取消机制 数据传递：可以携带请求范围内的数据（比如请求ID、path、begin timestamp等），这个特性在分布式链路追踪框架中被广泛使用 上面第二个场景中的代码换成Context来实现： import "context" func childSvc1(ctx context.Context) { cancel, ctx := context.WithCancel(ctx) // 创建子Context defer cancel() go childSvc1_1(ctx) go childSvr1_2(ctx) for { select { case ctx.Done(): return default: // 处理业务... // 因为某些原因需要取消下游服务 cancel() } } } 带超时控制的Context： ...