《游戏服务端编程实践》13.1 Goroutine/Actor 调度优化

一、先回到 GMP：调度器到底在调度什么

Go 运行时把 goroutine（G）放到逻辑处理器（P）的本地队列里，再由操作系统线程（M）取出执行。理解这三个角色，才能判断一个游戏服务端的卡顿究竟来自业务锁、系统调用，还是调度器本身。

这里有两个容易被忽略的细节。第一，网络读写等待不占 M：Go 的 netpoll 会把等待 socket 的 G 挂起，数据到达后再放回运行队列，所以“一万个连接就一万个线程”是错误直觉。第二，文件 I/O、cgo 调用和部分系统调用会阻塞 M：运行时会尝试把 P 交给其他 M，但如果阻塞调用很多，线程数仍会上升，P 也可能被腾挪，带来额外的调度延迟。

1.1 P 的数量与游戏帧预算

GOMAXPROCS 决定同时执行 Go 代码的 P 数量。它不是越大越好：P 多于物理核心时，CPU 缓存和内存带宽会成为瓶颈；P 少于核心时，CPU 又跑不满。对于以 tick 驱动的房间服务器，常见的起点是“物理核心数”，再用压测确认 GC 与网络回调是否把尾延迟推高。

如果业务依赖线程亲和性，例如某些图形库、音频库或第三方 SDK 要求固定线程，可以使用 runtime.LockOSThread。但锁定后这个 G 会绑定到当前 M，不能再被调度到其他线程，滥用会让 P 与 M 的配比失衡。锁定应局限在极少数必须线程绑定的调用上，而不是给整个房间循环加锁。

1.2 阻塞系统调用为什么会伤害 tick

假设一个房间的 tick 每 50 毫秒执行一次，其中某一步同步写日志文件。写文件可能等待磁盘，G 进入阻塞系统调用，运行时会把这个 M 与 P 解绑，让其他 M 接管 P。单次看似没事，但当大量房间同时写日志时，线程数上升、P 频繁交接，tick 的抖动会明显变大。

处理方式不是“把日志改成异步”就结束，而是要把所有可能阻塞的操作从 tick 路径里移出去：日志进入有界队列，由独立 worker 批量落盘；数据库访问通过连接池和异步结果回投；第三方 SDK 调用放进专用 goroutine，并用 channel 把结果送回房间。tick 路径只做内存计算和消息入队。

二、goroutine 数量不是越多越好

goroutine 很便宜，但“便宜”不等于“免费”。每个 goroutine 有初始栈、调度元数据和退出清理成本；大量 goroutine 还会让运行队列变长、GC 扫描对象变多、尾延迟更难预测。游戏服务端真正需要的是受控的并发度，而不是无限的并发。

一个常见的误区是把“异步”等同于“开 goroutine”。异步的本质是“调用方不等待结果”，不是“每个动作都新建执行体”。固定数量的 worker 从队列取任务，同样能实现异步，而且并发上限明确、排队长度可观测、 shutdown 时也容易排空。

三、Actor 模型：把共享状态收进单线程

Actor 的核心约束只有一句话：一个 Actor 的状态只由它自己的消费循环修改。外部不直接读写状态，而是把消息放进 mailbox；消费循环按顺序取出消息、处理、更新状态。这样，房间、背包、公会等对象内部不再需要为每个字段加锁。

在 Go 里，Actor 通常表现为“一个 goroutine + 一个 channel 或有界队列”。它解决的问题不是“让代码更时髦”，而是把锁的粒度从“每个字段”提升到“每个对象”，把并发正确性变成顺序正确性。

3.1 投递语义要说清楚

内存中的 mailbox 通常只能提供“最多一次”的投递保证：消息成功入队后，Actor 会处理一次；如果处理过程中进程崩溃，消息就丢了。想让消息不丢，必须把 mailbox 持久化，或者在上游记录待确认状态并在重启后重放。

同一 Actor 内的消息顺序由 mailbox 保证；跨 Actor 没有全局顺序。两个玩家几乎同时交易时，各自 Actor 看到的先后可能不同。解决跨 Actor 顺序问题不能靠“再加一把大锁”，而要靠业务上的版本号、唯一请求 ID 或单点仲裁者。

3.2 Actor 与锁的取舍

Actor 不是“无锁”，它把锁换成了队列和单线程。它适合状态内聚、消息边界清晰的对象，例如房间、副本、公会；不适合需要跨对象强一致、或者单对象吞吐已经超过单核能力的场景。后者要么分片，要么回到更细粒度的并发结构。

