Java调用FileUtils删目录遇IOException：第二个目录无法删除

我来梳理几个常见的、可能导致你遇到这个问题的原因，毕竟我在处理文件操作相关问题时也碰到过类似场景：

• 当前Java进程持有该目录的文件句柄
  你提到用lsfo（应该是lsof吧？）检查了其他进程，但别忘了当前运行这段代码的Java进程本身可能还握着该目录或其下文件的句柄。比如之前你遍历过这个目录的文件、打开过其中的流但没正确关闭，或者用了File.listFiles()这类操作后，相关资源没被GC及时回收。
  可以试试用lsof -p <你的Java进程PID> | grep Job000000000676来排查当前进程是否还持有该目录的句柄；或者导出堆快照分析有没有未关闭的FileInputStream、FileChannel等对象。

• 目录残留隐藏文件/特殊文件
  尤其是在NFS挂载的文件系统上，当文件被删除但仍有进程持有其句柄时，系统会创建.nfs开头的隐藏临时文件。这类文件会阻止目录被删除，即使你看起来已经删光了所有可见文件。
  你可以执行ls -la /opt/appdata/conv/data/out/Job000000000676查看目录下的所有内容，包括隐藏文件。如果发现.nfs文件，要么等持有句柄的进程彻底退出，要么重启NFS客户端来清理这类临时文件。

• Apache Commons IO的deleteDirectory存在执行间隙
  这个方法的逻辑是先递归删除所有子文件和子目录，最后删除当前目录。如果在删除子内容到删除目录本身的间隙里，有其他操作（比如另一线程、定时任务）往这个目录里写入了新的文件/目录，就会导致最后删除目录失败。
  你可以在调用deleteDirectory前后，加上日志打印目录的内容，看看是否有意外的文件被创建；或者给删除操作加个同步锁，避免并发写入。

• 文件系统层面的异常
  比如磁盘IO错误、inode损坏，或者目录所在的分区出现了文件系统不一致的问题。这种情况比较少见，但可以通过df -h检查磁盘空间是否正常，用fsck（注意需先卸载分区或进入单用户模式）来修复文件系统的潜在问题。

另外，建议你捕获异常时打印完整的堆栈信息，IOException通常会包含更细节的失败原因，比如是“目录不为空”还是“权限不足”，这能帮你更快定位问题。

内容的提问来源于stack exchange，提问作者Alexandre