防止日志无限增大需启用滚动与保留策略：用logback的rollingfileappender配合sizeandtimebasedrollingpolicy（如maxfilesize="100mb"、maxhistory="30"）、totalsizecap="5gb"，并警惕asyncappender丢日志风险，辅以磁盘空间检查和logrotate兜底。
防止日志文件无限增大，核心是启用日志滚动（Rolling）和设置保留策略，而不是只靠手动清理或简单按天切分。
用支持滚动的 Appender（如 Logback 的 RollingFileAppender）
Logback（最常用的 Java 日志实现）默认的 FileAppender 不滚动，必须改用 RollingFileAppender，并配合 RollingPolicy 和 TriggeringPolicy：
- TimeBasedRollingPolicy：按时间滚动（如每天一个文件），适合按周期归档
- SizeAndTimeBasedRollingPolicy：同时按大小 + 时间滚动（推荐），避免单日日志过大导致单个文件超 GB
- 示例配置中指定
maxFileSize="100MB"和maxHistory="30"，表示单个文件最大 100MB，最多保留 30 个归档文件
合理设置归档保留数量与生命周期
仅滚动不够，不清理旧文件仍会占满磁盘：
-
maxHistory控制保留多少个历史文件（按滚动单位计），不是天数——比如按天滚动且设为 30，就保留最近 30 天；按大小滚动且设为 30，则保留最近 30 个归档文件 - 搭配
totalSizeCap（如"5GB"）可设所有日志总大小上限，超出时自动删除最老的归档 - 避免设为 -1 或不设限制，否则归档持续累积
警惕异步日志中的缓冲与丢弃风险
用 AsyncAppender 提升性能时需注意：
- 异步队列满后，默认会 丢弃新日志（
discardingThreshold默认为 25%），可能掩盖问题 - 若需强保障，可设
neverBlock="true"配合合理的queueSize（如 256），并监控队列堆积情况 - 注意：异步不会影响滚动逻辑，但若应用崩溃前日志未刷出，可能丢失最后部分日志
补充建议：加一层轻量级运维防护
框架层控制是主力，但可叠加简单防护：
- 在启动脚本中检查日志目录剩余空间，低于阈值（如 10%）时打印告警或拒绝启动
- 用 logrotate（Linux）作为兜底：即使 Java 层滚动异常，系统级轮转仍能防爆盘（注意避免与 Java 层重复滚动导致冲突）
- 避免将日志写入根分区，单独挂载
/var/log/app并限制配额（如使用 XFS project quota）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
