Logback异步日志不卡主线程的关键是合理配置AsyncAppender的队列容量与行为策略：需将queueSize设为8192～32768，启用neverBlock="true"并设discardingThreshold=0，同时关闭includeCallerData、避免套用ConsoleAppender，并确保磁盘I/O匹配。
Logback 异步日志不卡主线程的关键，是让队列既能扛住突发流量，又不因满而阻塞或盲目丢日志。光加 <AsyncAppender> 不够，必须调准队列容量和行为策略。
队列大小不能靠默认值撑住生产流量
Logback 的 AsyncAppender 底层用 ArrayBlockingQueue，默认 queueSize=256 —— 这在压测或秒杀场景下几秒钟就满。队列一满，若没配对策略，业务线程就会等在 put() 上。
- 建议将
queueSize设为 8192～32768（根据峰值 QPS 估算：QPS × 50～100 是较稳妥的起点） - 不宜无限制调大：比如设成 100 万，会显著增加堆内存占用，GC 压力上升
- 若应用日志量极低（如后台定时任务），256 可能够用；但 Web 服务、网关类应用务必上调
丢弃策略要明确且可控
队列满时，Logback 默认行为是丢弃新日志（discardingThreshold 默认为队列容量的 20%，即剩余容量低于 20% 就开始丢 INFO 及以下日志）。但这不是“不阻塞”的充分条件——它只丢低优先级日志，WARN/ERROR 仍可能排队导致阻塞。
- 必须显式配置
<neverBlock>true</neverBlock>，让队列满时调用offer()而非put()，彻底避免阻塞 - 同时设置
<discardingThreshold>0</discardingThreshold>表示“不主动丢日志”，但前提是neverBlock="true"已启用，否则discardingThreshold=0会退回到阻塞模式 - 如果接受部分日志丢失，可设
discardingThreshold为具体数值（如 1024），表示剩余空间低于该值时开始丢TRACE/DEBUG/INFO日志，WARN及以上保留
配套参数必须同步优化
单改队列大小治标不治本：
-
<includeCallerData>false</includeCallerData>：避免每次日志都触发Throwable.getStackTrace()，否则 GC 爆增，间接加剧队列积压 - 配合
RollingFileAppender使用，别套在ConsoleAppender上压测（控制台本身是同步瓶颈） - 检查磁盘 I/O 是否跟得上：SSD + 合理滚动策略（如
SizeAndTimeBasedRollingPolicy+maxFileSize=100MB），否则再大队列也撑不住写入
验证是否生效，看两点：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 日志中出现
AsyncAppender-Worker-1类似线程名 -
logback-status.html或启动日志里没有QUEUE_FULL警告
不复杂但容易忽略
