Logback 的日志输出（如 log.debug()）默认写入 stdout，而 e.printStackTrace() 默认输出到 stderr；两者属于不同流、无同步机制，导致控制台显示顺序不可靠，尤其在多线程场景下更易出现“堆栈先于后续日志打印”的现象。
logback 的日志输出（如 `log.debug()`）默认写入 stdout，而 `e.printstacktrace()` 默认输出到 stderr；两者属于不同流、无同步机制，导致控制台显示顺序不可靠，尤其在多线程场景下更易出现“堆栈先于后续日志打印”的现象。
在使用 Logback（配合 Lombok @Slf4j）进行日志记录时，开发者常遇到一个看似违反执行顺序的“怪现象”：代码中 e.printStackTrace() 明确位于 log.debug("continue") 之前，但终端输出中却看到堆栈信息出现在 "continue" 日志之后（或穿插其间）。例如以下典型复现代码：
@Slf4j
public class SleepTest {
public static void main(String[] args) {
Thread t0 = new Thread(() -> {
log.debug("running...");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace(); // ← 写入 stderr
}
log.debug("continue"); // ← 写入 stdout（经 Logback 处理）
}, "t0");
t0.start();
t0.interrupt();
}
}
其输出可能为：
00:09:48 [t0] [DEBUG] com.example.SleepTest - running...
00:09:48 [t0] [DEBUG] com.example.SleepTest - continue
java.lang.InterruptedException: sleep interrupted
at java.base/java.lang.Thread.sleep(Native Method)
...
⚠️ 注意：这并非执行顺序错误，而是 stdout 与 stderr 两个独立输出流的缓冲与刷新行为差异所致。
- log.debug(...) 经由 Logback 输出，默认走 System.out（或配置的 Appender，如 ConsoleAppender），其底层通常基于 System.out（即 stdout）；
- e.printStackTrace() 则硬编码写入 System.err（stderr），且默认无缓冲（或行缓冲），响应更快；
- 二者无同步机制，JVM 不保证跨流输出的时序一致性；
- 多线程环境下（如本例中 t0 线程），竞争加剧了这种不确定性。
✅ 正确做法：统一日志出口，避免混用 printStackTrace() 与框架日志。推荐使用 Logback 原生异常记录能力：
} catch (InterruptedException e) {
log.debug("Thread interrupted during sleep", e); // ✅ 自动附加完整堆栈
// 或使用更合适的级别
log.warn("Sleep interrupted; proceeding with cleanup", e);
}
该方式将异常对象作为参数传入，Logback 会自动格式化并输出堆栈跟踪（含缩进与换行），且全部内容严格按单次日志事件原子写入同一输出流（如 stdout），彻底消除顺序错乱。
? 补充建议：
- 若需强制同步 stdout/stderr（仅限调试，不推荐生产），可手动刷新：
System.out.flush(); System.err.flush();
但无法根治竞态，且影响性能；
- 检查 logback.xml 中 ConsoleAppender 是否配置了 immediateFlush="true"（默认为 true），确保日志实时落屏；
- 生产环境务必禁用 printStackTrace() —— 它绕过日志级别控制、丢失 MDC 上下文、无法路由至文件/ELK 等后端，且格式不统一。
总之，日志应“全链路托管”：异常捕获后，交由日志框架统一处理，而非混合使用原始 I/O 方法。这是保障可观测性、可维护性与线程安全性的基本实践。
