Golang http.Client引发goroutine与套接字文件描述符持续增长的排查与诊断求助

问题描述 #

我有一个持续运行的Go程序，最近发现goroutine数量和打开的文件描述符每天都在稳步增长，但活跃网络连接数并没有成比例上升。查看goroutine dump后，发现大多数长期存活的goroutine都是：
net/http.(*persistConn).writeLoop 和 net/http.(*persistConn).readLoop

同时用lsof -p [pid]查看文件描述符，发现大量类似这样的TCP套接字：

myprogram 8 root 26u sock 0,8 0t0 349484146 protocol: TCP
myprogram 8 root 27u sock 0,8 0t0 350094405 protocol: TCP
myprogram 8 root 29u sock 0,8 0t0 350354169 protocol: TCP

我怀疑是http.Client或http.Transport的连接/协程泄漏，可能是连接被无限保持了，但不确定怎么确认和调试，想请教大家：

• 如何确认是不是http.Client或http.Transport导致的连接/协程泄漏？
• 有哪些诊断工具或指标可以帮助追踪泄漏根源？

附相关goroutine栈信息：

goroutine 1030476 [select, 3878 minutes]:
net/http.(*persistConn).writeLoop(0xc02af42240)
	/usr/local/go/src/net/http/transport.go:2458 +0xf0
created by net/http.(*Transport).dialConn in goroutine 1030485
	/usr/local/go/src/net/http/transport.go:1800 +0x1585

goroutine 667283 [select, 5476 minutes]:
net/http.(*persistConn).readLoop(0xc029285440)
	/usr/local/go/src/net/http/transport.go:2261 +0xd3a
created by net/http.(*Transport).dialConn in goroutine 667247
	/usr/local/go/src/net/http/transport.go:1799 +0x152f

更新补充 #

关于响应体关闭的问题，我检查了自己的http客户端：我给http.Client加了一个用于日志的RoundTripper，代码如下：

func (l *RoundTripper) Log(r *http.Response) {
	if r == nil {
		return
	}
	respDump, err := httputil.DumpResponse(r, true)
	if err != nil {
		l.Logger.Error(fmt.Sprintf("DumpResponse error:%v", err))
	}
	l.Logger.Info(fmt.Sprintf("Response: %s\n", respDump))
}

我原本以为httputil.DumpResponse会自动读取并关闭响应体，但因为项目里调用http.Client的地方太多，实在找不到哪段代码导致了泄漏。有没有办法定位到具体的调用方？

排查建议 #

针对你的问题，我整理了几个关键的排查方向和实操方法，希望能帮到你：

1. 先修复响应体关闭的潜在问题

你当前的Log函数存在一个明显的隐患：如果httputil.DumpResponse执行出错，响应体r.Body会没有被关闭。未关闭的响应体直接会导致对应的persistConn协程无法退出，连接被永久占用，最终引发泄漏。

最简单的修正方法是在Log函数里添加defer r.Body.Close()，确保无论Dump是否成功，响应体都会被关闭：

func (l *RoundTripper) Log(r *http.Response) {
	if r == nil {
		return
	}
	defer r.Body.Close() // 强制关闭响应体，避免泄漏
	respDump, err := httputil.DumpResponse(r, true)
	if err != nil {
		l.Logger.Error(fmt.Sprintf("DumpResponse error:%v", err))
		return
	}
	l.Logger.Info(fmt.Sprintf("Response: %s\n", respDump))
}

如果你的业务代码还需要后续读取响应体，直接关闭会导致报错。这种情况下，建议先把响应体内容读出来，再重新包装成可读取的ReadCloser，同时关闭原响应体：

func (l *RoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
	resp, err := l.Next.RoundTrip(req)
	if resp != nil {
		// 先读取原响应体内容
		bodyBytes, readErr := io.ReadAll(resp.Body)
		resp.Body.Close() // 关闭原响应体
		if readErr != nil {
			l.Logger.Error(fmt.Sprintf("Read response body failed: %v", readErr))
		} else {
			// 用读取到的内容生成响应日志
			dumpResp := &http.Response{
				Status:        resp.Status,
				StatusCode:    resp.StatusCode,
				Header:        resp.Header,
				Body:          io.NopCloser(bytes.NewBuffer(bodyBytes)),
				ContentLength: int64(len(bodyBytes)),
			}
			if dump, dumpErr := httputil.DumpResponse(dumpResp, true); dumpErr != nil {
				l.Logger.Error(fmt.Sprintf("Dump response failed: %v", dumpErr))
			} else {
				l.Logger.Info(fmt.Sprintf("Response: %s\n", dump))
			}
		}
		// 重新设置响应体给业务代码使用
		resp.Body = io.NopCloser(bytes.NewBuffer(bodyBytes))
	}
	return resp, err
}

2. 用工具定位泄漏根源

（1）使用Go pprof分析协程和连接

• 开启程序的pprof端点：在代码中导入_ "net/http/pprof"，然后启动一个http服务暴露pprof接口（比如go func() { log.Fatal(http.ListenAndServe(":6060", nil)) }()）
• 采集goroutine的详细栈信息：执行go tool pprof http://localhost:6060/debug/pprof/goroutine?debug=2，可以看到所有存活goroutine的调用链，重点关注persistConn相关的协程，看它们是由哪些请求触发的。
• 采集trace数据分析生命周期：执行go tool trace http://localhost:6060/debug/pprof/trace?seconds=60，通过可视化界面查看协程的创建/销毁、网络连接的建立/关闭情况，找到未被释放的资源。

（2）开启Transport调试日志

给http.Transport开启DebugLog，直接观察连接的建立、复用、关闭过程，能快速定位异常连接：

client := &http.Client{
	Transport: &http.Transport{
		DebugLog: log.New(os.Stderr, "http-transport: ", log.LstdFlags),
		// 其他原有配置...
	},
}

日志里会输出类似http-transport: Transport acquired idle conn、http-transport: Transport closing idle conn的信息，通过对比可以看到哪些连接没有被正常关闭。

（3）查看TCP连接状态

用netstat -anp | grep [你的进程PID]查看这些泄漏的TCP连接处于什么状态：

• 如果是ESTABLISHED状态：说明连接被保持但未被复用/关闭，大概率是响应体未关闭导致。
• 如果是TIME_WAIT：一般是正常的，但数量过多可能是连接创建太频繁或超时设置不合理。

3. 定位具体的泄漏调用方

因为调用http.Client的地方太多，可以通过以下方式标记请求来源：

• 给请求加唯一标识：在RoundTripper里为每个请求生成一个UUID，放到请求的Header或Context中，同时在日志里记录这个UUID。
• 记录请求的调用栈：在RoundTripper的RoundTrip方法中，用runtime.Stack获取当前调用栈，和请求UUID关联起来存入日志或缓存。当发现泄漏的连接时，可以通过goroutine栈中的请求ID或者连接创建时间，匹配到对应的调用栈，从而定位到具体业务代码。

4. 检查Transport的配置

默认的http.Transport有空闲连接的限制，但如果配置不合理也可能导致积累：

• MaxIdleConns/MaxIdleConnsPerHost：如果设置得过大，空闲连接会占用资源；
• IdleConnTimeout：如果设置得太长，空闲连接会长期不被回收；
  建议根据业务情况调整这些参数，比如设置IdleConnTimeout: 30 * time.Second，让空闲连接及时被回收。

内容来源于stack exchange