四、有界 mailbox 才有背压

无界队列会把“下游变慢”伪装成“系统还能接收”。生产者继续入队，内存持续上涨，直到 OOM 才暴露问题。有界 mailbox 则把压力传回生产者：队列满了，生产者要么等待，要么拒绝，要么丢弃。

选择哪种策略取决于消息语义。位置同步可以丢弃中间帧，只保留最新位置；聊天消息不能静默丢弃，应该拒绝并提示发送方；奖励发放既不能丢也不能重复，必须走持久化队列和幂等消费。

4.1 容量怎么估

一个粗略的起点是用 Little 定律：平均排队长度 ≈ 到达速率 × 平均处理时间。例如某个房间每秒收到 200 条消息，单条平均处理 0.2 毫秒，那么平均在途约 200 × 0.0002 = 0.04 条，容量取几十已经足够吸收突发。这个数字是示例值，真实容量必须用生产流量分布和压测确认，不能照抄。

容量太小会让正常突发频繁触发背压，容量太大则会让故障时的排队时间变长、内存占用变高。更稳妥的做法是同时设置“队列长度上限”和“排队时间上限”：消息在队列里等待超过预算就拒绝或降级，而不是无限等待。

五、调度优化的几个具体手段

5.1 固定 worker pool，而不是按请求建 goroutine

把“每个请求一个 goroutine”改成“固定 N 个 worker 从有界队列取任务”，可以同时获得三个好处：并发度可控、下游连接池不会被瞬间打满、队列长度成为可直接观测的背压指标。N 的取值应围绕下游容量来定，而不是围绕 CPU 核数拍脑袋。

5.2 批量处理，减少调度与系统调用次数

网络包可以攒批读取，日志可以攒批写入，数据库可以批量提交。批量的收益来自摊薄固定成本：一次系统调用处理十条消息，通常比十次系统调用处理十条消息更划算。但批量会增加单条消息的等待时间，所以要有“批量上限”和“超时上限”，不能为了凑批把延迟无限拉长。

5.3 按房间或玩家分片，避免全局热点

全局排行榜、全服邮件、跨服匹配天然是热点。可行的做法包括按玩家 ID 哈希分片、把全服广播拆成多个批次、把排行榜更新改成周期快照而不是每次实时重排。分片的关键是保证同一实体的消息总落到同一个分片，否则顺序又会丢失。

5.4 不在锁内做 I/O

锁内做 I/O 是最常见的尾延迟来源之一。正确顺序是：在锁内只做状态判断和必要的内存修改，把 I/O 所需的数据复制出来，释放锁后再执行网络或磁盘操作。Actor 也一样：消费循环里不要直接调用可能阻塞的数据库或第三方 SDK，应该把结果通过另一个消息投递回来。

5.5 用 benchmark 证明，而不是猜

优化前后至少记录四类数据：单次操作耗时、每次操作分配次数、分配字节数、并发下的尾延迟。Go 自带的 benchmark 能给出前三类，尾延迟则需要自定义压测。比较时必须使用同一台机器、同一份负载、同一个 Go 版本，并且串行运行，避免其他构建或测试抢占 CPU。

六、失败场景：每条消息一个 goroutine

某活动需要向全服玩家广播一条公告。实现方式是遍历在线玩家，为每个玩家启动一个 goroutine 写连接。活动开始瞬间创建了数万个短命 goroutine，每个 goroutine 还要竞争写锁和执行网络写。结果不是“广播更快”，而是调度队列暴涨、写锁竞争加剧、部分连接超时，随后客户端重连又把接入层打了一遍。

正确的做法是固定写 worker 数量，按连接分片批量发送；发送队列有界，队列满时记录指标并拒绝新增广播，而不是继续创建 goroutine。广播的“完成时间”可能略长，但系统不会因为一次活动进入雪崩。

七、可运行实现：带缓冲 mailbox 的 Actor

下面的实现把“在途消息”定义为“排队中 + 正在处理”，因此容量为 1 时，第二条 Send 一定会等待第一条处理完，背压边界清晰。消费循环是唯一的 Handler 执行者；Close 停止接收新消息，并等待已经接收的消息全部处理完才返回。

// file: ch13/actor/actor.go
// tier: L1
// verify: go test ./ch13/actor/

package actor

import (
	"errors"
	"sync"
)

