为什么Java计算文件哈希的代码会陷入内层while循环无法退出？

问题成因分析 #

你遇到的卡住问题分两种常见情况，对应不同的根因：

• 低CPU占用的阻塞（90%以上的概率是这个情况）
  根本不是while无限循环，是FileInputStream.read()方法进入了阻塞状态：
  你的allFiles列表中混入了非普通文件，包括但不限于：
  • 网络挂载路径（NFS、SMB共享等）下的文件，网络不稳定时read会一直等待响应
  • Linux下的伪文件系统（/proc、/sys）、设备文件（/dev/random、/dev/zero等）、管道文件、Socket文件，这类文件没有固定的EOF标记，只要有数据生成就会一直返回可读内容，或者没有足够输入时就会一直阻塞
  • 正在被其他进程持续写入的命名管道，只要写入端不关闭，读取端就不会收到EOF标记
• 高CPU占用的真正无限循环
  如果你确认卡住时进程CPU占比很高，那只有一种可能：你实际运行的代码和你贴出的代码有出入，read()方法的返回值处理出错了：
  如果你错误的将read()的返回值存入了byte类型变量，而非int类型：read()返回的有效值范围是0~255，返回-1代表EOF，如果你把返回值强转为byte，255会被转换成byte类型的-1，虽然这个场景通常会导致提前退出循环，但如果你的代码逻辑写反了判断条件、或者漏写了循环内的b = fis.read()赋值语句，就会出现无限循环。

修复方案 #

• 第一步先定位问题文件：在FileInputStream fis = new FileInputStream(file.getAbsolutePath());之前加一行打印代码System.out.println("Processing file: " + file.getAbsolutePath());，运行后最后打印的路径就是导致卡住的文件，可直接定位根因。
• 提前过滤非普通文件：遍历allFiles时先调用file.isFile()判断是不是标准普通文件，过滤掉目录、符号链接、特殊设备文件。
• 优化流处理逻辑：用try-with-resources语法自动关闭流，避免异常时的资源泄漏，示例修改后的读取逻辑：

  try (FileInputStream fis = new FileInputStream(file)) {
      int b;
      int xor = 0;
      // 新增计数器避免超长读取
      long readCount = 0;
      long fileLength = file.length();
      while ((b = fis.read()) != -1) {
          xor ^= b;
          readCount++;
          if (readCount > fileLength) {
              // 非正常文件，直接跳出避免卡死
              break;
          }
      }
      // 后续哈希计算逻辑
  }
  

• 补充优化建议：你当前用的异或哈希碰撞概率极高，排查重复文件建议用MD5、SHA-1等标准哈希算法，避免误判不同文件为重复文件。

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