3. Go 并发模型基础：goroutine 与 channel、GMP 调度原理、并发安全与锁

在支付系统中，高并发是常态。Go 语言通过 goroutine 和 channel 提供了轻量级的并发原语，配合 GMP 调度器 实现高效的 M:N 调度。然而，并发也带来了数据竞争和死锁的风险，必须通过 锁 或 原子操作 来保证并发安全。本章将深入剖析这些核心概念，并结合支付场景中的慢查询与并发瓶颈进行讲解。

3.1 goroutine 与 channel：轻量级并发与通信

goroutine 是 Go 语言并发执行的最小单位，其栈空间初始仅几 KB，可动态伸缩，因此可以轻松创建数十万个 goroutine。channel 则是 goroutine 之间通信的桥梁，遵循“通过通信共享内存”的设计哲学。

3.2 GMP 调度原理：从 M:N 模型到工作窃取

Go 运行时实现了 GMP 调度模型，将用户级 goroutine 高效地映射到操作系统线程上。理解 GMP 是诊断并发瓶颈的关键。

• G (Goroutine)：代表一个待执行的任务，包含栈、指令指针、上下文等信息。
• M (Machine)：代表一个操作系统线程，由 Go 运行时管理。
• P (Processor)：代表一个逻辑处理器，是 G 和 M 之间的调度上下文。P 的数量由 GOMAXPROCS 决定，默认等于 CPU 核心数。

调度流程：M 必须绑定一个 P 才能执行 G。P 维护一个本地运行队列（LRQ），当 LRQ 为空时，P 会从全局运行队列（GRQ）或其他 P 的 LRQ 中“偷取”一半的 G（工作窃取算法）。

3.3 并发安全与锁：避免数据竞争

当多个 goroutine 同时访问共享变量时，必须保证 并发安全。Go 提供了 sync.Mutex、sync.RWMutex 和 sync/atomic 包来保护临界区。

3.3.1 锁的选择与对比

3.3.2 锁的常见陷阱与慢查询关联

• 锁争用（Lock Contention）：多个 goroutine 同时竞争同一把锁，导致大量 goroutine 阻塞在 Lock() 调用上。在支付系统中，若使用全局锁保护账户余额，高并发下会形成热点，吞吐量急剧下降。
• 死锁（Deadlock）：两个或多个 goroutine 互相等待对方释放锁。例如，转账操作中 A 锁住账户 A，等待账户 B 的锁；B 锁住账户 B，等待账户 A 的锁。
• 锁粒度不当：锁的粒度太粗（如锁住整个订单表）会导致并发度低；粒度太细（如每个字段一把锁）会增加锁开销和死锁风险。

// 错误示例：全局锁导致热点
var mu sync.Mutex
var balance map[string]int64

func Deduct(userID string, amount int64) error {
    mu.Lock()
    defer mu.Unlock()
    // 高并发下所有扣款请求串行化，性能极差
    if balance[userID] < amount {
        return errors.New("insufficient balance")
    }
    balance[userID] -= amount
    return nil
}

// 优化方案：分片锁（Shard Lock）
var shards [64]sync.Mutex
func getShard(userID string) *sync.Mutex {
    idx := hash(userID) % 64
    return &shards[idx]
}
func DeductOptimized(userID string, amount int64) error {
    mu := getShard(userID)
    mu.Lock()
    defer mu.Unlock()
    // 仅锁住当前用户的分片，不同用户可并发
    // ...
}

3.4 并发模型在支付场景中的综合应用

下图展示了 goroutine、channel、GMP 调度和锁在支付订单处理流程中的协作关系。