filestore.getusablespace() 返回 0 的真实原因是 jvm 进程无权限读取或挂载点为伪文件系统（如 proc、overlay），而非磁盘已满；需过滤非物理存储、校验 totalspace、跨平台使用 getfilestores 并去重，告警应多采样+shell 交叉验证。
FileStore.getUsableSpace() 返回 0 的真实原因
不是磁盘真满了，而是 JVM 进程没权限读取该 FileStore 的实际使用状态——尤其在容器、Docker 或非 root 用户下常见。Linux 下某些挂载点（如 /proc、/sys、overlayfs）会返回 0 或不准确值，FileStore 本身不抛异常，只静默失效。
- 先用
Files.getFileStore(Paths.get("/"))获取实例，再调getTotalSpace()和getUsableSpace()对比：若后者为 0 但前者正常，基本可判定是权限或挂载类型问题 - 跳过虚拟文件系统：检查
fileStore.type()，过滤掉"proc"、"sysfs"、"cgroup"、"overlay"等非物理存储类型 - 容器中优先监控挂载的宿主机目录（如
/data），而非/根路径
如何正确遍历本机所有可监控磁盘分区
File.listRoots() 在 Windows 上能列出 C:、D:，但在 Linux/macOS 下只返回 /，完全不可靠；真正跨平台的方式是用 FileSystems.getDefault().getFileStores()，但它默认包含大量无意义的伪文件系统。
- 必须手动过滤：保留
fileStore.isReadOnly() == false且fileStore.getTotalSpace() > 0的条目 - Linux 下注意区分
ext4、xfs（可监控）和tmpfs（内存盘，容量易波动，告警阈值需调高） - 避免重复：同一物理设备可能因 bind mount 出现多个
FileStore，可用fileStore.name()+fileStore.totalSpace()组合去重
告警触发时为什么总延迟或漏报
直接轮询 getUsableSpace() 每秒一次看似合理，但 Linux 内核对磁盘统计有缓存（尤其是 ext4 的 delayed allocation），导致 Java 读到的数值滞后真实状态数秒甚至数十秒。
- 不要依赖单次采样：连续 3 次间隔 2 秒的采样都低于阈值（如 10%）才触发告警
- 避免高频轮询：JVM 调用
statvfs()是系统调用，每秒超 5 次可能引发内核负载上升，尤其在多磁盘场景 - 补充验证：告警触发后，用
Runtime.getRuntime().exec("df -B1 /path")同步执行 shell 命令交叉校验，但仅限关键路径，勿滥用
FileStore 不支持 Windows 网络驱动器（UNC 路径）
像 \servershare 这类 UNC 路径传给 Paths.get() 后，getFileStore() 会抛 FileSystemException：“The network path was not found”，不是 bug，是 JDK 明确不支持。
立即学习“Java免费学习笔记（深入）”；
- Windows 下监控网络盘，必须先映射为本地盘符（如
Z:），再用File.listRoots()扫描 - 映射盘符需确保服务账户有登录会话（否则
Z:对后台 Java 进程不可见），推荐改用 SMB 协议直连 +jcifs库查空间，但复杂度陡增 - 更务实的做法：在 UNC 路径所在服务器上部署本地监控 Agent，Java 程序只接收其 HTTP 上报结果
磁盘监控真正的难点不在获取数字，而在分辨哪些数字可信、哪些是内核障眼法，以及什么时候该信 Java、什么时候该信 df。别让 getUsableSpace() 的返回值看起来“很 Java”就以为它一定准。
