本文详解为何使用 exec.Command.CombinedOutput() 会导致 Go 程序阻塞，以及如何通过 Start() + Wait() 组合实现非阻塞、可计时的 runc 容器启动。
本文详解为何使用 `exec.command.combinedoutput()` 会导致 go 程序阻塞，以及如何通过 `start()` + `wait()` 组合实现非阻塞、可计时的 runc 容器启动。
在使用 Go 脚本自动化测试 runc 容器启动性能时，一个常见误区是直接调用 CombinedOutput() 启动带 -d（detached）模式的容器，例如：
command := exec.Command("runc", "start", "-d", "redis")
command.Dir = "/containers/redis"
start := time.Now()
output, err := command.CombinedOutput() // ⚠️ 此处会无限期阻塞！
duration := time.Since(start) / time.Millisecond
这段代码看似合理——runc start -d redis 在 Shell 中立即返回，但 Go 中却卡住不退出。根本原因在于：CombinedOutput() 会等待子进程及其所有继承该标准流的后代进程完全关闭 stdout/stderr 后才返回。而 runc 在 detached 模式下启动的容器进程（如 Redis）会持续持有这些文件描述符（即使父 runc 进程已退出），导致 Go 主程序永远等待。
✅ 正确做法是分离「启动」与「等待」逻辑，仅监控 runc start 命令本身的执行完成（它负责创建并后台运行容器），而非整个容器生命周期：
command := exec.Command("runc", "start", "-d", "redis")
command.Dir = "/containers/redis"
start := time.Now()
if err := command.Start(); err != nil {
fmt.Printf("failed to start runc: %v\n", err)
return
}
// runc 进程已成功 fork 并返回 —— 启动阶段结束
duration := time.Since(start) / time.Millisecond
fmt.Printf("runc start latency: %d ms\n", duration)
// 可选：等待 runc 进程彻底退出（通常极快，毫秒级）
if err := command.Wait(); err != nil {
fmt.Printf("runc process error: %v\n", err)
}
? 关键要点：
- Start() 仅启动进程并立即返回，不读取输出也不等待退出；
- runc start -d 的职责是创建容器并让其在后台运行，它自身退出即代表启动成功；
- 若需验证容器是否真正就绪（如监听端口），应额外添加健康检查（如 net.DialTimeout 或 runc state redis 查询状态），而非依赖 CombinedOutput()；
- 避免在性能测试中混用 I/O 阻塞操作（如 Output()/CombinedOutput()），它们会引入不可控延迟。
总结：测量容器「启动命令执行耗时」，应使用 Start() + Wait()；若需捕获错误输出，可通过 StderrPipe() 单独处理，但切勿阻塞于容器进程的整个生命周期——那属于运维监控范畴，而非启动性能指标。