var (
	// ErrMailboxFull 表示非阻塞投递时 mailbox 已满。
	ErrMailboxFull = errors.New("actor: mailbox full")
	// ErrActorClosed 表示 Actor 已关闭，不再接受新消息。
	ErrActorClosed = errors.New("actor: actor closed")
)

// Message 是投递给 Actor 的最小消息单元。
//
// ID 由发送方按业务需要保证有序；Actor 只保证同一个 mailbox
// 内的消息按投递顺序被处理，不解释 ID 的语义。
type Message struct {
	ID   uint64
	Kind string
	Body any
}

// Handler 处理单条消息。同一个 Actor 的 Handler 永远不会并发执行。
type Handler func(Message)

// Actor 是一个带缓冲 mailbox 的单消费者执行体。
//
// 所有消息由唯一的 loop goroutine 顺序取出并交给 Handler，
// 因此 Handler 内不需要再为状态加锁。mailbox 的容量同时包含
// “正在处理”的消息，Send 在满载时阻塞，形成从消费者到生产者
// 的背压。
type Actor struct {
	mu          sync.Mutex
	cond        *sync.Cond
	queue       []Message
	capacity    int
	outstanding int
	handler     Handler
	closed      bool
	done        chan struct{}
}

// New 创建一个 Actor 并启动消费 goroutine。
//
// buffer 是同时在途（排队 + 正在处理）的消息上限，小于 1 时
// 按 1 处理。handler 为 nil 时消息会被取出并丢弃，便于单独
// 验证 mailbox 的背压与关闭行为。
func New(buffer int, handler Handler) *Actor {
	if buffer < 1 {
		buffer = 1
	}
	a := &Actor{
		capacity: buffer,
		handler:  handler,
		done:     make(chan struct{}),
	}
	a.cond = sync.NewCond(&a.mu)
	go a.loop()
	return a
}

// Send 阻塞投递一条消息。
//
// mailbox 满载时 Send 等待消费者释放容量，把压力传回生产者。
// Actor 关闭后 Send 立即返回 ErrActorClosed；正在等待容量的
// 调用也会被 Close 唤醒并返回同一个错误。
func (a *Actor) Send(msg Message) error {
	a.mu.Lock()
	defer a.mu.Unlock()
	for a.outstanding >= a.capacity && !a.closed {
		a.cond.Wait()
	}
	if a.closed {
		return ErrActorClosed
	}
	a.enqueueLocked(msg)
	return nil
}

// TrySend 尝试非阻塞投递；mailbox 满载时返回 ErrMailboxFull。
//
// 适合“宁可丢弃也不能卡住网络线程”的场景，例如位置同步中的
// 低频中间帧。丢弃策略必须由调用方记录指标，不能静默吞掉。
func (a *Actor) TrySend(msg Message) error {
	a.mu.Lock()
	defer a.mu.Unlock()
	if a.closed {
		return ErrActorClosed
	}
	if a.outstanding >= a.capacity {
		return ErrMailboxFull
	}
	a.enqueueLocked(msg)
	return nil
}

// enqueueLocked 必须在持有 a.mu 时调用。
func (a *Actor) enqueueLocked(msg Message) {
	a.queue = append(a.queue, msg)
	a.outstanding++
	a.cond.Broadcast() // 唤醒可能在等待队列非空的 loop
}

// Close 停止接收新消息，并等待已经接收的消息全部处理完。
//
// Close 可以重复调用。关闭后 Send 与 TrySend 返回 ErrActorClosed。
// Handler 内不要同步调用本 Actor 的 Close 或满载的 Send，否则会
// 自己等待自己。
func (a *Actor) Close() {
	a.mu.Lock()
	if a.closed {
		a.mu.Unlock()
		<-a.done
		return
	}
	a.closed = true
	a.cond.Broadcast()
	a.mu.Unlock()
	<-a.done
}

// Outstanding 返回排队中与正在处理的消息总数，用于观测背压。
func (a *Actor) Outstanding() int {
	a.mu.Lock()
	defer a.mu.Unlock()
	return a.outstanding
}

// Capacity 返回创建时确定的在途消息上限。
func (a *Actor) Capacity() int {
	return a.capacity
}

// Done 在消费 goroutine 退出后关闭，便于外部等待 Actor 结束。
func (a *Actor) Done() <-chan struct{} {
	return a.done
}

