高并发RPC服务核心是控流、复用与快路径：用信号量或协程池限并发，复用gRPC ClientConn/HTTP Client/缓存rpc.Client，sync.Pool复用缓冲区，协议层优选protobuf或jsoniter，服务端异步化IO并用pprof定位瓶颈。
用 Go 实现高并发 RPC 服务，核心不是堆 Goroutine，而是控制并发规模、复用连接、减少阻塞。Goroutine 本身轻量，但无节制启动仍会耗尽内存或触发调度开销；连接池则解决频繁建连的延迟和资源浪费问题。
用 Goroutine 控制并发节奏，而非盲目并发
RPC 客户端每请求起一个 Goroutine 看似简单，但面对突发流量易导致 Goroutine 数量失控（如 10 万并发请求 → 10 万个 Goroutine），反而拖慢整体响应。更稳妥的做法是结合 限流 + 工作协程池：
- 用
semaphore（如golang.org/x/sync/semaphore）限制同时发起的请求数，例如最多 200 个并发调用 - 或使用固定数量的工作 Goroutine（如 50 个）从任务队列中取 RPC 请求执行，避免瞬时爆炸
- 对每个 RPC 调用设置明确超时（
context.WithTimeout），防止个别慢请求拖垮整个池
用连接池复用底层 TCP 连接
标准 net/rpc 或 gRPC-Go 默认不带连接池，每次 rpc.Dial 或新建 gRPC client 都可能新建 TCP 连接。高频短请求下，三次握手+TLS 握手开销显著。实际应：
- gRPC 场景：复用同一个
*grpc.ClientConn实例（它是线程安全、自带连接池的），不要为每个请求 new client - 自定义 TCP RPC（如 JSON-RPC over raw TCP）：用
sync.Pool缓存*rpc.Client，或封装带连接复用的 Client 结构体，内部维护空闲连接队列 - HTTP-based RPC（如 REST over HTTP）：用全局复用的
*http.Client，其Transport默认启用连接池（MaxIdleConns等参数可调）
序列化与编解码尽量零拷贝或复用缓冲区
高并发下，反复 json.Marshal/Unmarshal 或 proto.Marshal 会触发大量内存分配，加剧 GC 压力。优化方向：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.Pool缓存常用结构体或字节切片（如*bytes.Buffer、[]byte），避免每次请求都 new - gRPC 推荐用 Protocol Buffers，默认已较高效；若用 JSON，考虑
easyjson或jsoniter替代标准库，支持预生成代码和缓冲复用 - 服务端接收请求后，尽早做协议解析，失败快速返回，避免在业务逻辑里才校验格式
服务端也要适配：别让 handler 成瓶颈
客户端优化再好，服务端若用同步阻塞写法（如每个请求独占一个 goroutine 但内部串行处理 DB 查询），吞吐仍上不去。需配合：
- RPC 服务端 handler 内部避免长阻塞操作；DB 查询、HTTP 调用等异步化或加超时
- 必要时对后端依赖做客户端连接池（如
sql.DB本身是连接池，redis.Client也内置池） - 用 pprof 和 trace 分析真实瓶颈——常发现卡在锁竞争、日志打印、或未关闭的 response body 上
基本上就这些。高并发不是靠“多开协程”，而是靠“控流 + 复用 + 快路径”。Goroutine 是工具，连接池是基础，真正提升吞吐的是减少等待、复用资源、缩短关键路径。
