getusablespace() 返回当前进程实际可写入的字节数，考虑权限、配额和保留空间；getfreespace() 仅返回文件系统未分配字节数，忽略权限与保留块。
Linux 下 getFreeSpace 与 getUsableSpace 的核心区别
在 Linux 系统中，getFreeSpace() 返回的是文件系统超级块中记录的“未分配字节数”，它不检查当前 JVM 进程是否有写权限，也不扣除 ext4/xfs 等文件系统的保留空间（如默认 5% 的 root reserve）。而 getUsableSpace() 会主动校验：当前进程对目标路径是否具有写权限、是否受用户配额限制、是否被保留块排除在外——最终返回的是该 JVM 实际能成功写入的字节数。
权限影响的具体表现
当目标路径存在但当前用户无写权限时：
Java Linux版
下载
Java Linux版下载入口，提供 Oracle JDK 26.0.2 官方 Linux 安装包、Java 环境配置、JDBC 数据库连接和 Java 服务端开发相关信息。
-
getFreeSpace()仍可能返回非零值（例如/root目录下，普通用户调用会得到真实空闲量，但根本无法写入） -
getUsableSpace()通常返回0或显著偏小的值，因为它在内核层面做了statvfs()调用，并参考了f_bavail字段（即普通用户可用块数） - 若路径本身不存在或不可读（
!file.exists() || !file.canRead()），两个方法都返回0L，但getUsableSpace()更早暴露权限问题
保留空间导致的典型偏差
以 ext4 文件系统为例，即使磁盘显示剩余 10GB，普通用户实际可写空间可能只有约 9.5GB（扣除了 5% 保留块）：
-
getFreeSpace()显示接近 10GB（对应f_bfree） -
getUsableSpace()显示约 9.5GB（对应f_bavail） - 这种差异在监控告警逻辑中尤为关键：用
getFreeSpace()设 90% 使用率阈值，可能在用户真正写满前就误报；而getUsableSpace()能更真实反映业务进程的写入瓶颈
生产环境推荐用法
不要直接依赖单次调用结果做决策，应结合路径有效性与权限校验：
- 始终先判断
file.exists() && file.canRead()，避免 0 值误导 - 优先使用
getUsableSpace()，尤其在需触发告警或拒绝上传等关键路径 - 如需交叉验证，可同步执行
Runtime.getRuntime().exec("df -B1 " + path)解析Avail列（等价于f_bavail） - 避免高频轮询（如小于 10 秒间隔），防止
statvfs系统调用堆积，影响性能
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
