Logback通过RollingFileAppender配合TimeBasedRollingPolicy实现异步压缩归档，配置fileNamePattern含.gz后缀触发自动压缩，并用AsyncAppender包裹以避免I/O阻塞。
Java 日志的异步压缩归档，核心不是靠 Java 代码手动实现，而是通过成熟的日志框架（如 Logback 或 Log4j2）配置完成。关键在于：选择支持异步写入 + 自动滚动 + 压缩归档的日志实现，并正确配置其内置机制。
用 Logback 实现异步压缩归档（推荐）
Logback 原生支持 RollingFileAppender 配合 TimeBasedRollingPolicy 或 SizeAndTimeBasedRollingPolicy，可自动按时间/大小滚动，并在归档时启用 GZ 压缩。
- 添加
<rollingpolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"></rollingpolicy>，设置fileNamePattern含.%d{yyyy-MM-dd}.%i.gz—— 后缀.gz触发自动压缩 - 嵌套配置
<timebasedfilenamingandtriggeringpolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"></timebasedfilenamingandtriggeringpolicy>可同时按天和单文件大小（如 100MB）触发归档 - 异步写入：外层包裹
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"></appender>，将 RollingFileAppender 作为子 appender，避免 I/O 阻塞主线程
Log4j2 的等效方案
Log4j2 使用 RollingFileAppender + TimeBasedTriggeringPolicy + DefaultRolloverStrategy，压缩需借助 CompressionLevel 和归档文件名后缀（如 app.log.$${date:yyyy-MM-dd}.gz）。
- 确保
filePattern中包含.gz，并设置compressionLevel="6"（0–9，默认为 -1 表示不压缩） - 异步能力更优：直接使用
AsyncLoggerContextSelector（系统属性log4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector），或用AsyncAppender - 注意：Log4j2 对 GZ 压缩的支持依赖
log4j-core内置逻辑，无需额外引入压缩库
不建议手写异步压缩逻辑的原因
自己开线程监听日志文件、调用 GZIPOutputStream 压缩、删除旧文件，看似可控，实则风险高：
立即学习“Java免费学习笔记（深入）”；
- 容易与日志框架的文件锁、滚动时机冲突，导致压缩失败或文件损坏
- 无法精准判断“该压缩哪个文件”——框架滚动后的文件名、时间戳、是否正在写入，都需严格同步
- 增加运维复杂度：异常处理、OOM 风险、磁盘满兜底策略都要自行实现
关键配置检查点
无论选 Logback 还是 Log4j2，上线前务必验证以下行为：
- 当日志达到滚动条件（如 23:59:59 或文件超 100MB），是否生成带
.gz后缀的归档文件，且原始日志文件被清空或重命名 - 压缩后文件能否正常解压查看（可用
gunzip -t xxx.log.2024-06-15.0.gz校验） - 异步配置生效后，高并发打日志时，应用响应时间是否稳定（对比关闭异步时的 RT 波动）
- 归档保留策略（如只留 30 天）是否按预期清理过期压缩包（Logback 用
maxHistory，Log4j2 用delete子节点）
