Golang on Chen Shungen

Go 扩展并发原语与分布式并发

Mon, 20 Apr 2026 14:27:00 +0800

前面几篇我们讲了标准库的并发原语、atomic 和 Channel，掌握这些已经能解决 80% 的并发问题。但要进一步提升并发编程能力，还需要了解 扩展并发原语 和 分布式并发原语。这篇文章分两部分：上半部分讲 Go 官方和社区提供的进程内扩展原语（Semaphore、SingleFlight、ErrGroup、CyclicBarrier），下半部分讲基于 etcd 的分布式并发原语（Leader 选举、分布式锁、队列、栅栏、STM）。

上篇：扩展并发原语

一、Semaphore（信号量）

什么是信号量？

信号量（Semaphore）是荷兰计算机科学家 Edsger Dijkstra 在 1963 年提出的并发原语，用来 控制多个 goroutine 同时访问多个资源。

它的核心是一个计数器（0 到 n），表示当前可用的资源数量：

┌────────────────────────────────────────────────────────────────┐
│ 信号量模型 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 初始资源数 = n │
│ │
│ Acquire (P 操作)：计数器 - 1 │
│ 计数器 > 0 → 成功获取，继续执行 │
│ 计数器 = 0 → 阻塞等待，直到有资源释放 │
│ │
│ Release (V 操作)：计数器 + 1 │
│ 唤醒一个等待中的 goroutine │
│ │
└────────────────────────────────────────────────────────────────┘

P/V 操作 的名称来自荷兰语：P（Proberen，尝试）减少信号量，V（Verhogen，增加）增加信号量。

Go 内存模型

Mon, 20 Apr 2026 14:25:00 +0800

前面的文章我们讲了 Mutex、Channel、atomic 等各种并发工具，但有一个更底层的问题我们还没回答——一个 goroutine 写入的值，另一个 goroutine 什么时候能看到？ 这就是 Go 内存模型（The Go Memory Model）要回答的问题。

注意：这里的"内存模型"不是内存分配/回收，而是 并发环境下变量的可见性规则。

一、为什么需要内存模型？

直觉上，代码应该按你写的顺序执行。但现实中有两个因素会打破这种直觉：

┌──────────────────────────────────────────────────────────────┐
│ 打破执行顺序的两个因素 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. 编译器重排 │
│ 编译器为了优化性能，可能调整指令执行顺序 │
│ 只要在单 goroutine 内语义不变，就允许重排 │
│ │
│ 2. CPU 多级缓存 │
│ 每个 CPU 核有自己的 L1/L2 缓存 │
│ 一个核写入的值不一定立即对其他核可见 │
│ │
└──────────────────────────────────────────────────────────────┘

看一个例子：

Go 并发原语 - Channel

Mon, 20 Apr 2026 14:00:00 +0800

Channel 是 Go 语言内建的 first-class 类型，也是 Go 与众不同的特性之一。它不是通过库提供的——而是直接内置在语言规范中，地位之高在编程语言中比较罕见。Channel 的设计源自 CSP（Communicating Sequential Process）模型：不要通过共享内存来通信，要通过通信来共享内存。

一、Channel 基本用法

声明和初始化

// 声明
var ch chan int // 双向 channel
var sendCh chan<- int // 只发送
var recvCh <-chan int // 只接收

// 初始化（必须用 make）
ch = make(chan int) // 无缓冲
ch = make(chan int, 10) // 有缓冲，容量 10

三种操作

┌──────────────────────────────────────────────────────────────┐
│ Channel 的三种操作 │
├──────────────────────────────────────────────────────────────┤
│ ch <- value 发送：把 value 放入 channel │
│ value := <-ch 接收：从 channel 取出值 │
│ close(ch) 关闭：关闭 channel │
└──────────────────────────────────────────────────────────────┘

无缓冲 vs 有缓冲

