为什么不推荐使用 java.util.logging？
java.util.logging（JUL）配置繁琐、功能有限、生态薄弱、性能一般，主流项目普遍选 Logback 或 Log4j2 并通过 SLF4J 门面编程。本文详解原因与替代方案。
一句话结论：JUL 不算"坏"，但它在配置灵活性、功能丰富度、性能和生态集成上都落后于 Logback / Log4j2，新项目没有理由选它；标准做法是基于 SLF4J 门面编程，底层绑定 Logback（或 Log4j2），同时用 jul-to-slf4j 把依赖库里残留的 JUL 输出桥接过来统一管理。
JUL 的主要短板
1. 配置繁琐且不直观
JUL 用 properties 文件配置，Handler/Formatter 概念绕，运行时动态调整能力弱；Logback 的 XML/Groovy 配置可读性和表达力都强得多。
2. 功能有限
缺少现代日志框架的标配能力：灵活的滚动策略（按时间+大小+压缩）、异步 Appender、MDC 的完整支持、条件化配置等。
3. 性能一般
JUL 的同步写入和锁机制在高并发下是瓶颈；Log4j2 的异步 Logger（基于 LMAX Disruptor）和 Logback 的 AsyncAppender 都明显更快。
4. 生态与社区薄弱
第三方扩展、与可观测平台/采集器的现成集成远少于 Logback/Log4j2，遇到问题可参考的资料也少。
推荐架构
业务代码 → SLF4J API → Logback（或 Log4j2）
依赖库的 JUL 输出 → jul-to-slf4j 桥接 → 同一套配置
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class Service {
private static final Logger log = LoggerFactory.getLogger(Service.class);
public void run() {
log.info("处理订单 orderId={}", 1001);
}
}
门面编程的好处：换实现只改依赖不改代码。
观测云对照
Java 日志统一接入观测云。 Logback 配置 JSON Encoder 输出结构化日志，DataKit 采集后字段自动可检索；桥接 JUL 后老依赖的输出也进入同一条链路，配合 APM 探针实现日志与调用链关联。
常见问题（FAQ）
Q：老项目全是 JUL，要重写吗？
A：不必。引入 jul-to-slf4j 桥接，JUL 调用原样保留，输出统一走 SLF4J 渠道，逐步迁移即可。
Q：Spring Boot 默认用什么？
A：默认 Logback + SLF4J，开箱即用；这也侧面说明了社区的选择。
Q：JUL 有什么适合的场景吗？
A：零依赖的小工具/库，不想引入任何第三方包时可以用——这正是它存在于 JDK 里的意义。
