Log4j 2.20.0 在首次调用 LogManager.getLogger() 时出现数秒卡顿，主因是其内部自动解析 hostName 属性时触发了阻塞式 InetAddress.getLocalHost() 调用——该方法在 DNS 配置异常或主机名解析不畅时可能耗时长达 5–10 秒。
log4j 2.20.0 在首次调用 `logmanager.getlogger()` 时出现数秒卡顿，主因是其内部自动解析 `hostname` 属性时触发了阻塞式 `inetaddress.getlocalhost()` 调用——该方法在 dns 配置异常或主机名解析不畅时可能耗时长达 5–10 秒。
Log4j 2.x 默认会在初始化阶段自动注入运行时上下文属性（如 hostName、hostAddress、javaVersion 等），其中 hostName 的获取逻辑会调用 java.net.InetAddress.getLocalHost()。该方法看似轻量，实则隐含一次完整的 DNS 正向/反向解析流程：它先通过系统 hostname 命令获取主机名（如 my-mac.local），再尝试通过 DNS 解析该名称对应的 IP；若 DNS 不可用、/etc/hosts 缺失映射或网络配置异常（尤其在 macOS Ventura + M1 环境中常见），JVM 将陷入长达数秒的超时等待，直接拖慢整个应用启动。
✅ 根本解决方式：禁用自动 hostName 解析
最直接有效的方案是
跳过 hostName 属性的自动注入
，有以下两种推荐方式（任选其一）：
方式一：启动时通过 JVM 参数预设 hostName（推荐）
在运行应用时显式指定 hostName 系统属性，使 Log4j 直接使用该值，绕过 InetAddress.getLocalHost()：
✅ 优势：无需修改代码或配置文件，生效快，兼容所有 Log4j 2.x 版本（包括 2.20.0）；localhost 是安全、稳定且无需 DNS 解析的兜底值。
方式二：在 log4j2.xml 中禁用上下文查找器
通过配置 的 status 和 packages 属性，并
显式关闭 ContextSelector 的自动主机名发现
（需配合自定义属性）：
并在 Java 代码中确保使用带属性的 logger（可选）：
⚠️ 注意事项与补充建议
不要依赖 log4j2.formatMsgNoLookups=true 单独解决此问题
：该参数仅防止消息模板中的 Lookup 注入（如 ${env:HOME}），
不影响 hostName 等内置上下文属性的初始化逻辑
。
验证你的 /etc/hosts 是否正确
（macOS 用户重点检查）：
确保包含类似以下行（将 your-mac-name.local 替换为 hostname 输出结果）：
运行 hostname 和 ping $(hostname) 双重验证解析是否秒级返回。
开发环境快速验证命令
：
若该命令延迟 >1s，即确认为根本原因。
升级不是万能解
：问题在 2.17.0–2.20.0 均存在，Log4j 官方未将其视为 bug（属 JDK 行为），因此
主动规避比等待修复更可靠
。
总结
Log4j 启动延迟并非框架缺陷，而是其对 JDK 网络 API 的合理但敏感的依赖。通过 -DhostName=localhost 启动参数实现“零配置修复”，是兼顾简洁性、可靠性与跨平台兼容性的最佳实践。此举不仅消除数秒阻塞，更提升了开发迭代效率与终端用户体验——让日志系统真正成为无声的助力，而非启动路上的隐形路障。
java -Dlog4j2.formatMsgNoLookups=true \
-Dlog4j2.disable.jmx=true \
-DhostName=localhost \
-jar target/Example-1.0-SNAPSHOT.jar
localhost
private static final Logger logger = LogManager.getLogger(Main.class);
// 日志中将输出：10:23:45.123 [main] INFO localhost - application launched127.0.0.1 localhost
::1 localhost
127.0.0.1 your-mac-name.local# 测试 InetAddress.getLocalHost() 是否卡顿
java -c "java.net.InetAddress.getLocalHost().getHostName()"