17370845950

go 程序内存持续上涨且线程数达上百，通常并非因 goroutine 泛滥，而是底层阻塞系统调用（如日志写入、文件 i/o、cgo 调用等）触发 go 运行时创建新 os 线程，导致线程泄漏和内存累积。

在 Go 中，“大量 goroutine” ≠ “大量 OS 线程”。Go 运行时通过 M:N 调度模型（M 个 OS 线程调度 N 个 goroutine）实现高并发，正常情况下活跃线程数由 GOMAXPROCS 控制（默认为 CPU 核心数），远低于 goroutine 数量。你观察到 Threads: 177 且内存长期不释放，说明存在 非预期的 OS 线程驻留，根源在于阻塞式系统调用未及时返回，导致运行时无法复用线程。

? 关键机制：什么情况下 Go 会创建新线程？

当一个 goroutine 执行以下操作时，运行时会将其从当前 M（OS 线程）上解绑，并可能新建线程：

• 阻塞型系统调用（如 read()/write() 到慢速设备、open()、stat() 等）；
• 使用 cgo 调用 C 函数（尤其含阻塞逻辑）；
• 调用 runtime.LockOSThread() 显式绑定线程（你的代码未使用，可排除）；
• 某些第三方库内部封装的阻塞 I/O（如日志库、数据库驱动、加密库等）。

⚠️ 注意：标准库的 net.Conn 操作（如 conn.Read()/Write()）是非阻塞的——它们基于 epoll/kqueue/io_uring 实现异步 I/O，不会导致线程增长。因此 handleClient 及 Session.handleRecv 中的网络读写本身不是元凶。

? 你的代码中最可疑的线程来源：日志写入

你使用了自定义日志模块 sanguo/base/log，并启用了文件写入：

filew := log.NewFileWriter("log", true)
err := filew.StartLogger() // 启动日志协程（极可能含阻塞 I/O）

若该日志器采用同步写文件（如直接 os.File.Write() + fsync()），尤其在磁盘负载高或 NFS 挂载时，每次写入都可能触发阻塞系统调用。Go 运行时为保障其他 goroutine 不被卡住，会分配新线程执行该阻塞调用。若日志高频且写入缓慢，线程将持续累积，且因未显式关闭，这些线程不会自动回收。

其他潜在风险点：

• tcpkeepalive.EnableKeepAlive() 底层调用 setsockopt()，虽为轻量系统调用，但若其内部有锁竞争或错误路径，也可能间接引发线程行为；
• json.Marshal() 本身无阻塞，但若 SendDirectly 中 sess.conn.Write() 因 TCP 窗口满而阻塞（罕见），理论上也可能触发线程切换（不过 net.Conn 默认非阻塞，实际概率极低）。

✅ 排查与修复方案

1. 验证线程归属

运行时检查线程状态：

# 查看进程所有线程的栈信息（需安装 delve 或使用 go tool pprof）
go tool pprof -threads http://localhost:6060/debug/pprof/threadcreate
# 或直接查看线程堆栈（Linux）
sudo cat /proc/$(pidof your_program)/stack | grep -A 5 -B 5 "sys"

重点关注栈中是否频繁出现 write, fsync, openat, epoll_wait（正常）或 futex, nanosleep（可疑阻塞）。

2. 替换/优化日志组件

• ✅ 首选：改用异步日志库
  如 zap（带缓冲队列）或 logrus + hook 异步写入。
• ✅ 次选：强制日志异步化
  将 filew.StartLogger() 改为启动 goroutine + channel 缓冲：

  logChan := make(chan string, 1000)
  go func() {
      for msg := range logChan {
          // 同步写文件，但由单一线程承担
          os.WriteFile("log.txt", []byte(msg+"\n"), 0644)
      }
  }()
  // 日志调用改为：logChan <- fmt.Sprintf("[DEBUG] %s", msg)

3. 设置线程上限（临时缓解）

通过环境变量限制最大 OS 线程数（防失控）：

export GODEBUG="schedtrace=1000"  # 每秒打印调度器状态（调试用）
export GOMAXPROCS=4               # 严格限制 P 数（影响并发吞吐，慎用）
# 注：Go 无直接 GOMAXTHREADS，但可通过 runtime.LockOSThread() + 池管理模拟

4. 补充资源清理

确保连接关闭时释放所有资源：

func (sess *Session) Close() {
    sess.lock.Lock()
    if sess.ok {
        sess.ok = false
        close(sess.closeNotiChan)
        // ⚠️ 补充：关闭 recvChan 避免 goroutine 泄漏
        close(sess.recvChan)
        sess.conn.Close()
    }
    sess.lock.Unlock()
}

并在 handleDispatch 的 for 循环中处理 recvChan 关闭：

case msg, ok := <-sess.recvChan:
    if !ok { return } // chan closed
    log.Debug("msg", msg)
    sess.SendDirectly("helloworld", 1)

? 总结

• Go 线程暴涨 ≠ goroutine 写错，而是阻塞系统调用未收敛所致；
• 你的案例中，同步文件日志是最可能的罪魁祸首；
• 修复核心：将阻塞 I/O 移至专用 goroutine + 缓冲队列，或切换成熟异步日志库；
• 始终通过 pprof 和 /proc/PID/stack 验证线程行为，而非仅依赖猜测。

遵循以上方案，线程数将稳定在 GOMAXPROCS 附近，内存占用回归合理水平。