Go 的 net/rpc 不支持连接池，需手动管理 *rpc.Client 实例；sync.Pool 易致连接泄漏，推荐用带健康检测的自定义 RPCPool 或第三方库。
Go 的 net/rpc 本身不支持连接池
直接用 rpc.Dial 或 rpc.DialHTTP 每次都新建 TCP 连接，频繁调用会导致 TIME_WAIT 积压、FD 耗尽、延迟升高。官方 net/rpc 包是无状态的客户端封装，*rpc.Client 实例内部持有单个 net.Conn，不可复用到多个请求——它不是“池”，只是单连接代理。
所以所谓“RPC 客户端池”，本质是手动管理一批预先建立的 *rpc.Client 实例，并控制其生命周期。
用 sync.Pool 管理 *rpc.Client 实例可行但需谨慎
sync.Pool 适合缓存临时对象，但它不保证对象存活，GC 时可能被清除；而 *rpc.Client 关联着底层 net.Conn，不能随意丢弃未关闭的连接，否则泄漏 socket。
- 必须在
Pool.New中创建新连接并返回新*rpc.Client - 取出后使用前，需检查连接是否仍可用（比如调用
client.Call时捕获io.EOF或net.OpError） - 归还时不能直接放回 Pool：要先调用
client.Close()，否则连接泄漏；但关了又失去“池”的意义
结论：用 sync.Pool 做 *rpc.Client 池容易误用，更适合管理轻量无资源的对象。
立即学习“go语言免费学习笔记（深入）”；
推荐方案：用第三方库 go-pool 或自建带健康检测的连接池
更稳妥的方式是维护一个固定大小的 *rpc.Client 列表，配合连接健康检查与懒重建逻辑。例如：
type RPCPool struct {
clients []*rpc.Client
mu sync.RWMutex
dialer func() (*rpc.Client, error)
size int
}
func (p *RPCPool) Get() (*rpc.Client, error) {
p.mu.RLock()
if len(p.clients) > 0 {
c := p.clients[0]
p.clients = p.clients[1:]
p.mu.RUnlock()
// 简单探测：发个 ping 或检查 Conn 是否活跃
if c == nil || c.Closed() {
c.Close()
return p.dialer()
}
return c, nil
}
p.mu.RUnlock()
return p.dialer()
}
func (p *RPCPool) Put(client *rpc.Client) {
p.mu.Lock()
if len(p.clients) < p.size {
p.clients = append(p.clients, client)
} else {
client.Close() // 池满，直接关掉
}
p.mu.Unlock()
}
关键点：
-
dialer应带超时，如rpc.Dial("tcp", addr, rpc.DefaultClientCodec(), &net.Dialer{Timeout: 3*time.Second}) - 避免在
Put前做复杂健康检查（如真实 ping），会拖慢归还路径；可改在Get时按需探测 - 服务端也需启用 keepalive，否则中间网络设备可能静默断连
比客户端池更有效的优化：换用 gRPC 或 HTTP/JSON-RPC
原生 net/rpc 协议简单但功能薄弱，不支持流控、超时传递、metadata、连接多路复用。实际项目中，与其花精力维护客户端池，不如迁移：
- 对内服务优先选
gRPC-Go：grpc.Dial返回的*grpc.ClientConn天然支持连接复用、重试、负载均衡，且默认开启 HTTP/2 多路复用 - 对外或跨语言场景用
net/http+ JSON-RPC 2.0：每个请求走标准 HTTP 连接池（http.Transport自带MaxIdleConns等配置），无需自己实现池逻辑
真正难处理的从来不是“怎么池化”，而是“连接什么时候算失效”“服务端是否配合 keepalive”“超时如何逐层透传”。这些在 gRPC 或标准 HTTP 栈里已有成熟解法。
