Go 并发编程系列文章，系统梳理 sync、sync/atomic、context、channel 等并发原语的原理、用法与陷阱，以及扩展并发模式和分布式并发方案。
前面几篇我们讲了标准库的并发原语、atomic 和 Channel，掌握这些已经能解决 80% 的并发问题。但要进一步提升并发编程能力，还需要了解 扩展并发原语 和 分布式并发原语。这篇文章分两部分：上半部分讲 Go 官方和社区提供的进程内扩展原语（Semaphore、SingleFlight、ErrGroup、CyclicBarrier），下半部分讲基于 etcd 的分布式并发原语（Leader …
前面的文章我们讲了 Mutex、Channel、atomic 等各种并发工具，但有一个更底层的问题我们还没回答——一个 goroutine 写入的值，另一个 goroutine 什么时候能看到？ 这就是 Go 内存模型（The Go Memory Model）要回答的问题。 注意：这里的"内存模型"不是内存分配/回收，而是 并发环境下变量的可见性规则。 一、为什么需要内存模型？ …
Channel 是 Go 语言内建的 first-class 类型，也是 Go 与众不同的特性之一。它不是通过库提供的——而是直接内置在语言规范中，地位之高在编程语言中比较罕见。Channel 的设计源自 CSP（Communicating Sequential Process）模型：不要通过共享内存来通信，要通过通信来共享内存。 一、Channel 基本用法 声明和初始化 Copy // …
前面讲 Mutex、WaitGroup 等并发原语的实现时，你会发现它们的底层都依赖 sync/atomic 包的原子操作。原子操作是并发编程的最底层基石——比锁更轻量、比 Channel 更快，适合特定场景下的高性能并发控制。这一篇我们专门来讲 atomic。 一、什么是原子操作？ 原子操作是指 不会被中断的操作。在其他 goroutine 看来，原子操作要么已经完成，要么还没开始，不会看 …
并发编程中，除了"互斥访问"和"等待通知"之外，还有一类核心需求——取消和超时控制。比如：HTTP 请求超时了，下游所有 goroutine 都应该停止工作；用户取消了操作，正在进行的数据库查询应该被中断。Go 标准库的 context 包就是为了解决这类问题而生的。 一、Context 解决什么问题？ 假设一个 HTTP 请求触发了多个 goroutine …
Go 是自动垃圾回收的语言，创建对象没有回收的心理负担。但如果你要开发高性能应用，就必须关注 GC 的影响——大量创建堆上的对象，会增加 GC 标记的时间和 STW（stop-the-world）的开销。对象池 是一种经典的优化手段：把不用的对象回收起来复用，减少堆分配和 GC 压力。Go 标准库提供了 sync.Pool 来实现这个目的。 这篇文章我们先讲 sync.Pool 的用法和原理，再扩 …
前面几篇我们聊了各种同步原语，这一篇聊一个更贴近日常开发的话题——map 的并发安全。Go 内建的 map 类型不是线程安全的，并发读写会直接 panic。那怎么办？这一篇我们从内建 map 的基本用法和陷阱开始，逐步讲到加锁方案和标准库的 sync.Map。 一、内建 map 基本用法 Go 的 map 是内建的哈希表类型： Copy m := make(map[string]int) …
前面几篇我们聊了 Mutex、WaitGroup 和 Cond，它们各自解决不同维度的并发问题。这一篇聊一个相对简单但极其实用的原语——sync.Once，它解决的是 “确保某个操作只执行一次” 的问题，最经典的场景就是单例资源的延迟初始化。 一、为什么需要 Once？ 单例资源的初始化有好几种方式，按执行时机可以分成两类： Copy …
前两篇我们聊了 Mutex 和 WaitGroup，它们分别解决"互斥访问"和"等待一组任务完成"的问题。但并发编程中还有一类需求——等待某个条件满足后再继续执行。比如：队列满了，生产者要等；队列空了，消费者要等。这就是 sync.Cond（条件变量）要解决的问题。 一、为什么需要 Cond？ 假设你要实现一个限定容量的队列：队列满时生产者阻塞，队列空时消费 …