无缓冲 channel (make(chan int))：

 发送者 channel 接收者
 │ │ │
 │── send ────→ │ │
 │ (阻塞...) │ │
 │ │ ←── recv ────────│
 │ (解除阻塞) ──→│──→ (收到值) │
 │ │ │

 发送和接收必须同时就绪，类似"面对面交接"。


有缓冲 channel (make(chan int, 3))：

 发送者 buffer [_ _ _] 接收者
 │ │ │
 │── send ────→ [v _ _] (不阻塞) │
 │── send ────→ [v v _] (不阻塞) │
 │── send ────→ [v v v] (不阻塞) │
 │── send ────→ [v v v] (阻塞! 满了) │
 │ │ ←── recv ────────│
 │ (解除阻塞) ──→│──→ (取出一个值) │
 │ │ │

 缓冲未满时发送不阻塞，缓冲为空时接收阻塞。

二、Channel 的行为表

对 channel 执行不同操作，在不同状态下的行为：

Go 并发原语 - atomic

Mon, 20 Apr 2026 13:30:00 +0800

前面讲 Mutex、WaitGroup 等并发原语的实现时，你会发现它们的底层都依赖 sync/atomic 包的原子操作。原子操作是并发编程的最底层基石——比锁更轻量、比 Channel 更快，适合特定场景下的高性能并发控制。这一篇我们专门来讲 atomic。

一、什么是原子操作？

原子操作是指 不会被中断的操作。在其他 goroutine 看来，原子操作要么已经完成，要么还没开始，不会看到"执行了一半"的中间状态。

普通操作（count++，三步）： 原子操作（atomic.AddInt64，一步）：

 goroutine A goroutine B goroutine A goroutine B
 │ │ │ │
 │ 读取 count=5 │ │ │
 │ │ 读取 count=5 │ AddInt64(+1) │
 │ count=5+1=6 │ │ (不可分割) │
 │ 写回 count=6 │ count=5+1=6 │ │ AddInt64(+1)
 │ │ 写回 count=6 │ │ (不可分割)
 │ │ │ │
 结果：6（丢失一次+1）💀 结果：7（正确）✅

原子操作为什么能保证这一点？因为 CPU 硬件直接支持：

Go 并发原语 - Context

Mon, 20 Apr 2026 13:00:00 +0800

并发编程中，除了"互斥访问"和"等待通知"之外，还有一类核心需求——取消和超时控制。比如：HTTP 请求超时了，下游所有 goroutine 都应该停止工作；用户取消了操作，正在进行的数据库查询应该被中断。Go 标准库的 context 包就是为了解决这类问题而生的。

一、Context 解决什么问题？

假设一个 HTTP 请求触发了多个 goroutine 并行处理：

 HTTP 请求
 │
 ├── goroutine: 查询数据库
 ├── goroutine: 调用下游 API
 └── goroutine: 读取缓存

如果请求超时了（比如客户端断开连接），这三个 goroutine 应该如何知道"不用干了"？

没有 Context： 有 Context：

 请求超时 请求超时
 │ │
 │ 数据库查询还在跑... │── ctx.Done() 触发
 │ 下游 API 还在等... │── 所有 goroutine 收到信号
 │ 缓存读取还在等... │── 立即停止，释放资源
 │ │
 └── 资源浪费 💀 └── 干净退出 ✅

Context 提供了三个核心能力：

Go 并发原语 - Pool

Mon, 20 Apr 2026 12:30:00 +0800

Go 是自动垃圾回收的语言，创建对象没有回收的心理负担。但如果你要开发高性能应用，就必须关注 GC 的影响——大量创建堆上的对象，会增加 GC 标记的时间和 STW（stop-the-world）的开销。对象池 是一种经典的优化手段：把不用的对象回收起来复用，减少堆分配和 GC 压力。Go 标准库提供了 sync.Pool 来实现这个目的。

这篇文章我们先讲 sync.Pool 的用法和原理，再扩展到连接池和 Worker Pool。

