go 程序读取命名管道时若未正确处理 eof 或退出信号，会导致空转循环持续调用 `readline()`，引发单核 100% 占用；根本原因是缺少阻塞等待机制和循环退出条件。
命名管道（FIFO）在无数据可读时，默认行为是阻塞——但这一特性仅在管道被至少一个写端打开时才生效。一旦所有写端关闭（例如外部进程退出），os.OpenFile 打开的读端会立即进入 EOF 状态，后续 reader.ReadLine() 将快速返回 (nil, io.EOF)，而你的原始代码未检查该错误，导致 for {} 循环陷入“读 → 判空 → 继续读”的高频自旋，CPU 使用率飙升。
更关键的是，原逻辑中 awaitingExit 仅用于跳过业务处理，却未终止循环本身。即使收到 SIGTERM，主 goroutine 仍无限轮询 ReadLine()，无法响应退出。
✅ 正确做法需同时满足三点：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
- 显式检查 io.EOF 并退出读取循环；
- 使用同步机制（如 sync.Once 或 channel）安全响应信号；
- 确保 bufio.Reader 在阻塞读期间真正挂起，而非忙等。
以下是优化后的完整示例：
package main
import (
"bufio"
"log"
"os"
"os/signal"
"sync"
"syscall"
)
func handleNewLine(line string) {
// 实际业务逻辑，例如日志上传、解析等
log.Printf("Processing: %s", line)
}
func main() {
// 设置优雅退出信号监听
sigChan := make(chan os.Signal, 1)
signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM)
var exitOnce sync.Once
var wg sync.WaitGroup
// 启动信号处理 goroutine
go func() {
<-sigChan
log.Println("Received shutdown signal, waiting for pending tasks...")
exitOnce.Do(func() {
wg.Wait()
os.Exit(0)
})
}()
// 打开命名管道（注意：若写端未启动，此调用会阻塞，符合预期）
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)
// 主读取循环：显式处理 EOF 和错误
for {
line, isPrefix, err := reader.ReadLine()
if err != nil {
if err == syscall.EINTR {
continue // 被信号中断，重试
}
if err == os.ErrClosed || err == syscall.EBADF {
log.Println("FIFO closed, exiting read loop")
break
}
log.Printf("Read error (will exit): %v", err)
break
}
// 处理不完整行（行太长被截断）
if isPrefix {
log.Println("Warning: line too long, skipping")
continue
}
// 仅当未进入退出流程时才启动新 goroutine
select {
case <-sigChan:
log.Println("Shutdown in progress, skipping new line")
continue
default:
wg.Add(1)
go func(uploadLog string) {
defer wg.Done()
handleNewLine(uploadLog)
}(string(line))
}
}
log.Println("Reader loop exited, waiting for final cleanup...")
}⚠️ 注意事项：
- 不要依赖 len(line) > 0 判断有效性：空行（\n）是合法输入，应由业务逻辑决定是否忽略；ReadLine() 返回空切片 []byte{} 表示空行，而非 EOF。
- 避免竞态访问 awaitingExit：原代码中 awaitingExit 被多 goroutine 读写却无锁/原子操作，易导致未定义行为；改用 sync.Once + channel 是更 Go 风格的方案。
- defer file.Close() 在循环外执行是安全的：因为 os.OpenFile 返回的是文件描述符，Close() 仅释放资源，不影响已启动的 goroutine（只要它们不继续读写该文件）。
总结：解决 FIFO 读取高 CPU 的核心在于——让循环在无数据时真正阻塞，在异常或退出时明确终止，且所有共享状态变更线程安全。遵循上述模式，即可实现低开销、可响应、生产就绪的管道监听服务。
