Redigo 的连接池在清理过期空闲连接时，会主动释放 mu 锁再调用 conn.Close()，这是为了避免长时间持有锁阻塞其他 goroutine，提升并发吞吐量。
redigo 的连接池在清理过期空闲连接时，会主动释放 `mu` 锁再调用 `conn.close()`，这是为了避免长时间持有锁阻塞其他 goroutine，提升并发吞吐量。
在 Redigo 的 Pool.get() 方法中，连接池需在获取新连接前主动清理已超时的空闲连接（即 idleConn.t.Add(IdleTimeout).Before(now) 的连接）。这一清理过程看似简单，却隐含关键的并发设计权衡：net.Conn.Close() 可能触发底层网络 I/O（如 TCP FIN 等待、linger 处理或 TLS 关闭握手），耗时不可控，从毫秒到数秒不等。若在持有 p.mu 期间直接调用 ic.c.Close()，将导致整个连接池被长期阻塞——所有其他调用 get() 或 put() 的 goroutine 都需等待该锁释放，严重拖慢整体吞吐。
因此，Redigo 采用“分段加锁”策略：
- 先加锁遍历 idle 链表，定位过期连接节点；
-
移除节点并调用
p.release()（减少活跃计数）后立即解锁； -
在无锁状态下安全执行
ic.c.Close()； - 重新加锁继续后续逻辑（如尝试复用剩余 idle 连接，或新建连接）。
这种设计明确分离了元数据操作（需线程安全，如修改 list.List、更新计数）与资源释放操作（I/O 密集、无需同步），符合 Go 并发编程中“锁粒度最小化”的最佳实践。
// 简化示意：关键锁边界清晰可见
p.mu.Lock()
e := p.idle.Back()
if isStale(e) {
p.idle.Remove(e)
p.release() // 仅更新内部状态
p.mu.Unlock() // ⚠️ 此刻释放锁，允许其他 goroutine 进入
ic.c.Close() // I/O 操作，在无锁上下文中执行
p.mu.Lock() // 重新加锁，继续池内逻辑
}
// ... 其余获取连接流程
p.mu.Unlock()
⚠️ 注意事项：
-
Close()调用本身不要求同步，因该连接已从idle链表移除，且Pool不再持有其引用（ic.c是独立副本）； -
p.release()必须在解锁前完成，确保连接计数准确，避免ActiveCount统计失真； - 若
Close()出现 panic（极罕见），需包裹recover（Redigo 实际源码中已处理），否则会导致锁未正确重入而死锁。
总结而言，这一设计不是权宜之计，而是对高并发 Redis 客户端的核心优化：以少量额外的锁切换开销（两次 Lock()/Unlock()），换取连接池整体响应性的显著提升。在 QPS 数千以上的服务中，该优化可降低 P99 延迟达 30%+，是 Redigo 稳定支撑生产环境的关键细节之一。
