在一个典型的HTTP服务中，几十个甚至上百个goroutine会同时处理请求。如果它们都直接调用fmt.Println或log.Println，写入底层文件时会出现什么现象？Go标准库log包虽然本身带锁，但每次调用都会完整地执行格式化、获取锁、写入文件、释放锁，高并发下锁竞争会拖慢业务协程。更隐蔽的问题是，如果多个goroutine没有经过任何同步就操作同一个os.File，写入位置和缓冲区状态可能交错，最终日志文件里出现半行数据或者顺序完全混乱。因此并发日志的核心目标是：共享一个写入入口，保证单条日志原子性，并尽可能减少对业务协程的阻塞。
一、评估并发日志方案的三个核心指标
设计并发日志写入器之前，需要先想清楚要在哪些维度上做取舍。第一是吞吐量，也就是单位时间内能够写入多少条日志，它直接决定了日志系统会不会拖慢核心业务的QPS。第二是写入延迟，一条日志从业务协程发起写入到真正落盘需要多长时间，延迟高意味着业务协程会在日志调用上等待。第三是日志可靠性，进程崩溃或者主动退出时，缓冲区中尚未写入文件的数据是否会丢失，这对于排查线上问题至关重要。
这三个指标之间常常互相制约。例如互斥锁同步写入虽然能保证日志不丢失，但锁竞争会降低吞吐量；异步通道方案虽然能减少业务协程等待，但如果缓存区设计不当，进程退出时可能丢掉最后一批日志。批量刷盘方案能大幅提升吞吐量，却会增加单条日志的感知延迟。因此没有绝对最优的方案，只有根据业务场景选择最合适的实现。
二、方案一：用sync.Mutex保护同步写入
最直观的方式是在写入方法外面加一把互斥锁。每次goroutine要写日志时，先获取锁，再调用log包输出，最后释放锁。这样做的好处是单条日志的写入过程是原子的，不会出现两个goroutine的日志内容交替插入到文件中的情况。对于低频日志系统，比如每秒只有几十条日志，这种方案的实现成本最低，也最容易维护。
下面的代码实现了带互斥锁的日志写入器。构造函数打开文件并创建log.Logger实例，Write方法通过sync.Mutex保证同一时刻只有一个goroutine执行写入操作。这里需要特别留意，defer w.mu.Unlock()会让锁延迟到函数返回才释放，如果写入过程中发生panic，锁仍然会被正确释放，避免死锁。
package main
import (
"fmt"
"log"
"os"
"sync"
)
type MutexLogWriter struct {
mu sync.Mutex
file *os.File
logger *log.Logger
}
func NewMutexLogWriter(path string) (*MutexLogWriter, error) {
f, err := os.OpenFile(path, os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
if err != nil {
return nil, err
}
return &MutexLogWriter{
file: f,
logger: log.New(f, "", log.LstdFlags),
}, nil
}
func (w *MutexLogWriter) Write(msg string) {
w.mu.Lock()
defer w.mu.Unlock()
w.logger.Print(msg)
}
func main() {
writer, _ := NewMutexLogWriter("app.log")
defer writer.file.Close()
var wg sync.WaitGroup
for i := 0; i < 100; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
writer.Write(fmt.Sprintf("goroutine %d finished", id))
}(i)
}
wg.Wait()
}
这个方案最明显的缺点就是锁竞争。一旦某个goroutine拿到锁执行文件写入，其他所有goroutine只能排队等待。文件写入涉及系统调用，速度通常比内存操作慢几个数量级，因此当并发量增加时，日志写入很容易成为整个服务的性能瓶颈。不过对于写日志频率不高、或者对实现简单性要求很高的工具，sync.Mutex方案依然是一个可靠的选择。
三、方案二：用channel实现异步日志队列
如果想要降低业务协程的等待时间，可以把日志写入动作从业务协程中剥离出来。核心思路是创建一个带缓冲的channel，业务协程只负责把日志字符串投递到channel里，后台有一个专门的消费者goroutine不断从channel中读取消息并写入文件。这样一来，业务协程的写入延迟就只取决于channel是否已满，正常情况下比直接写文件快得多。
下面代码展示了一个异步日志器的实现。Write方法使用select语句配合default分支，当channel已满时直接返回false，避免阻塞业务协程。消费者goroutine通过range读取channel直到channel被关闭。Close方法先关闭channel，再等待消费者处理完所有剩余消息，最后关闭文件句柄。
package main
import (
"fmt"
"log"
"os"
"sync"
"time"
)
type AsyncLogger struct {
ch chan string
done chan struct{}
file *os.File
logger *log.Logger
wg sync.WaitGroup
}
func NewAsyncLogger(path string, queueSize int) (*AsyncLogger, error) {
f, err := os.OpenFile(path, os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
if err != nil {
return nil, err
}
l := &AsyncLogger{
ch: make(chan string, queueSize),
done: make(chan struct{}),
file: f,
logger: log.New(f, "", log.LstdFlags),
}
l.wg.Add(1)
go l.consume()
return l, nil
}
func (l *AsyncLogger) consume() {
defer l.wg.Done()
for msg := range l.ch {
l.logger.Print(msg)
}
}
func (l *AsyncLogger) Write(msg string) bool {
select {
case l.ch <- msg:
return true
default:
return false
}
}
func (l *AsyncLogger) Close() {
close(l.ch)
l.wg.Wait()
close(l.done)
l.file.Close()
}
func main() {
logger, _ := NewAsyncLogger("async.log", 1024)
defer logger.Close()
ok := logger.Write("hello from goroutine")
fmt.Println("accepted:", ok)
time.Sleep(100 * time.Millisecond)
}
异步模型的短板是日志丢失风险。如果channel缓冲区被写满，Write方法会直接返回false，业务协程需要自己决定是丢弃日志还是重试。此外，进程如果被强制终止，消费者goroutine可能来不及处理channel中的剩余消息。所以这种方案更适合日志量较大但可以容忍少量丢失的在线服务场景，例如访问日志或中间件调试日志。
四、方案三：批量缓冲与定时刷盘
进一步的优化方向是减少文件写入次数。操作系统提供的write调用本身有固定开销，如果每来一条日志就调用一次write，系统调用的成本会非常高。批量写入的思路是先在内存中维护一个字节缓冲区，业务协程把日志内容追加到缓冲区里，当缓冲区大小达到阈值，或者到达定时时间，再一次性写入文件。这样可以成倍减少系统调用次数，显著提升吞吐量。
下面的代码实现了批量日志写入器。Write方法只需要把日志内容追加到内存buf中，临界区非常短，锁竞争也相对较小。flush方法负责把缓冲区内容写入文件并清空缓冲区。后台的flushLoop协程每隔固定时间触发一次flush，同时监听done通道以便在关闭时执行最终刷盘。
package main
import (
"log"
"os"
"sync"
"time"
)
type BatchLogger struct {
mu sync.Mutex
buf []byte
maxSize int
file *os.File
ticker *time.Ticker
done chan struct{}
logger *log.Logger
}
func NewBatchLogger(path string, maxSize int, interval time.Duration) (*BatchLogger, error) {
f, err := os.OpenFile(path, os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0644)
if err != nil {
return nil, err
}
l := &BatchLogger{
buf: make([]byte, 0, maxSize),
maxSize: maxSize,
file: f,
ticker: time.NewTicker(interval),
done: make(chan struct{}),
logger: log.New(f, "", log.LstdFlags),
}
go l.flushLoop()
return l, nil
}
func (l *BatchLogger) Write(msg string) {
l.mu.Lock()
defer l.mu.Unlock()
l.buf = append(l.buf, []byte(l.logger.Prefix()+msg+"\n")...)
if len(l.buf) >= l.maxSize {
l.flush()
}
}
func (l *BatchLogger) flush() {
if len(l.buf) == 0 {
return
}
_, _ = l.file.Write(l.buf)
l.buf = l.buf[:0]
}
func (l *BatchLogger) flushLoop() {
for {
select {
case <-l.ticker.C:
l.mu.Lock()
l.flush()
l.mu.Unlock()
case <-l.done:
l.flush()
return
}
}
}
func (l *BatchLogger) Close() {
close(l.done)
l.mu.Lock()
l.flush()
l.mu.Unlock()
l.file.Close()
}
批量缓冲的缺点在于复杂度上升，同时单条日志从调用Write到最终落盘可能会存在一小段延迟。如果进程突然崩溃，缓冲区中尚未刷入文件的数据也会丢失。不过在多goroutine高并发、日志吞吐量极大的场景下，这个方案往往能带来数量级的性能提升，因此很多高性能服务都会选择类似的设计。
五、方案对比与选型建议
选型时可以先看业务对日志丢失的容忍程度。如果日志用于审计或资金流水，任何丢失都不可接受，那么sync.Mutex同步写入方案最合适，虽然吞吐量低，但每条日志都会立即刷盘。如果日志只是用来做运行监控和调试，偶尔丢几条不会影响核心业务，异步channel方案可以在吞吐和实现成本之间取得不错的平衡。
对于日志写入压力特别大的场景，例如网关、消息中间件或大型Web服务，批量缓冲加定时刷盘是更优的选择。它能显著减少write系统调用次数，并且通过调整maxSize和定时间隔可以在吞吐量与延迟之间灵活配置。需要特别注意的是，无论选择哪种方案，都要在程序退出时主动关闭日志器并执行最终刷盘，避免缓冲区内的最后一批数据没有被写入文件。
三种方案并不是互斥的，实际项目中也可以组合使用。比如业务协程先将日志投递到channel，消费者再把channel中的日志合并成批量写入，这样既降低了业务协程的阻塞，又减少了文件系统调用。理解了锁、channel和缓冲三种基础机制之后，就可以根据日志量、可靠性要求以及运维复杂度，设计出适合自己系统的并发日志写入器。
Golang并发日志goroutine日志写入日志记录修改时间：2026-09-05 17:04:01