同步日志显著拖累cpu，因主线程参与i/o等待、字符串拼接、锁竞争和内存分配；logback/log4j1.x默认同步appender致线程卡顿；未用isdebugenabled()导致无效拼接与序列化；consoleappender因system.out锁性能极低；asyncappender存在队列满阻塞、丢日志及崩溃丢失风险。
高并发下同步日志记录会显著拖累 CPU，核心原因不是日志内容本身，而是主线程被迫参与 I/O 等待、字符串提前拼接、锁竞争和频繁内存分配。这些操作把本该轻量的日志调用，变成了 CPU 密集型负担。
同步写入让业务线程原地卡住
Logback、Log4j 1.x 等默认使用同步 Appender，每次 logger.info(...) 调用，业务线程必须等日志真正落盘才返回。在每秒数千条日志的场景下：
- 线程反复陷入 WAITING 状态（常见于
ArrayBlockingQueue.put()或文件 write+fsync） - CPU 时间片被大量消耗在等待磁盘响应上，
%user可能不高，但%wait或iowait显著上升 - 线程池积压、HTTP 请求超时、TPS 断崖下跌往往由此触发
日志级别没关紧，CPU 白干一场
即使配置了 root level="INFO"，DEBUG 日志不输出，以下写法仍会执行字符串拼接和对象序列化：
-
log.debug("User " + user.getId() + ", name=" + user.getName());→ 拼接必发生 -
log.debug("Request: {}", JSON.toJSONString(request));→ 序列化必发生 - 正确做法是加开关判断：
if (log.isDebugEnabled()) { log.debug("..."); }
控制台输出是隐藏的性能杀手
别小看 ConsoleAppender，它底层依赖 System.out，而这个流是全局 synchronized 的：
- 多线程并发调用
println会排队争抢同一把锁 - 实测性能比
FileAppender低 20 倍，即使重定向到/dev/null也慢 - Log4j2 推荐开启
direct="true"绕过System.out，改用FileOutputStream(FileDescriptor.out)
异步日志不是万能解药
引入 AsyncAppender 能缓解主线程阻塞，但可能引入新问题：
- 队列满时若配置
neverBlock="false"，业务线程仍会被阻塞 - 若
queueSize过小（如默认 256），高流量下日志快速丢弃或堆积 - 多个异步 Appender 写同一文件，可能引发文件句柄竞争或写入乱序
- 异常崩溃时，缓冲区中未刷盘的日志永久丢失
