关于java.util.logging的原理咨询：老旧无同步多线程应用日志移植后存疑

嘿，我来给你捋清楚java.util.logging（咱们常叫JUL）在你这个多线程应用里到底是怎么跑的，结合你启动时的代码和场景拆解：

1. 启动阶段：LogManager的初始化与配置加载 #

你启动时调用的LogManager.getLogManager()是整个JUL体系的核心入口，它是JVM全局唯一的单例对象，管着所有日志相关的配置和Logger实例。

• 第一次调用getLogManager()时，JVM会先初始化这个单例，默认会尝试加载系统级的配置（比如JRE目录下的lib/logging.properties）。
• 之后你通过代码加载自定义的boxlog.properties（应该是在try块里调用了readConfiguration之类的方法吧？），这一步会覆盖默认配置。配置文件里一般会定义这些核心内容：
  • 全局或特定Logger的日志级别（比如INFO、DEBUG）
  • 日志处理器（Handler），比如控制台输出的ConsoleHandler、文件输出的FileHandler
  • 日志格式（Formatter），比如自带的SimpleFormatter或者你自定义的格式器
  • 文件日志的滚动策略、输出编码等细节

2. Logger实例的获取与关联 #

当你的多线程应用里各个模块需要打日志时，通常会通过Logger.getLogger(String name)来拿Logger实例：

• LogManager会维护一个Logger树结构，比如com.foo.moduleA和com.foo.moduleB会自动继承com.foo的配置，最顶层的是根Logger（名字是空字符串""）。
• 每个Logger实例都是线程安全的，JUL内部已经做了锁机制，所以多线程同时拿Logger或者修改配置时，不会出现竞态问题——这对你的老旧多线程应用特别友好，不用自己加同步逻辑。

3. 一条日志从调用到输出的完整流程 #

当某个线程调用logger.info("xxx")这类方法时，整个流程是这样走的：

1. 级别快速校验：Logger先判断当前日志的级别是否高于自身配置的级别，如果低于（比如Logger是INFO级别，却调用了debug日志），直接跳过，避免做无用功，提升性能。
2. 过滤规则校验：如果给Logger或Handler配置了Filter，会先过一遍Filter的判断，不符合规则的日志直接被丢弃。
3. 传递日志事件：Logger会把日志封装成LogRecord对象，传递给自己的Handler，同时默认也会传递给父Logger的Handler（除非你设置了setUseParentHandlers(false)关闭这个继承）。
4. Handler处理输出：每个Handler会再做一次级别校验，然后用Formatter把LogRecord格式化成可读性强的字符串，最后输出到目标（控制台、文件、甚至远程服务器）。
   • 划重点：Handler本身也是线程安全的，比如FileHandler内部会加锁，保证多线程同时写日志时不会出现日志乱序或者文件损坏的情况。

4. 多线程环境下的关键特性 #

因为你的应用是大型多线程的，JUL的这些特性刚好适配你的场景：

• LogRecord的线程信息绑定：每个LogRecord会自动记录当前线程的名字、ID，方便你排查多线程下的问题，比如追踪某条日志是哪个线程打出来的。
• 无需额外同步：Logger和Handler内部已经实现了线程安全，你的应用不用在打日志的地方加同步锁，避免拖慢多线程的运行效率。
• 配置动态更新：如果需要调整日志级别或者输出规则，不用重启应用，直接调用LogManager.readConfiguration()重新加载配置就行，JUL会原子性地把新配置应用到所有Logger实例上。

5. 和你原有专有日志组件的小差异（补充） #

原来的专有日志是自定义实现，而JUL是JDK内置的标准库，它的优势是不用额外加依赖，且遵循Java的日志规范。你移植后能正常运行，说明你的配置和Logger的使用方式已经匹配了JUL的逻辑——比如原来的日志级别和JUL的级别对应上了，输出目标的配置也正确映射到了Handler上。

内容的提问来源于stack exchange，提问作者Siegfried