一、sync.Pool 基本用法

sync.Pool 的 API 非常简洁：

┌─────────────────────────────────────────────────────────────┐
│ sync.Pool │
├─────────────────────────────────────────────────────────────┤
│ New func() any 创建新对象的工厂函数（Pool 为空时调用）│
│ Get() any 从池中取出一个对象 │
│ Put(x any) 把对象放回池中 │
└─────────────────────────────────────────────────────────────┘

一个典型的用法——复用 bytes.Buffer：

Go 并发原语 - Map

Mon, 20 Apr 2026 12:00:00 +0800

前面几篇我们聊了各种同步原语，这一篇聊一个更贴近日常开发的话题——map 的并发安全。Go 内建的 map 类型不是线程安全的，并发读写会直接 panic。那怎么办？这一篇我们从内建 map 的基本用法和陷阱开始，逐步讲到加锁方案和标准库的 sync.Map。

一、内建 map 基本用法

Go 的 map 是内建的哈希表类型：

m := make(map[string]int)
m["age"] = 28 // 写入
v := m["age"] // 读取
v, ok := m["name"] // 读取 + 检查是否存在
delete(m, "age") // 删除

key 的类型必须是 可比较的（comparable）——能用 == 和 != 比较：

┌──────────────────────────────────────────────────────────┐
│ ✅ 可以做 key 的类型 │
├──────────────────────────────────────────────────────────┤
│ bool、整数、浮点数、复数、字符串 │
│ 指针、Channel、接口 │
│ 所有字段都可比较的 struct │
│ 元素都可比较的数组 │
├──────────────────────────────────────────────────────────┤
│ ❌ 不能做 key 的类型 │
├──────────────────────────────────────────────────────────┤
│ slice、map、函数 │
└──────────────────────────────────────────────────────────┘

struct 做 key 的坑

用 struct 做 key 时要特别小心——修改了 struct 字段后，就再也找不到原来的值了：

Go 并发原语 - Once

Mon, 20 Apr 2026 11:30:00 +0800

前面几篇我们聊了 Mutex、WaitGroup 和 Cond，它们各自解决不同维度的并发问题。这一篇聊一个相对简单但极其实用的原语——sync.Once，它解决的是 “确保某个操作只执行一次” 的问题，最经典的场景就是单例资源的延迟初始化。

一、为什么需要 Once？

单例资源的初始化有好几种方式，按执行时机可以分成两类：

┌─────────────────────────────────────────────────────────────┐
│ 程序启动时初始化 │
├─────────────────────────────────────────────────────────────┤
│ 1. package 级别变量 var startTime = time.Now() │
│ 2. init 函数 func init() { startTime = ... } │
│ 3. main 函数中调用 func main() { initApp() } │
│ │
│ ✅ 天然线程安全（Go 保证 init 串行执行） │
│ ❌ 无法延迟——程序启动就初始化，不管用不用得上 │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ 首次使用时初始化（延迟初始化） │
├─────────────────────────────────────────────────────────────┤
│ 需要自己保证线程安全 │
│ ✅ 按需初始化，不浪费资源 │
│ ❌ 并发控制是个问题 │
└─────────────────────────────────────────────────────────────┘

延迟初始化更灵活，但并发安全怎么办？最直接的想法是用 Mutex：

Go 并发原语 - Cond

Mon, 20 Apr 2026 11:00:00 +0800

前两篇我们聊了 Mutex 和 WaitGroup，它们分别解决"互斥访问"和"等待一组任务完成"的问题。但并发编程中还有一类需求——等待某个条件满足后再继续执行。比如：队列满了，生产者要等；队列空了，消费者要等。这就是 sync.Cond（条件变量）要解决的问题。

一、为什么需要 Cond？

假设你要实现一个限定容量的队列：队列满时生产者阻塞，队列空时消费者阻塞。没有 Cond 的话，你可能会这样写：

