日志的重要性与性能挑战
很多人觉得日志就是print大法，出了问题再打开看看。但真正经历过线上事故的人都知道——日志是系统的黑匣子。没有它，你连故障根因都找不到。
我入行第三年接了一个支付核心系统。每天凌晨三点总有几笔交易对不上账，查了三天数据库，最后发现是日志里记录了异常堆栈但没人看。嗯，从那以后我再也不敢轻视日志了。
但日志这把双刃剑，用好是宝，用不好就是灾难。高并发下，日志写入速度跟不上业务请求速度，就会引发连锁反应：线程阻塞、吞吐量暴跌、甚至雪崩。今天我们就来掰扯清楚，日志到底重要在哪？性能瓶颈出在哪？
1.1 日志的核心价值
你可能觉得日志记录几个字符串有什么价值。我举几个真实场景：
- 问题定位：线上异常找不到堆栈？查日志。
- 链路追踪：分布式系统里一个请求经过五个服务，靠 traceId 把日志串起来。
- 监控告警：业务指标（比如下单失败率）通过日志结构化上报。
- 审计合规：金融系统必须记录操作日志，没有就是重大事故。
- 性能分析：慢查询、耗时分布，都能从日志里挖出来。
1.2 高并发场景下的性能挑战
日志性能问题说白了就一句话：写入速度跟不上业务请求速率。为什么跟不上？我们来解构一下日志写入的完整链路：
- 日志内容构建：字符串拼接、参数序列化（比如 Jackson 转 JSON）
- IO 系统调用：写入文件/管道/网络，涉及内核态切换
- 磁盘写入：机械硬盘随机写 ≈ 10ms/次，SSD 也有写入寿命限制
- 锁竞争：多线程同时写同一个文件，必然加锁排队
- 格式化和缓冲：日志框架内部缓冲区满了才刷盘，但刷盘时机不好又导致延迟波动
我当年调优过一个日交易量千万级的系统，线上压力测试时发现日志写入占了 35% 的 CPU 时间片。你想想看，业务逻辑没跑多少，全在拼字符串和等 IO，这谁受得了？
下面这张图帮你理清挑战的层次：
1.3 同步 vs 异步：一个绕不开的选择
很多新人上来就给日志配成同步刷盘，觉得这样最安全。但高并发下同步写入的代价你扛得住吗？
| 对比维度 | 同步日志 | 异步日志 |
|---|---|---|
| 写入延迟 | 业务线程直接等待IO完成，高并发下延迟可达几百毫秒 | 业务线程只做入队操作（微秒级），IO由后台线程处理 |
| 吞吐量 | 受限于磁盘随机写性能，通常 < 5万行/秒 | 可轻松达到百万行/秒（如 Log4j2 异步） |
| 丢日志风险 | 保证写入完成后才返回，几乎不丢 | 缓冲区满或进程异常退出时可能丢日志 |
| 适用场景 | 审计、金融等不能丢日志的场景 | 大部分业务系统（日志丢失可接受） |
1.4 日志框架选型常识
现在主流框架就这几个：Log4j2、Logback、SLF4J 门面、java.util.logging。性能最推荐的是 Log4j2 的异步模式，它使用了无锁队列（Disruptor）来避免锁竞争。我习惯直接上 Log4j2 + AsyncAppender，配合 Jackson 按需序列化。
对了，有个细节很多人忽略 —— 参数化日志 vs 字符串拼接。比如：
// 不好的写法：即使日志级别不输出，也会拼接字符串
log.debug("用户ID：" + userId + " 消费金额：" + amount);
// 好的写法：使用参数化，日志框架会自动延迟求值（如果级别不输出，不拼接）
log.debug("用户ID：{} 消费金额：{}", userId, amount);
别小看这一行。在高并发下，info 级别的日志每秒百万次调用，字符串拼接的 CPU 开销可以吃掉一个核。
1.5 小结：你需要在开课前搞清楚的三个问题
- 你的业务对日志丢失容忍度是多少？——决定了你用同步还是异步，以及异步队列的丢弃策略（丢弃老日志还是新日志）。
- 你的系统峰值 QPS 下产生了多少日志数据？——先估一下单行日志平均长度（比如 500 字节），再乘 QPS，带宽和磁盘够不够一目了然。
- 你有没有在测试环境压过日志性能？——我见过很多团队只测试功能，从不压日志，上线后才发现日志是瓶颈。至少做一次日志写入速率压测（比如用 jmeter 模拟并发请求，同时打日志）。
我们后面几节会逐一破解这些挑战：从异步缓冲、批量写入、日志采样、结构化压缩，到分布式日志链路收集。但第一步，就是先承认 日志不是免费的，它的代价必须被量化和管理。