golang吞吐量低怎么办-Golang-PHP中文网

Go服务吞吐量低主因是HTTP超时与连接配置不当：ReadTimeout（建议5s）、WriteTimeout（建议10s）、IdleTimeout（必须设，如30s）和MaxHeaderBytes（建议64KB）四字段未显式配置，导致连接堆积、FD耗尽。

golang吞吐量低怎么办

Go 服务吞吐量低，八成不是代码写得慢，而是连接没复用、超时没控好、goroutine 没管住——先别改业务逻辑，盯紧 http.Server 和 http.Transport 的几个关键字段。

http.Server 启动时必须显式设这 4 个超时

默认不设超时，一个慢请求就能卡住整个连接池，QPS 断崖下跌。现象是 netstat -an | grep :8080 | wc -l 高但 CPU 很低，ss -s 显示大量 ESTABLISHED 连接堆积。

ReadTimeout：从 TCP 建连到读完请求头的上限，建议 5 * time.Second；大文件上传可单独用 ReadHeaderTimeout
WriteTimeout：从开始写响应到写完的上限，建议 10 * time.Second，防 handler 卡在 DB 或日志里
IdleTimeout：Keep-Alive 空闲连接存活时间，必须设（如 30 * time.Second），否则 fd 耗尽
MaxHeaderBytes：防攻击，设为 64 （64KB）较安全

别再用 `http.DefaultClient` 发下游请求

它的 MaxIdleConnsPerHost 默认是 2，多域名高频调用时，连接池秒空，后续请求排队等连接，延迟毛刺明显。

每个下游目标应配独立 *http.Client 实例，transport 中设 MaxIdleConns ≥ 200、MaxIdleConnsPerHost ≥ 100
IdleConnTimeout 设为 60 * time.Second 左右，太短失去复用价值，太长易积压失效连接
务必禁用 ExpectContinueTimeout（设为 0），小请求不会卡在 100-continue 等待上
全局复用 client 实例，禁止在 handler 里每次 new(http.Client)

goroutine 不是越多越好，得用池控住

每请求起一个 goroutine，在高并发下会迅速拉高 runtime.NumGoroutine()，调度器过载，P99 延迟飙升，pprof runtime.mallocgc 占比常超 40%。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

用 ants 或自建 worker pool，初始大小按 runtime.GOMAXPROCS(0) * 2 ~ 4 压测调整
任务 channel 必须带缓冲（如 make(chan Task, 1000)），否则生产者一卡，吞吐直接归零
每个 worker 内必须用 select { case 主动响应取消，不能只靠超时
DB 查询、HTTP 调用等 I/O 全部走 ctx，例如 db.QueryContext(ctx, sql)

别忽略系统级参数和连接队列

Go 层面调优再细，/proc/sys/net/core/somaxconn 还是 128，客户端照样收 Connection refused。

启动前执行 sysctl -w net.core.somaxconn=4096，并确认 cat /proc/sys/net/core/somaxconn 输出一致
用 ss -lnt 观察监听端口的 Recv-Q，若持续接近 somaxconn 值，说明连接队列已满
若用 net.Listen("tcp", ...)，拿到 *net.TCPListener 后无需手动 set backlog，系统参数生效即覆盖
容器环境注意 ulimit -n，避免 fd 不足导致 accept 失败

真正卡吞吐的地方，往往藏在 http.Transport.IdleConnTimeout 和 net.core.somaxconn 这种“不起眼”的配置里；改完记得用 ab 或 hey 对比压测，看 ss -s 和 runtime.NumGoroutine() 是否同步下降——数字不骗人。