file.getfreespace()返回值不准，因其仅读取文件系统超级块快照，不考虑用户配额、保留块（如ext4的5%）、nfs缓存或挂载选项，且结果可能滞后数秒；应优先使用getusablespace()。
File.getFreeSpace() 返回值为什么总是不准？
File.getFreeSpace() 返回的是文件系统层面的空闲空间，但不考虑用户配额、保留块（如 ext4 的 5% root reserve）、NFS 缓存延迟或挂载选项（如 noatime 或 barrier=1）。它只读取超级块快照，不是实时 I/O 统计。在高写入负载下，返回值可能比 df -B1 输出滞后数秒甚至更久。
实操建议：
- 不要单独依赖
File.getFreeSpace()做精确阈值判断，尤其在 ext4/xfs 等有保留空间的文件系统上 - 用
File.getUsableSpace()替代——它扣除了保留块和权限限制，更贴近普通进程实际可写大小 - 若必须用
getFreeSpace()，请搭配Runtime.getRuntime().exec("df -B1 /path")解析输出做交叉校验
Java 中每 30 秒轮询一次会触发 GC 或线程泄漏吗？
单纯调用 File.getUsableSpace() 不分配堆对象，不会直接引发 GC；但频繁创建 File 实例（尤其路径拼接用字符串 +）会在年轻代累积短生命周期对象。更大的风险来自轮询线程本身：如果用 new Thread(() -> { while(true) { ... } }).start() 且未设守护标志或退出条件，JVM 无法正常 shutdown，容易被误判为内存泄漏。
实操建议：
- 用
ScheduledExecutorService控制周期，显式调用shutdown()或设为daemon = true - 复用同一个
File实例，避免重复解析路径（new File("/data")只需一次） - 每次检查前加
if (!file.exists() || !file.isDirectory())，防止因目录被卸载导致异常中断轮询
预警阈值设 10% 还是 5GB？哪个更可靠？
绝对值（如 5GB）适合大容量盘（如 20TB SSD），但对小容量系统盘（如 50GB）会过早误报；百分比（如 10%）在小盘上可能只剩 500MB，来不及响应。真实生产环境应两者结合，并区分用途：系统盘看百分比 + 绝对下限，数据盘看绝对余量 + 写入速率趋势。
实操建议：
- 系统盘（
/,/var）：触发预警当usable - 数据盘（
/data,/log）：触发预警当usable 100MB/s * 60s（估算 1 分钟内将耗尽） - 所有阈值必须可配置，避免硬编码进逻辑——用
application.properties或环境变量注入
为什么本地测试正常，上线后预警总延迟 5 分钟？
常见原因是 JVM 所在容器未挂载宿主机的 /proc 和 /sys，导致 File API 读取的是容器 namespace 内的虚拟文件系统视图（如 overlay2 的 upperdir），而非物理磁盘真实状态。另一个原因是监控路径挂载在 NFS 上，而 NFS 客户端启用了 acregmin/acregmax 缓存属性，getUsableSpace() 结果最多缓存 300 秒。
实操建议：
- Docker 启动时加
--volume /proc:/proc:ro --volume /sys:/sys:ro - NFS 挂载加
noac或actimeo=1参数（需服务端支持） - 上线前用
df -B1 /your/monitored/path和 Java 日志输出对比数值，差值 > 1GB 就要查挂载上下文
实际部署时最容易被忽略的是：预警触发后没有自动清理临时文件或通知下游限流，而是只发一封邮件。磁盘满的根因往往不是空间小，而是某个日志组件没配 logrotate 或上传服务卡住没关流。
