Java应用日志自动清理应依赖Logback或Log4j2内置策略而非手动删除：Logback用TimeBasedRollingPolicy配maxHistory按天清理；Log4j2用DefaultRolloverStrategy配max按文件数清理；运维层可辅以find命令或logrotate兜底。
Java 应用中日志文件的自动清理，通常不靠 Java 代码手动删除，而是交由日志框架（如 Logback、Log4j2）内置的归档与滚动策略来完成。关键在于正确配置滚动策略和清理条件，让框架在生成新日志的同时，自动删除过期的旧日志文件。
使用 Logback 的 TimeBasedRollingPolicy 自动清理
Logback 是 Spring Boot 默认日志实现，推荐使用基于时间的滚动策略配合清理规则：
- 在 logback-spring.xml 或 logback.xml 中配置
TimeBasedRollingPolicy - 通过
30表示只留最近 30 天） - 确保
app.%d{yyyy-MM-dd}.%i.log），否则无法按时间识别和清理
示例片段：
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"><file>logs/app.log</file><rollingpolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"><filenamepattern>logs/app.%d{yyyy-MM-dd}.%i.log</filenamepattern><timebasedfilenamingandtriggeringpolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"><maxfilesize>100MB</maxfilesize></timebasedfilenamingandtriggeringpolicy><maxhistory>30</maxhistory></rollingpolicy></appender>
Log4j2 使用 DefaultRolloverStrategy 控制保留数量
Log4j2 通过 max 属性限制归档文件总数（注意：它是按文件数，不是按天）：
- 搭配
-
max="30"表示最多保留 30 个归档文件（如 app-2024-05-01.log.gz、app-2024-05-02.log.gz…） - 若同时启用压缩（
fileExtension=".gz"），清理会一并删除压缩包
注意：Log4j2 没有直接的“保留 N 天”参数，需估算日均生成文件数来设置 max 值。
避免手动清理：不要写定时任务删日志文件
常见误区是用 ScheduledExecutorService 扫描目录、按修改时间删除旧文件。这种方式存在风险：
- 可能误删正在被日志框架写入的临时文件（如
.tmp或未完成 rollover 的文件） - 与日志框架的滚动逻辑冲突，导致归档错乱或丢失日志
- 增加应用复杂度，且难以覆盖所有边界情况（如异步写入、JVM 异常退出）
真正需要定制清理逻辑的场景极少——优先信任 Logback / Log4j2 经过验证的归档机制。
额外建议：结合运维手段做双重保障
即使日志框架配置正确，也建议在部署层面加一层兜底：
- Linux 下可用
find /path/to/logs -name "*.log*" -mtime +30 -delete作为定期 cron 任务（频率低于日志滚动周期，如每周一次） - Docker 环境中，可挂载日志目录到 host，并用 host 的 logrotate 管理
- 云环境（如 Kubernetes）推荐对接集中式日志系统（Loki、ELK），本地只保留短周期日志
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