func (a *Actor) loop() {
	defer close(a.done)
	for {
		a.mu.Lock()
		for len(a.queue) == 0 && !a.closed {
			a.cond.Wait()
		}
		if len(a.queue) == 0 {
			// 只有 closed 且已排空才会走到这里。
			a.mu.Unlock()
			return
		}
		msg := a.queue[0]
		a.queue[0] = Message{} // 避免底层数组继续引用 Body
		a.queue = a.queue[1:]
		a.mu.Unlock()

		a.handle(msg)

		a.mu.Lock()
		a.outstanding--
		a.cond.Broadcast() // 唤醒等待容量的 Send/TrySend
		a.mu.Unlock()
	}
}

func (a *Actor) handle(msg Message) {
	if a.handler != nil {
		a.handler(msg)
	}
}

实现里有几个刻意选择。第一，用互斥锁加条件变量而不是裸 channel，是为了让“容量包含正在处理的消息”这件事可以被精确表达；裸 channel 的缓冲只统计排队消息，消费者取走消息后队列就空出位置，背压会比预期晚一步。第二，TrySend 提供非阻塞的拒绝路径，适合允许丢弃的流。第三，Close 会排空已接收消息，避免“关闭时丢掉已经答应处理的消息”。

测试覆盖五个边界：消息按投递顺序处理、满载时 Send 阻塞、TrySend 在满载时返回 ErrMailboxFull、Close 排空已接收消息并拒绝新消息、Close 唤醒正在等待容量的发送者。运行方式：

cd .local/checks/gs-practice-lab
gofmt -l ch13/actor
go vet ./ch13/actor/
go test ./ch13/actor/ -count=1

7.1 Handler 里不能做什么

Handler 由唯一的消费 goroutine 执行，因此它里面不能同步调用同一个 Actor 的 Send 或 Close。满载时 Send 会等待自己释放容量，Close 会等待自己退出，两者都会死锁。需要“处理完再投递”时，应该把后续消息交给另一个 Actor，或者先返回、由外部在下一轮投递。

Handler 里也不应该做长时间阻塞的 I/O。消费循环被阻塞时，mailbox 很快会被填满，所有发送者一起被拖住。正确做法是把 I/O 请求交给专用 worker，结果通过消息回到 Actor；如果必须同步等待，就要接受这个 Actor 的吞吐上限，并为它设置独立的超时和降级策略。

7.2 panic 与可观测性

Handler panic 会沿着消费 goroutine 向上传播，最终让整个进程退出。生产代码应在 Handler 外层加 recover，记录消息类型和堆栈，然后决定是跳过这条消息还是关闭 Actor。跳过意味着状态可能只更新了一半，所以更稳妥的做法是把 Handler 设计成“先校验、再修改、最后投递副作用”，让 panic 发生在状态修改之前。

至少要观测四个指标：mailbox 当前长度、Send 等待时长、TrySend 拒绝次数、单条消息处理耗时。没有这些指标，背压只会在事故发生时以“玩家操作没反应”的形式出现。

八、和 13.2 的衔接

Actor 解决了“状态由谁修改”的问题，但没有解决“消息本身如何低成本地传递”。高频位置同步会在 mailbox 和缓冲区里产生大量短命对象，分配与 GC 会成为新的瓶颈。下一篇 /game-server-in-action-13-2/ 会讨论无锁结构的适用边界、sync.Pool 与对象复用，以及 SPSC 环形缓冲区的实现要点。

小结

GMP 决定了 goroutine 在哪里、以多大并行度执行；Actor 把对象状态的并发修改收敛为单线程顺序处理；有界 mailbox 把下游压力传回上游，避免无界队列掩盖故障。调度优化的顺序应该是先减少不必要的 goroutine 和阻塞点，再考虑批量、分片与池化，最后用 benchmark 和尾延迟数据验证改动是否真的有效。

常见错误与边界

• 为每条消息启动一个 goroutine，既丢失顺序，又把调度器变成瓶颈。
• 使用无界 mailbox，故障时内存持续上涨，直到 OOM 才暴露。
• 在 Actor 的 Handler 里同步调用同一个 Actor 的 Send 或 Close，造成自等待死锁。
• 在锁内或 Actor 消费循环里执行数据库、文件、第三方 SDK 等阻塞操作。
• 把 GOMAXPROCS 调得远大于物理核心，误以为并发度越高吞吐越高。
• 只用平均耗时判断优化效果，忽略 p99 和 goroutine 数量的变化。
• 跨 Actor 依赖消息到达顺序，却没有版本号、请求 ID 或单点仲裁。