Chen Shungen

塞尔达传说：旷野之息

Thu, 16 Apr 2026 00:00:00 +0000

开放世界冒险的巅峰之作。在广袤的海拉鲁大陆上自由探索，攀爬、滑翔、战斗，用你的方式书写属于自己的传说。

超级马力欧奥德赛

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

马力欧的环球冒险之旅。抛出帽子附身万物，在沙漠、都市、海洋等奇妙国度中收集力量之月，拯救碧姬公主。

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）。

游戏服务器开发实战笔记

Sun, 19 Apr 2026 00:00:00 +0000

这篇文章整合了我在游戏服务器开发过程中积累的几个核心主题的实践经验，时间跨度从 2018 到 2022 年。内容涵盖 3D 寻路、唯一 ID 生成、Go Plugin 热更新、通信安全加密，以及 Go 性能优化技巧。

一、3D 寻路：RecastNavigation 在游戏服务器中的应用

最初发表于 2018 年，记录了将 RecastNavigation 应用于游戏服务器的完整过程。

背景

RecastNavigation 是一个开源的 Navigation-mesh Toolset for Games，核心功能包括 3D 寻路、控制 Agent 行走/移动、动态添加阻挡、动态改变地形。

值得一提的是，RecastNavigation 其实就是 Unity3D 引擎自带的 Navigation 寻路模块的前身——这一点我曾在 Google Group 里和作者 memononen 确认过。

为什么要在服务器上做寻路

客户端做寻路很容易，现代游戏引擎都内置了这些工具。但在服务器上实现 3D 寻路，对于 AI 控制、反外挂验证等场景至关重要。RecastNavigation 用 C++ 实现，可以很方便地嵌入到 C++、Go、Python 等语言的服务器程序中。

从 Unity 导出地图

以 Unity 为客户端为例，有两种方式导出地图供 RecastNavigation 使用：

方式一：导出 Unity 已 bake 好的 NavMesh

使用导出脚本将 Unity 中生成好的 NavMesh 导出为 obj 文件，然后放入 RecastNavigation 生成寻路网格。这种方式最直接，导出的 NavMesh 与 Unity 中一致。

我的开发者收藏夹：那些年攒下的技术链接

Sat, 18 Apr 2026 00:00:00 +0000

从 WordPress 迁移到 Hugo 的过程中，翻到了旧站上的「记事本」页面——一个从 2017 年就开始积攒的链接收藏夹。这些链接记录了我在不同阶段关注的技术方向，与其让它们躺在旧站里吃灰，不如整理出来，也算是一份个人技术成长的缩影。

注意：部分链接年代久远，可能已经失效。

博客推荐

鸟窝博客 — Go 语言领域非常活跃的中文博主
云风的博客 — 游戏开发圈的前辈，写了二十多年博客

Go 语言

Go 知识图谱 — 一张思维导图串起 Go 的核心知识点
Go101 — 系统性地深入 Go 语言细节
Go 并发常见错误 — 并发编程踩坑指南
So You Wanna Go Fast? — Go 性能优化实战
Go SkipList 实现 — 跳表的 Go 实现参考
go 标准库 rpc 实践 — net/rpc 使用指南
Go-Kit — Go 微服务框架入门
map for readonly access will always remain thread-safe? — golang-nuts 上关于 map 并发安全的经典讨论

算法与数据结构

经典算法 — GeeksforGeeks 竞赛编程算法合集
动态规划：最长公共子序列 + 最长公共子字符串 — DP 经典题目详解
限流之固定窗口/滑动窗口计数法 — 限流算法原理

Kubernetes

C / C++

Modern C++ Features (C++11/14/17) — 新标准特性速查
C++ Standards Support in GCC — GCC 各版本对 C++ 标准的支持情况
Free/Delete Not Returning Memory To OS? — 内存释放后为什么系统看不到？
cc1.exe: sorry, unimplemented: 64-bit mode not compiled in — MinGW 64 位编译报错解决

数据库

工具与编辑器

regex101 — 在线正则表达式测试，调正则必备
VSCode Vim 模式插件
Vim: Capitalize first letter of each word — Vim 批量首字母大写技巧
简历模板 — Office 官方简历模板

Linux / 运维

git rebase 丢失 commit 找回 — reflog + cherry-pick 救命指南
linux awk 命令统计排名单词出现次数
Linux 脚本只允许单实例运行

Python

Working with Binary Data in Python

关于

Thu, 16 Apr 2026 00:00:00 +0000

