3. 支付业务中的锁竞争：互斥锁 sync.Mutex、读写锁 sync.RWMutex、锁粒度优化策略

3.5 锁粒度选择决策表

在实际支付业务中，应根据具体场景选择合适的锁策略。以下决策表可帮助快速判断：

3.6 锁竞争排查与性能分析

Go 提供了内置的锁竞争检测工具，在支付业务性能调优中必须掌握：

• go test -race： 在测试阶段开启竞态检测，发现潜在的数据竞争。
• pprof 锁分析： 通过 runtime/pprof 或 net/http/pprof 采集锁等待时间，定位热点锁。
• trace 工具： 使用 go tool trace 可视化 goroutine 的阻塞和锁等待情况。

3.7 锁粒度优化实战：支付账户服务重构

以下是一个支付账户服务的锁优化案例，展示从粗粒度锁到分段锁的重构过程。

3.7.1 优化前：全局互斥锁

type AccountService struct {
    mu       sync.Mutex
    accounts map[string]*Account
}

func (s *AccountService) GetBalance(accountID string) float64 {
    s.mu.Lock()
    defer s.mu.Unlock()
    return s.accounts[accountID].Balance
}

func (s *AccountService) Transfer(from, to string, amount float64) error {
    s.mu.Lock()
    defer s.mu.Unlock()
    // 校验、扣减、增加、记录日志
    // 所有操作串行执行
}

3.7.2 优化后：分段锁 + 读写锁

type AccountShard struct {
    rwmu     sync.RWMutex
    accounts map[string]*Account
}

type AccountServiceOptimized struct {
    shards [64]*AccountShard
}

func (s *AccountServiceOptimized) getShard(accountID string) *AccountShard {
    idx := hash(accountID) % 64
    return s.shards[idx]
}

func (s *AccountServiceOptimized) GetBalance(accountID string) float64 {
    shard := s.getShard(accountID)
    shard.rwmu.RLock()
    defer shard.rwmu.RUnlock()
    return shard.accounts[accountID].Balance
}

func (s *AccountServiceOptimized) Transfer(from, to string, amount float64) error {
    // 注意：如果 from 和 to 在同一个分片，需要避免死锁
    fromShard := s.getShard(from)
    toShard := s.getShard(to)
    if fromShard == toShard {
        fromShard.rwmu.Lock()
        defer fromShard.rwmu.Unlock()
        // 执行转账逻辑
    } else {
        // 按分片 ID 顺序加锁，避免死锁
        if fromShard < toShard {
            fromShard.rwmu.Lock()
            toShard.rwmu.Lock()
        } else {
            toShard.rwmu.Lock()
            fromShard.rwmu.Lock()
        }
        defer fromShard.rwmu.Unlock()
        defer toShard.rwmu.Unlock()
        // 执行转账逻辑
    }
}

3.8 锁竞争与性能的平衡艺术

锁优化不是越细越好。过细的锁粒度会带来以下问题：

• 锁管理开销增加： 每个分片都需要独立的锁对象，内存占用和加锁/解锁的 CPU 开销上升。
• 死锁风险： 多锁场景下，必须严格遵循加锁顺序，否则容易死锁。
• 代码复杂度上升： 分段逻辑、哈希计算、跨分片操作都增加了代码维护成本。

在支付业务中，建议遵循以下原则：

1. 先测量，后优化： 使用 pprof 和 trace 工具定位真正的锁热点，不要过早优化。
2. 分片数适中： 通常设置为 CPU 核心数的 2~4 倍，或根据业务量选择 64/128/256 分片。
3. 读写锁谨慎使用： 只在读操作占比超过 80% 时使用 sync.RWMutex，否则写饥饿会抵消并发读的优势。
4. 考虑无锁替代方案： 对于简单的计数器、状态标志，优先使用 sync/atomic 包。