Golang并发日志写入方法与技巧

本篇文章给大家分享《Golang并发日志写入技巧与实践》，覆盖了Golang的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

直接用 log.Printf 在多 goroutine 中写文件会出问题，因为 log.Logger 默认不并发安全，格式化与写入非原子操作，易致日志错乱、截断或 panic。

为什么直接用 log.Printf 在多 goroutine 中写文件会出问题

因为标准库的 log.Logger 默认不保证并发安全——多个 goroutine 同时调用 logger.Print() 可能导致日志行错乱、截断，甚至 panic（比如底层 os.File.Write 被并发调用时触发内部锁竞争或缓冲区越界）。这不是“偶尔出错”，而是在高并发写入场景下几乎必然发生。

• 典型现象：2024-05-12T10:23:41Z INFO user login 和 2024-05-12T10:23:41Z ERROR db timeout 混合成一行，如 2024-05-12T10:23:41Z INFO user login2024-05-12T10:23:41Z ERROR db timeout
• 根本原因：日志格式化 + 写入不是原子操作；log.Logger 的 Output 方法内部未对写入目标加锁
• 误区：以为给 log.New 传一个带互斥锁的 io.Writer 就够了——其实还不够，因为格式化字符串（含时间、调用栈）本身也需同步，否则不同 goroutine 的 runtime.Caller 信息可能交叉

用 sync.Mutex 包裹 log.Logger 是最简方案但有性能瓶颈

适用于 QPS

var (
    mu     sync.Mutex
    logger = log.New(os.Stdout, "", log.LstdFlags)
)
<p>func SafeLog(msg string) {
mu.Lock()
defer mu.Unlock()
logger.Println(msg)
}</p>

• 不要在 log.New 里直接传 &muWriter{mu: &mu, w: file} 这类包装 writer——log.Logger 会在每次调用时重置缓冲区并多次调用 Write，仅锁 Write 无法防止格式化内容被其他 goroutine 插入
• 如果必须用标准库，务必把整个 logger.Println 或 logger.Printf 调用包在 Lock/Unlock 内
• 注意：log.SetOutput 不是并发安全的，不能在运行时动态切换输出目标

推荐用 zap.Logger 配合 zapcore.Lock 实现无锁高性能写入

zap 是 Uber 开源的结构化日志库，其 zapcore.Core 层原生支持并发写入。关键不是“加锁”，而是使用 zapcore.Lock 对底层 io.Writer 做最小粒度保护，同时保持格式化与写入分离的高效路径。

file, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)
lockedWriter := zapcore.Lock(file)
core := zapcore.NewCore(
    zapcore.JSONEncoder{TimeKey: "ts", EncodeTime: zapcore.ISO8601TimeEncoder},
    lockedWriter,
    zapcore.InfoLevel,
)
logger := zap.New(core)
<p>// 多个 goroutine 可安全调用
go func() { logger.Info("request started", zap.String("path", "/api/v1")) }()
go func() { logger.Error("db failed", zap.Error(err)) }()</p>

• zapcore.Lock 只锁 Write 系统调用，不锁格式化过程，因此比全函数加锁快 3–5 倍（实测 10k 日志/秒场景）
• 避免用 zap.NewDevelopment 或 zap.NewProduction 直接初始化——它们内部已封装了锁，但你无法控制 writer 生命周期；建议手动构造 Core 以明确管理文件句柄
• 注意关闭：程序退出前需调用 logger.Sync()，否则最后几条日志可能滞留在缓冲区未刷盘

自研环形缓冲 + 单独写入 goroutine 更适合极端吞吐场景

当单机日志量 > 50MB/s 或要求毫秒级延迟可控时，zap 的锁仍可能成为瓶颈。此时应将日志事件投递到 channel，由专用 goroutine 顺序写入，并配合内存缓冲和批量刷盘。

• 核心结构：chan *LogEntry（固定长度，如 1024），LogEntry 包含预格式化字符串、时间戳、level 字段
• 投递端不阻塞：用 select { case ch 防止日志堆积拖慢主逻辑
• 写入端做合并：每 10ms 或积满 64 条后统一 Write，减少系统调用次数
• 别忘了信号处理：收到 SIGTERM 时先 close channel，再等待写入 goroutine 完成剩余日志，最后 file.Close()

真正难的不是“怎么让多 goroutine 不写乱”，而是“怎么在不拖慢业务的前提下，把日志可靠落盘”。锁只是起点，缓冲策略、刷盘时机、错误降级（比如磁盘满时切到 syslog）、以及是否接受少量丢失——这些权衡点，往往比选哪个库更影响线上稳定性。

本篇关于《Golang并发日志写入方法与技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！