// ❌ 轮询方案：浪费 CPU，响应慢
for len(queue) == maxSize {
 time.Sleep(10 * time.Millisecond) // 空转等待
}
queue = append(queue, item)

这种轮询方式有两个严重问题：

问题 1：CPU 空转 问题 2：响应延迟

 CPU 条件满足
 ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ──●──────────────┐
 │?│ │?│ │?│ │?│ │?│ ← 反复空问 │ 等待下一次轮询
 └─┘ └─┘ └─┘ └─┘ └─┘ ─────────────────●
 全是无效检查 最多延迟 10ms

Cond 的方案则是：条件不满足就阻塞休眠，条件满足后立即唤醒，零空转、零延迟。

Go 并发原语 - WaitGroup

Mon, 20 Apr 2026 10:30:00 +0800

上一篇我们聊了 Mutex，它解决的是"同一时刻只能有一个 goroutine 访问共享资源"的问题。但并发编程中还有另一类常见需求——等待一组任务全部完成后再继续。这就是 sync.WaitGroup 要解决的问题。

一、为什么需要 WaitGroup？

假设你要并行执行三个子任务，全部完成后才能进入下一步。没有 WaitGroup 的话，你可能会这样写：

// ❌ 轮询方案：又慢又浪费 CPU
done1, done2, done3 := false, false, false

go func() { /* 任务1 */ done1 = true }()
go func() { /* 任务2 */ done2 = true }()
go func() { /* 任务3 */ done3 = true }()

for !done1 || !done2 || !done3 {
 time.Sleep(100 * time.Millisecond) // 空转等待
}

这种轮询方式有两个问题：

问题 1：响应慢 问题 2：浪费 CPU

 任务完成 CPU
 ──●────────────┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐
 │ 等待轮询 │?│ │?│ │?│ │?│ │?│ ← 反复空问
 ───────────────● └─┘ └─┘ └─┘ └─┘ └─┘
 最多延迟 100ms 全是无效检查

WaitGroup 的方案则是：任务没完成就阻塞，全部完成后立即唤醒，零延迟、零空转。

Go 并发原语 - Mutex

Mon, 20 Apr 2026 10:00:00 +0800

并发编程是 Go 的灵魂，而 Mutex（互斥锁） 是并发控制的第一道防线。这篇文章带你从"为什么需要锁"开始，一路走到 Mutex 的演进原理、常见坑点和读写锁 RWMutex，争取一文把 Mutex 讲透。

一、没有锁的世界有多危险？

先看一个经典的并发计数器问题：

package main

import (
	"fmt"
	"sync"
)

func main() {
	var count int
	var wg sync.WaitGroup

	for i := 0; i < 10000; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			count++ // 非原子操作：读取 → 加1 → 写回
		}()
	}

	wg.Wait()
	fmt.Println("count:", count) // 几乎不可能是 10000
}

多次运行，结果可能是 9831、9917、9756……每次都不一样。这就是典型的 数据竞争（Data Race）。

Go 语言后端开发实践总结

Wed, 15 Apr 2026 00:00:00 +0000

为什么选择 Go？

Go 语言在后端开发中的优势不言而喻：

编译速度快：秒级编译，开发体验流畅
并发原语优秀：goroutine + channel 模型简洁强大
部署简单：单二进制文件，无依赖
性能优异：接近 C 的性能，远超脚本语言

项目结构推荐

project/
├── cmd/ # 应用入口
│ └── server/
│ └── main.go
├── internal/ # 内部包（不对外暴露）
│ ├── handler/ # HTTP 处理器
│ ├── service/ # 业务逻辑
│ ├── repository/ # 数据访问
│ └── model/ # 数据模型
├── pkg/ # 可复用的公共包
├── api/ # API 定义（proto/openapi）
├── config/ # 配置文件
└── deploy/ # 部署相关

错误处理模式

Go 的错误处理虽然冗长，但有其设计哲学。推荐的做法：