filesystemloopexception是非受检异常，源于软链接路径闭环而非代码循环；通过异常消息、readsymboliclink、find -l等可定位闭环；应在previsitdirectory中用realpath+set检测并预警，避免静默捕获。
FileSystemLoopException 不是受检异常，它是继承自 RuntimeException 的非受检异常（unchecked exception），编译器不会强制要求 try-catch 或 throws。所谓“死循环”也并非代码逻辑上的无限循环，而是文件系统中软链接构成的路径闭环（如 /a → /b → /a），Java NIO 在遍历时主动检测并中断，防止真实卡死——排查重点在路径结构，不在 Java 循环语句。
看异常消息，锁定环路入口点
异常字符串里直接给出闭环线索：
- 典型格式：
java.nio.file.FileSystemLoopException: /path/to/link → /another/path -
exception.getFile()返回触发异常的那个链接路径（即最后被解析的路径） -
Files.readSymbolicLink(Paths.get("/path/to/link"))可确认其目标；再对目标重复读取，直到路径重复出现，就还原出完整闭环链
例如：
/a/b/c → /a/b /a/b → /a/b/c ← 再次出现 /a/b/c，闭环确认：/a/b/c ⇄ /a/b
用命令行快速验证软链接拓扑
不启动 Java 也能定位风险：
-
find /target -type l -exec ls -la {} \; 2>/dev/null：列出所有软链接及其指向 -
readlink -f /suspect/link：展开为绝对规范路径，观察是否回绕到父级或已知目录 -
find -L /target -maxdepth 4 -name "*" 2>/dev/null | head -30：强制跟随链接走 4 层，若输出大量重复路径或跳转突兀（如从/app/logs突然跳到/app/config），大概率存在环
注意：
-L选项会让find自动跟随链接，但本身不报错——异常只在 Java 遍历中由 JVM 主动抛出。
代码中加轻量路径追踪，早于崩溃捕获
在 SimpleFileVisitor 的 preVisitDirectory 中记录已访问路径：
- 调用
path.toRealPath()获取真实物理路径（注意包裹try-catch，目标不存在时会抛IOException） - 用
Set<string></string>缓存.toString()结果，每次进入前检查是否已存在 - 若命中重复，立即打 WARN 日志（含当前路径、线程名、时间戳），并返回
FileVisitResult.SKIP_SUBTREE
避免静默 catch (FileSystemLoopException e) { } —— 这会掩盖问题，导致后续重复扫描或资源泄漏。
上线前批量扫描与源头清理
把防御前置到部署阶段：
-
find /app/root -xtype l：找出所有“悬空链接”（目标不存在），这类链接极易演变为闭环起点 -
ls -lR | grep " -> " | awk '{print $9, $11}'：提取所有链接关系，生成(source → target)列表，可用脚本做图遍历检测环 - 对确认无用的闭环链接，直接
rm linkname；若需保留，改用ln -sf /final/target linkname指向终点，消除中间跳转
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
