go 程序在阻塞读取命名管道时出现 100% cpu 占用，根本原因是未正确处理 eof 或退出信号导致空转循环；需通过条件控制循环、同步退出信号或使用带超时/阻塞语义的 i/o 方式解决。
命名管道（FIFO）在 Linux 中表现为一种特殊文件，其读写行为具有阻塞特性：当无数据可读且管道未关闭时，os.Read 或 bufio.Reader.ReadLine() 会阻塞；但一旦写端关闭（或进程终止），读端将立即返回 io.EOF —— 此时若程序未做相应判断，就会陷入「检查 EOF → 发现无数据 → 继续尝试读 → 立即返回 EOF」的高速空转，从而耗尽单核 CPU。
原代码中的核心问题在于：
for {
line, _, _ := reader.ReadLine() // ⚠️ 未检查 err！EOF 时 line 为空，err == io.EOF
if !awaitingExit && len(line) > 0 {
wg.Add(1)
go func(uploadLog string) {
defer wg.Done()
handleNewLine(uploadLog)
}(string(line))
}
// ❌ 缺少对 err 的处理，也未跳出循环；awaitingExit 为 true 后仍持续调用 ReadLine()
}reader.ReadLine() 在遇到 EOF 时返回空切片和 io.EOF 错误，但代码忽略错误并继续下一轮循环，造成无限轮询。
✅ 正确做法：显式处理 EOF 并优雅退出
推荐使用带错误检查的循环，并结合通道信号实现安全退出：
// 使用 context 控制生命周期（更现代、推荐）
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
// 信号监听 goroutine
go func() {
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
<-sigChan
log.Println("Received shutdown signal")
cancel() // 触发 ctx.Done()
}()
// 打开 FIFO（注意：O_RDONLY 对空 FIFO 是阻塞的，符合预期）
file, err := os.OpenFile("file.fifo", os.O_RDONLY, 0)
if err != nil {
log.Fatal("Failed to open FIFO:", err)
}
defer file.Close()
reader := bufio.NewReader(file)
wg := &sync.WaitGroup{}
// 主读取循环
for {
select {
case <-ctx.Done():
log.Println("Shutting down reader...")
return // 退出整个函数
default:
// 尝试读一行（阻塞直到有数据或写端关闭）
line, isPrefix, err := reader.ReadLine()
if err != nil {
if errors.Is(err, io.EOF) {
log.Println("FIFO write end closed; exiting.")
return
}
log.Printf("Read error: %v", err)
continue // 其他临时错误可重试
}
if isPrefix {
log.Warn("Line too long, skipped")
continue
}
if len(line) > 0 {
wg.Add(1)
go func(data string) {
defer wg.Done()
handleNewLine(data)
}(string(line))
}
}
}⚠️ 关键注意事项
- 永远不要忽略 ReadLine() 的 error 返回值：io.EOF 是合法终止信号，必须显式处理；
- 避免裸 for {} 循环：应配合 select + context 或 break + 条件判断，防止失控；
- awaitingExit 需同步访问：若多 goroutine 修改该变量，必须用 sync.Mutex 或 atomic.Bool，但更推荐用 context 或 channel 通信替代共享变量；
- os.OpenFile 模式要准确：打开 FIFO 读端应使用 os.O_RDONLY，权限位（第三个参数）对 FIFO 无效，可设为 0；
- 写端关闭后，读端会收到 EOF：这是正常流程，不是异常，应作为优雅退出依据。
✅ 总结
100% CPU 根源是「无阻塞、无等待、无退出」的死循环。修复本质是：让循环在无数据可读时真正等待，而非忙等；并在收到终止信号或 EOF 时及时退出。使用 context.Context 配合 select 是 Go 生态中最惯用、最健壮的解决方案，兼顾可测试性、可取消性和并发安全性。
