先用 df -h 和 df -i 确认磁盘空间与 inode 是否耗尽，再用 du -sh */logs | sort -hr 定位大日志目录，结合 lsof +L1 和 lsof -p 查看被 Java 进程占用的活跃或已删未释日志文件，最后通过 truncate -s 0 安全清空并配置 logback 滚动策略预防复发。
当 Java 应用在 Linux 上运行时，日志文件（如 logs/ 下的 catalina.out、spring-boot.log 或自定义 logback 日志）长期未轮转或清理，极易导致磁盘空间被快速占满。此时通过 df 和 du 组合使用，能快速定位“谁吃了磁盘”，无需重启服务或翻代码。
先用 df 确认是否真爆满，以及是哪个挂载点告警
df -h 显示各挂载点使用率，重点关注 Use% 列。若某分区（如 / 或 /opt）达到 90%+，说明已触发报警阈值。注意看 Mounted on 列——Java 应用日志通常落在 /var/log、/opt/app/logs 或应用根目录下的 logs/，这些路径往往属于根分区或独立挂载点。
- 加
-i参数（df -hi）检查 inode 是否耗尽：日志文件多而小（如每秒生成一个 1KB 文件）时，可能磁盘空间还有余量但 inode 耗光，同样导致写入失败 - 若发现
/dev/shm或/run占用异常高，需排查是否 Java 应用误将临时文件写入内存文件系统
用 du 找出大日志目录和具体文件
进入疑似高占用挂载点（如 /opt），执行：du -sh */logs 2>/dev/null | sort -hr | head -10
这条命令递归统计所有子目录下 logs 文件夹大小，并按降序列出前 10 名。常见结果：./myapp/logs 占 12G，./tomcat/logs 占 8.5G。
- 进一步精确定位：进入该 logs 目录，运行
du -sh * | sort -hr | head -5，快速看到最大的几个日志文件（如catalina.out、gc.log.0.current） - 对单个可疑文件，用
ls -lh catalina.out查看大小和最后修改时间；若文件持续增长且无修改时间更新，可能是应用仍在追加写入但未关闭句柄 - 用
lsof +L1检查是否有已被删除但仍被 Java 进程占用的“幽灵日志文件”（常见于 logrotate 未发送 HUP 信号）
结合 Java 进程确认日志归属和写入状态
查到大日志后，需确认它是否正被当前 Java 进程写入。运行：lsof -p $(pgrep -f "java.*myapp") | grep logs
输出会显示该 Java 进程打开的日志文件路径及文件描述符。若看到 catalina.out 被打开且 size 不断变化，基本锁定问题源头。
立即学习“Java免费学习笔记（深入）”；
- 若发现日志路径指向
/tmp或/dev/shm，检查应用配置中logging.file.path或logback-spring.xml的<file>设置是否错误 - 用
tail -f -n 100 logs/app.log实时观察日志滚动频率和内容——高频 ERROR 堆栈或重复打印提示可能存在循环异常
临时缓解 + 长效预防建议
定位到问题日志后，可立即清理或截断（避免直接 rm 导致进程写入失败）：truncate -s 0 catalina.out 安全清空（保持文件句柄有效）；或 cp /dev/null catalina.out 效果相同。
- 检查 logback/log4j 配置：确保启用了基于大小或时间的滚动策略（如
<timeBasedFileNamingAndTriggeringPolicy>），并设置maxHistory和totalSizeCap - 生产环境禁用
catalina.out：在bin/setenv.sh中添加export CATALINA_OUT=/dev/null，改用logging.properties统一管理 - 为关键日志目录配置定时清理脚本（如每天凌晨压缩 7 天前日志并
find logs -name "*.log.*" -mtime +30 -delete）
