java应用日志占满磁盘需三步处理：先用df和du定位大日志文件，再用truncate清空或/proc/pid/fd截断释放空间，最后修复logback/log4j滚动配置并加logrotate兜底。
Java 应用在 Linux 上运行时，日志文件（尤其是未轮转、无大小限制的 stdout、stderr 或 Logback/Log4j 生成的日志）可能持续追加，快速占满磁盘，导致系统或应用异常。排查和解决需快速定位日志源、释放空间、并防止复发。
快速定位占用磁盘的 Java 日志文件
先确认磁盘使用情况，再聚焦 Java 进程相关文件：
- 运行
df -h查看哪个分区已满（如/var或/home） - 进入该分区，用
du -sh * | sort -hr | head -10找出最大目录 - 重点检查：
/var/log、应用部署目录下的logs/、./（当前工作目录）、/tmp - 结合 Java 进程查找日志路径：
ps -ef | grep java，观察启动命令中的-Dlog.path=...、--logging.file.name=...，或2>&1 > app.log类重定向 - 用
lsof +L1查看被删除但仍被进程打开的大文件（常见于 logrotate 后未重启 Java 进程，文件句柄未释放）
立即释放磁盘空间（应急操作）
不重启服务的前提下快速腾出空间：
- 清空正在写入但可丢弃的日志文件：
truncate -s 0 /path/to/app.log（比> app.log更安全，不破坏文件句柄） - 若发现被删除但仍在占用空间的文件（
lsof输出中显示(deleted)），可直接通过/proc/PID/fd/FD_NUM截断：echo > /proc/12345/fd/7 - 临时压缩旧日志：
gzip *.log.2024-05-*，减小体积 - 避免使用
rm -f删除正在写入的活跃日志——可能导致 Java 进程写入失败或异常（取决于日志框架行为）
检查并修复日志配置（防复发关键）
多数问题源于日志框架未启用滚动策略或配置不当：
-
Logback：检查
logback-spring.xml中<rollingpolicy></rollingpolicy>是否配置了TimeBasedRollingPolicy或SizeAndTimeBasedRollingPolicy，并设置了maxFileSize和maxHistory -
Log4j2：确认
RollingFileAppender使用了SizeBasedTriggeringPolicy+DefaultRolloverStrategy，且filePattern包含日期/序号，max指定了保留个数 -
Spring Boot 默认日志：检查
application.properties：logging.file.max-size=10MB、logging.file.max-history=7（2.x+ 支持） - 禁用 stdout/stderr 重定向到单一大文件（如
nohup java ... > out.log 2>&1），改用日志框架管理；若必须重定向，加tail -n 0 -f out.log | head -c 100M > out.log.tmp && mv out.log.tmp out.log类脚本控制大小（不推荐，仅临时）
长期加固建议
从系统和运维层面降低风险：
- 为 Java 应用分配独立用户，并设置磁盘配额（
edquota -u appuser） - 部署
logrotate配置（即使应用自身有滚动，作为兜底），注意加上copytruncate（兼容未重新打开文件句柄的应用） - 加入磁盘监控告警（如 Prometheus + Node Exporter 的
node_filesystem_usage_bytes） - 在启动脚本中添加空间检查逻辑，例如启动前执行：
[ $(df /var | awk 'NR==2 {print $5}' | sed 's/%//') -gt 90 ] && exit 1
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