用 AI 重构我的个人网站：从 WordPress 到 Hugo

Thu, 16 Apr 2026 00:00:00 +0000

为什么要告别 WordPress？

WordPress 是一个优秀的内容管理系统，但对于一个想要通过 AI 工具（如 Claude Code）来管理内容的开发者来说，它有几个痛点：

内容存储在数据库中，AI 工具无法直接读写
PHP + MySQL 的技术栈维护成本高
安全更新需要频繁关注
动态渲染相比静态站点速度慢

新方案：Hugo + Adritian

最终选择了 Hugo 作为静态站点生成器，配合 Adritian 主题：

内容即文件：所有文章都是 Markdown 文件，存储在 Git 仓库中
AI 友好：Claude Code 可以直接创建和编辑 .md 文件
零维护：纯静态 HTML，没有数据库，没有后端
极速：毫秒级页面加载

技术栈

组件	选择	原因
静态生成器	Hugo	Go 构建，速度极快
主题	Adritian	专业网站风格，非纯博客
部署	阿里云 ECS	国内访问最快，已有备案
CI/CD	GitHub Actions	git push 自动构建部署

AI 内容发布流程

Claude Code 写 Markdown → git push → GitHub Actions 构建 → 部署到 ECS

整个过程零人工干预，从写作到上线完全自动化。

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 的错误处理虽然冗长，但有其设计哲学。推荐的做法：

分布式系统设计要点

Tue, 14 Apr 2026 00:00:00 +0000

分布式系统的核心挑战

分布式系统面临的根本挑战可以用 CAP 定理来概括——一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者不可兼得。

在实际工程中，我们几乎总是需要保证分区容错性，因此核心的权衡在于：

CP 系统：优先一致性，如 ZooKeeper、etcd
AP 系统：优先可用性，如 Cassandra、DynamoDB

服务间通信

常见的服务间通信方式：

方式	适用场景	优势	劣势
gRPC	内部服务调用	高性能、强类型	调试不如 REST 方便
REST	外部 API	通用、易理解	性能较低
消息队列	异步解耦	削峰、解耦	复杂度增加

关键设计原则

幂等性：所有写操作都应该是幂等的
超时与重试：设置合理的超时，使用指数退避重试
熔断降级：防止级联故障
可观测性：日志、指标、链路追踪三者缺一不可

总结

分布式系统没有银弹。好的系统设计来自对业务场景的深入理解和对技术取舍的清晰认识。

Footer

Mon, 01 Jan 0001 00:00:00 +0000

Home

Mon, 01 Jan 0001 00:00:00 +0000

搜索

Mon, 01 Jan 0001 00:00:00 +0000

搜索

Chen Shungen

塞尔达传说：旷野之息

超级马力欧 奥德赛

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

上篇：扩展并发原语

一、Semaphore（信号量）

什么是信号量？

Go 内存模型

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

Go 并发原语 - Channel

一、Channel 基本用法

声明和初始化

三种操作

无缓冲 vs 有缓冲

二、Channel 的行为表

Go 并发原语 - atomic

一、什么是原子操作？

Go 并发原语 - Context

一、Context 解决什么问题？

Go 并发原语 - Pool

一、sync.Pool 基本用法

Go 并发原语 - Map

一、内建 map 基本用法

struct 做 key 的坑

Go 并发原语 - Once

一、为什么需要 Once？

Go 并发原语 - Cond

一、为什么需要 Cond？

Go 并发原语 - WaitGroup

一、为什么需要 WaitGroup？

Go 并发原语 - Mutex

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

游戏服务器开发实战笔记

一、3D 寻路：RecastNavigation 在游戏服务器中的应用

背景

为什么要在服务器上做寻路

从 Unity 导出地图

我的开发者收藏夹：那些年攒下的技术链接

博客推荐

Go 语言

算法与数据结构

推荐书籍

Kubernetes

C / C++

数据库

工具与编辑器

Linux / 运维

Python

关于

用 AI 重构我的个人网站：从 WordPress 到 Hugo

为什么要告别 WordPress？

新方案：Hugo + Adritian

技术栈

AI 内容发布流程

Go 语言后端开发实践总结

为什么选择 Go？

项目结构推荐

错误处理模式

分布式系统设计要点

分布式系统的核心挑战

服务间通信

关键设计原则

总结

Footer

Home

推荐游戏

塞尔达传说：旷野之息

超级马力欧 奥德赛

搜索

超级马力欧奥德赛

超级马力欧奥德赛