Java 应用长期运行在 Linux 上，日志文件通常会持续增长；如果缺少轮转和清理机制，磁盘占满后不仅会触发告警，还可能直接影响服务稳定性。实际处理时，关键不只是“删日志”，而是根据部署方式、日志来源和保留周期，把系统工具、应用配置与定时任务组合起来，既控制容量，也保留必要的排障记录。
下面按常见场景拆开说明：什么时候适合用 logrotate，什么时候需要自己写脚本，Java 日志框架本身能做哪些事，以及 systemd 和手动清理分别适合解决什么问题。
为什么要提前规划 Java 日志清理
日志清理最好不要等磁盘报警后再补救。对于部署在 Linux 上的 Java 服务来说，日志来源往往不止一种：应用自身输出的文件日志、systemd 接管后的 journal 日志，以及临时导出的备份文件，都会占用磁盘空间。
更稳妥的做法，是提前明确三件事：日志保留多久、由谁负责轮转、出问题后需要保留多少历史。这也是下面几种方法的选择依据。
用 logrotate 做系统级轮转和清理
如果你的 Java 应用把日志写到普通文件中，logrotate 通常是最省心的一种方式。它是 Linux 常见的日志管理工具，可以自动完成轮转、压缩、保留和删除，适合批量管理固定目录下的日志文件。
安装与基本命令
如果系统里还没有安装 logrotate，可以按发行版使用对应命令：
sudo yum install logrotate # CentOS/RHEL系统
sudo apt install logrotate # Ubuntu/Debian系统配置轮转规则
可以新建或编辑 /etc/logrotate.d/java 文件，为 Java 日志目录单独定义规则。下面这段配置保留了原文里的参数含义，路径需要替换成你自己的实际目录：
/path/to/your/java/logs/*.log {
daily # 按天轮转（可选：weekly/monthly）
rotate 7 # 保留最近7天的日志
compress # 压缩旧日志，节省空间
missingok # 日志文件不存在也不报错
notifempty # 日志为空时不轮转
create 0644 root root # 轮转后创建新日志文件并设置权限
}这类配置适合规则比较稳定的场景，比如每天切分、保留 7 份历史并压缩旧文件。
生效前先做测试
配置写完后，建议先做一次调试检查：
logrotate -d /etc/logrotate.d/java确认没有语法或路径问题后，再重新加载配置：
sudo systemctl reload logrotate对于大多数标准文件日志来说，logrotate 已经足够覆盖“定时轮转 + 历史压缩 + 自动删除”这套基础需求。
需要更灵活时，用 Shell 脚本做备份与清理
logrotate 的优点是稳定、省事，但它并不适合所有需求。比如你想把日志备份到单独目录、按自定义命名保存，或者后续还要同步到远程服务器，这时 Shell 脚本会更灵活。
脚本示例
下面是一个原文给出的示例脚本 backup_java_logs.sh，用于备份当前日志、清空原始文件，并删除 30 天前的备份：
#!/bin/bash
BACKUP_DIR="/path/to/backup/directory" # 备份目录
DATE=$(date +%Y%m%d) # 当前日期，用于文件名
LOG_DIR="/path/to/your/java/logs" # Java日志目录
# 备份日志文件，带上日期后缀
cp "$LOG_DIR"/*.log "$BACKUP_DIR/java_$DATE.log"
# 清空原始日志文件，避免占用空间
> "$LOG_DIR"/*.log
# 删除30天前的备份文件
find "$BACKUP_DIR" -mtime +30 -type f -name "java_*.log" -exec rm -f {} ;配合定时任务执行
脚本写好后，先赋予执行权限：
chmod +x backup_java_logs.sh然后通过 crontab -e 添加定时任务。比如每天凌晨 0 点执行一次：
0 0 * * * /path/to/backup_java_logs.sh这种方式适合“清理动作不止删除” 的情况，例如要先归档、再清空、最后再按保留期删除历史文件。
直接在 Java 日志框架里配置轮转
如果你希望从应用层直接限制日志体积，那么在日志框架中配置轮转策略，通常比事后手动清理更可靠。常见的 Logback 和 Log4j 2 都支持按时间、按大小或混合条件轮转，并能控制保留数量。
Logback 示例
以下是 logback.xml 的配置示例：
logs/app.log
logs/app-%d{yyyy-MM-dd}.log.gz
30
%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n
这份配置的重点在于：当前日志写入 logs/app.log，旧日志按日期命名并压缩，最多保留 30 天历史。
Log4j 2 示例
如果项目使用的是 Log4j 2，可以参考下面的 log4j2.xml 配置：
和 Logback 相比，这里多了一层按大小触发的控制：除了按天轮转，单个文件超过 100 MB 时也会切分，同时最多保留 20 个备份文件。
如果应用本身已经支持这类能力，优先在框架层处理，通常能减少外部脚本和手工维护成本。
应用由 systemd 启动时，用 journalctl 管理日志
如果 Java 应用不是自己写文件，而是通过 systemd 启动并把输出交给 journal，那么清理方式就和普通 .log 文件不同了。这种场景更适合直接用 journalctl。
按时间保留
例如只保留最近 1 周的 journal 日志：
sudo journalctl --vacuum-time=1w按容量保留
如果你更关心磁盘占用，可以按总大小限制：
sudo journalctl --vacuum-size=500M针对单个服务清理
也可以只处理某个指定服务，例如 java-app，仅保留最近 3 天的日志：
sudo journalctl --unit=java-app --vacuum-time=3d这种方式的优势在于，它直接针对 systemd 管理的日志体系，不需要再去定位具体文件路径。
临时处理时，手动清理要注意什么
手动清理适合临时救火，或者处理已经确认无用的旧文件，但要特别注意不要误删仍在写入的日志。
删除过期日志文件
例如删除指定目录下 30 天前的 .log 文件：
find /path/to/java/logs -type f -name "*.log" -mtime +30 -exec rm -f {} ;只清空内容，保留文件
如果你的目标只是立刻释放空间，同时保留文件本身，可以直接清空某个日志：
> /path/to/java/logs/app.log这个操作不会删除文件，只会清空内容，因此在某些排障或兼容固定文件路径的场景下更稳妥。
实际环境里怎么组合使用
这几种方法并不是互斥关系。对于大多数线上 Java 服务，更常见的做法是分层处理：
- 普通文件日志交给
logrotate做系统级批量管理； - 应用内部再通过 Logback 或 Log4j 2 控制单文件大小、按天切分和历史保留；
- 如果服务由
systemd托管，再额外用journalctl控制 journal 占用； - Shell 脚本和手动命令，则保留给备份归档、临时清理或特殊规则处理。
简单说，想省事就优先用框架配置和 logrotate；有备份、归档或远程同步需求时，再补充脚本；如果日志根本不落文件，而是走 systemd，就应把重点放在 journalctl 上。把日志来源和保留目标分清楚，方案自然就不会乱。
