先说结论：Java 应用的日志如果不及时归档，项目跑上几个月，磁盘空间被撑爆是迟早的事。因此，日志归档这个环节必须提前规划。下面介绍的三种方法，覆盖了从“开箱即用”到“高度定制”的全场景，你可以根据项目实际情况灵活选择。
一、用 Logrotate：系统级的自动归档方案
Logrotate 是 CentOS 自带的日志管理工具，经常被忽视，但确实非常实用。它的最大优势在于完全不用修改 Java 代码就能实现日志的轮转、压缩和清理，适合需要统一管理服务器上所有日志的运维场景。
如何配置 Logrotate
- 安装 Logrotate。 绝大多数 CentOS 默认仓库都带了 Logrotate，没装的话执行
sudo yum install logrotate即可。 - 创建专属配置文件。 在
/etc/logrotate.d/目录下，新建一个专属于你 Java 应用的文件，比如/etc/logrotate.d/my_java_app。配置参考如下：
/path/to/your/java/app/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty create 640 root root sharedscripts postrotate /bin/kill -USR1 $(cat /var/run/my_java_app.pid) 2>/dev/null || true endscript }这里用了一个
sharedscripts配置项，它的作用是所有日志文件处理完后再执行一次 postrotate 脚本，避免因为一个应用有多个日志文件而频繁重启应用。另外，kill -USR1这条命令是为了通知 Java 应用重新打开日志文件，这样切割完日志后，应用能继续正常写入。 - 验证配置是否正确。 可以用
sudo logrotate -d /etc/logrotate.d/my_java_app模拟运行，检查语法。确认没问题后，执行sudo logrotate -f /etc/logrotate.d/my_java_app强制立即执行一次。
系统默认通过 /etc/cron.daily/logrotate 的定时任务每天自动执行，所以配置文件放好，基本就不用操心了。
二、用 Java 日志框架内置功能：应用级的灵活归档
如果你的项目用了 Log4j 或 Logback 这种日志框架，直接在配置文件里写规则是更优雅的做法。这样能实现更细粒度的控制，比如按文件大小滚动，或者自定义归档后的文件名格式。
Log4j 配置方式
Log4j 配置相对简单，用 RollingFileAppender 加上 MaxFileSize 和 MaxBackupIndex 就能实现按大小滚动。以 XML 配置为例：
这种方式简单直接，但灵活性不够——它只能按大小滚动，没办法按时间（比如每天一个文件）来做。
Logback 配置方式
Logback 就灵活多了。推荐使用 TimeBasedRollingPolicy 或者 SizeAndTimeBasedRollingPolicy。
按天滚动，保留 30 天：
/path/to/your/java/app/logs/app.log
/path/to/your/java/app/logs/app-%d{yyyy-MM-dd}.log
30
%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
按大小+时间双维度滚动，加上总大小限制：
/path/to/your/java/app/logs/app.log
/path/to/your/java/app/logs/app-%d{yyyy-MM-dd}.%i.log
10MB
30
1GB
%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
这其实是大部分生产环境最常用的配置。每天一个文件，单个文件超过 10M 会自动另起一个序列号，同时所有归档文件总大小不超过 1G，磁盘空间基本不用担心。注意项目里得保证有 Logback 的依赖（logback-core 和 logback-classic）。
三、用 Shell 脚本 + 定时任务：低成本定制
如果不方便安装 Logrotate，也不想改日志框架配置，那用 Shell 脚本自己写个归档逻辑是最直接的办法。虽然简单，但胜在完全可控、不依赖任何外部工具。
写个脚本
在 /usr/local/bin/archive_java_logs.sh 里写入以下内容：
#!/bin/bash
LOG_DIR="/path/to/your/java/app/logs"
ARCHIVE_DIR="/path/to/your/java/app/archive"
mkdir -p "$ARCHIVE_DIR"
for log_file in "$LOG_DIR"/*.log; do
if [ -f "$log_file" ]; then
gzip "$log_file"
mv "${log_file}.gz" "$ARCHIVE_DIR"
fi
done
find "$ARCHIVE_DIR" -name "*.gz" -mtime +7 -exec rm -f {} \;脚本的逻辑很直接：把日志目录下所有 .log 文件压缩后移动到归档目录，再删除 7 天前的旧文件。你可以根据需求调整 -mtime +7 的数字。
让它定时执行
先给脚本赋予执行权限：chmod +x /usr/local/bin/archive_java_logs.sh。
然后通过 crontab -e 添加定时任务：
0 2 * * * /usr/local/bin/archive_java_logs.sh >> /var/log/archive_java_logs.log 2>&1这样每天凌晨 2 点就会自动执行一次归档和清理操作。把输出重定向到日志文件里，方便排查问题。
几点提醒
不管用哪种方式，以下几条值得留意：
- 权限。 确保归档目录的写入权限正确，通常用
root或者应用启动时的用户去操作。 - 时机。 日志切割最好安排在低峰期，比如凌晨。如果是在高并发时段切割日志，应用突然收到
kill -USR1信号，理论上会影响几毫秒的性能。 - 策略。 保留多久的日志，取决于磁盘空间大小和业务需求。一般建议生产环境保留 30 天，但是像 Logrotate 的
rotate 7或 Logback 的maxHistory 30，根据实际情况灵活调整就行。 - 应用重启。 如果用 Logrotate 的
postrotate脚本通知应用，一定要确保发送的信号是正确的（通常是USR1），否则应用会继续向已重命名的日志文件里写内容，导致日志丢失。这个坑踩过的人应该不少。
