4. 支付业务中的并发陷阱：共享资源竞争、死锁、活锁、饥饿问题

在支付系统中，并发是提升吞吐量的核心手段，但也是引入不确定性和故障的主要来源。Go 语言虽然通过 goroutine 和 channel 简化了并发编程，但共享资源竞争、死锁、活锁、饥饿这四大陷阱在支付业务中依然频繁出现。理解它们的成因、表现和解决方案，是构建高可用支付系统的必修课。

4.1 共享资源竞争 (Race Condition)

当多个 goroutine 同时读写同一块共享内存（如账户余额、订单状态、库存数量），且至少有一个是写操作时，就会发生数据竞争。支付业务中典型的场景包括：

• 余额扣减：两个请求同时读取用户余额为 100 元，各自扣减 80 元和 50 元，最终写入结果取决于最后一个写入的 goroutine，导致余额不一致。
• 订单状态更新：支付成功回调和超时取消同时修改同一笔订单的状态，可能导致状态机跳转错误。
• 库存扣减：秒杀场景下多个 goroutine 同时读取和写入库存计数器，造成超卖。

4.2 死锁 (Deadlock)

死锁是指两个或多个 goroutine 互相等待对方释放资源，导致所有相关 goroutine 永久阻塞。支付系统中死锁的常见模式：

4.3 活锁 (Livelock)

活锁中 goroutine 并未阻塞，但一直在重复执行相同的操作却无法取得进展。它们互相谦让资源，导致系统空转。支付业务中的活锁案例：

• 重试风暴：两个服务互相调用，A 调用 B 超时后重试，B 调用 A 也超时后重试，双方不断重试但始终无法完成请求。
• 分布式锁竞争：多个节点同时尝试获取同一把分布式锁，获取失败后立即释放并重试，导致锁一直在节点间“跳舞”。
• 事务回滚循环：两个事务互相依赖对方提交的数据，检测到冲突后各自回滚并重试，反复冲突无法提交。

4.4 饥饿 (Starvation)

饥饿是指某个 goroutine 长期无法获得所需的资源，导致其任务无法执行。在支付系统中，饥饿通常表现为：

4.5 四大陷阱对比与检测

4.6 支付业务实战案例：余额扣减中的并发陷阱

以下是一个典型的余额扣减代码，展示了共享资源竞争和死锁问题：

// 问题代码：存在数据竞争
func DeductBalance(userID string, amount int64) error {
    balance := getBalanceFromDB(userID) // 读取
    if balance < amount {
        return ErrInsufficientBalance
    }
    newBalance := balance - amount
    updateBalanceToDB(userID, newBalance) // 写入
    return nil
}

// 修复方案1：使用 Mutex 保护
var mu sync.Mutex

func DeductBalanceSafe(userID string, amount int64) error {
    mu.Lock()
    defer mu.Unlock()
    balance := getBalanceFromDB(userID)
    if balance < amount {
        return ErrInsufficientBalance
    }
    newBalance := balance - amount
    updateBalanceToDB(userID, newBalance)
    return nil
}

// 修复方案2：使用原子操作 + 乐观锁（推荐）
func DeductBalanceOptimistic(userID string, amount int64) error {
    for retries := 0; retries < 3; retries++ {
        balance := getBalanceFromDB(userID)
        if balance < amount {
            return ErrInsufficientBalance
        }
        newBalance := balance - amount
        // UPDATE user_balance SET balance = ? WHERE user_id = ? AND balance = ?
        affected := updateBalanceWithCAS(userID, balance, newBalance)
        if affected > 0 {
            return nil
        }
        // CAS 失败，说明其他 goroutine 已修改余额，重试
    }
    return ErrConcurrentConflict
}

4.7 总结