17370845950

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 栈里已有成熟解法。