java日志控制台无输出主因是jul根handler被关闭或级别设为off；slf4j+logback配置失效多因logback.xml位置错误或存在多绑定冲突；log4j2 asynclogger卡住常因disruptor队列满或上下文未显式传递；logback跨天滚动丢日志需校准时区、启用prudent模式并压测边界。
Java里用java.util.logging写日志，为什么控制台没输出？
默认情况下，java.util.logging（JUL）只启用Level.INFO及以上级别，且根处理器（ConsoleHandler）的日志级别也必须匹配。常见现象是调用了logger.info("xxx")却看不到输出——大概率是根Handler被静默关闭，或级别被设为OFF。
- 检查是否显式调用了
Logger.getLogger("").setLevel(Level.OFF)或类似操作 - 确认
ConsoleHandler已启用：Logger.getLogger("").getHandlers()应返回非空数组，且该Handler的getLevel()≥ 当前日志级别 - 若用IDE运行（如IntelliJ），注意其控制台可能过滤掉
System.err以外的输出；JUL默认走System.err，但某些环境会重定向失败
SLF4J + Logback组合中，logback.xml配置不生效怎么办？
SLF4J只是门面，真正干活的是绑定的实现（如Logback）。配置不生效，90%是因为logback.xml位置或命名不对，或类路径里混进了多个冲突的实现。
-
logback.xml必须放在src/main/resources/下（Maven项目），确保编译后位于classes/根目录 - 检查依赖：不能同时存在
logback-classic和slf4j-simple或slf4j-jdk14，否则SLF4J会随机选一个并报SLF4J: Class path contains multiple SLF4J bindings - 加JVM参数验证加载：
-Dlogback.debug=true，启动时会打印Logback加载过程，包括配置文件路径和解析结果
Log4j2异步日志（AsyncLogger）为什么没提速，反而卡住？
AsyncLogger依赖LMAX Disruptor队列，默认使用无界环形缓冲区，但若日志量突增、磁盘I/O慢或Appender阻塞（如网络Appender超时），队列会满，导致调用线程被阻塞——这和“异步”预期相悖。
- 确认是否启用了正确的异步方式：不是简单用
AsyncLoggerContext，而是要在log4j2.xml中声明<asynclogger></asynclogger>，或全局开启<configuration async="true"></configuration> - 检查
disruptor依赖是否在classpath中（Log4j2.17+已内置，旧版需手动引入） - 避免在
PatternLayout里用%X{key}等需要ThreadContext的操作——异步模式下上下文不自动传递，需显式调用ThreadContext.put()并配合async="true"属性
生产环境日志要滚动压缩，Logback的TimeBasedRollingPolicy怎么防丢日志？
按天滚动时，如果应用在00:00附近重启，可能因时间判断误差或锁竞争，导致当日日志写进错误文件（如app.log.2024-05-19），甚至丢失最后几条。
立即学习“Java免费学习笔记（深入）”；
- 强制使用
fileNamePattern中的日期格式与系统时区一致：app.%d{yyyy-MM-dd}.%i.log比app.%d{yyyy-MM-dd-HH}.log更稳定 - 设置
maxHistory="30"同时配totalSizeCap="3 GB"，避免仅靠时间清理导致磁盘爆满 - 关键服务建议加
<prudent>true</prudent>（但会牺牲性能，仅限多JVM写同一日志文件场景） - 上线前用
touch -d "2024-01-01 23:59:59" /tmp/testtime && java -Duser.timezone=GMT-8 -jar app.jar模拟跨天边界测试
slf4j-log4j12）和异步日志的上下文传递失效——这两处一旦出问题，排查成本远高于配置本身。 
