NodeJS并发执行大量大型目录删除操作出现挂起问题该如何解决？

根因分析 #

首先可以明确：该问题不是fs模块的固有局限，核心是当前业务逻辑的并发设计缺陷，叠加系统IO瓶颈导致的：

• 无限制并发删除：你用Promise.all直接发起所有目录的删除任务，等于同时触发数十上百万次文件系统IO操作。Node.js底层依赖libuv线程池处理所有fs异步操作，默认线程池大小仅为4，大量IO任务会直接堵死线程池队列，导致应用所有后续IO相关操作都无法执行，表现为服务挂起。
• 系统IO过载：CentOS 7默认使用ext4文件系统与CFQ IO调度策略，同时删除多个包含大量小文件的1G目录会瞬间打满磁盘IOPS，系统IO等待占比飙升，所有磁盘操作都会被阻塞。
• 代码边界缺陷：你当前的deleteDirectory函数未处理传入路径不是目录的场景，该分支无返回值会导致Promise一直处于pending状态，也会卡住Promise.all的执行。

超时方案的作用 #

设置超时只能缓解部分场景的假死问题，无法彻底解决根因：
超时逻辑只能主动终止Node层面超时的删除任务，释放线程池资源，但已经提交到系统内核的删除IO请求仍会继续执行，仍会占用系统IO资源导致其他操作变慢。

实现方案 #

1. 超时逻辑封装 #

你可以用Promise.race封装异步任务的超时逻辑，示例代码如下：

/**
 * 为异步函数添加超时能力
 * @param {Function} asyncFn 要包装的异步函数
 * @param {Number} timeoutMs 超时时间，单位毫秒
 * @returns 包装后的带超时的异步函数
 */
const withTimeout = (asyncFn, timeoutMs = 30000) => {
  return async (...args) => {
    let timer;
    const timeoutPromise = new Promise((_, reject) => {
      timer = setTimeout(() => {
        reject(new Error(`删除操作超时，超时时间：${timeoutMs}ms`));
      }, timeoutMs);
    });

    try {
      const result = await Promise.race([asyncFn(...args), timeoutPromise]);
      return result;
    } finally {
      clearTimeout(timer);
    }
  };
};

// 给删除函数添加30秒超时
const deleteDirectoryWithTimeout = withTimeout(deleteDirectory, 30000);

2. 根本优化：控制删除并发数 #

最有效的解决方案是限制同时执行的删除任务数量，避免IO过载，你可以手动实现简单的并发控制器，无需引入第三方依赖：

/**
 * 并发控制器
 * @param {Number} concurrency 最大并发数，建议根据磁盘性能设置为2-4
 * @returns 限流函数，接收异步任务作为参数
 */
const limitConcurrency = (concurrency = 2) => {
  const taskQueue = [];
  let activeTaskCount = 0;

  const runNextTask = () => {
    activeTaskCount--;
    if (taskQueue.length > 0 && activeTaskCount < concurrency) {
      const { task, resolve, reject } = taskQueue.shift();
      activeTaskCount++;
      task().then(resolve, reject).finally(runNextTask);
    }
  };

  return (task) => {
    return new Promise((resolve, reject) => {
      if (activeTaskCount < concurrency) {
        activeTaskCount++;
        task().then(resolve, reject).finally(runNextTask);
      } else {
        taskQueue.push({ task, resolve, reject });
      }
    });
  };
};

// 初始化并发控制器，最多同时删2个目录
const deleteLimit = limitConcurrency(2);

// 改造cleanup函数
const cleanup = async (directories) => {
  // 原有参数校验逻辑保留
  if (!Array.isArray(directories)) {
    return await responseStatementHandler(
      400,
      `Provide a list of directories as an array - [dir1, dir2].`,
      null,
      console.error
    );
  }

  if (!(directories.length > 0)) {
    return await responseStatementHandler(
      400,
      `Directory list cannot be empty.`,
      null,
      console.error
    );
  }

  try {
    const promisesList = await Promise.all(
      directories.map(d => deleteLimit(() => deleteDirectoryWithTimeout(d)))
    );
    return await responseStatementHandler(
      207,
      promisesList,
      null,
      console.log
    );
  } catch (err) {
    return await responseStatementHandler(
      500,
      `Directory cleanup failed.`,
      err,
      console.error
    );
  }
};

3. 边界问题修复 #

补全deleteDirectory的非目录路径处理逻辑，避免Promise pending：

const deleteDirectory = async (directory) => {
  console.log(`Deleting directory: ${directory}`);
  try {
    const stat = await fs.stat(directory);
    if (stat.isDirectory()) {
      await fs.rm(directory, { recursive: true, force: true });
      return await generateIndividualResponseObj(
        directory,
        200,
        `Successfully deleted directory: ${directory}`,
        null,
        console.log
      );
    } else {
      return await generateIndividualResponseObj(
        directory,
        400,
        `Path is not a directory: ${directory}`,
        null,
        console.error
      );
    }
  } catch (err) {
    if (err.message.includes("no such file or directory")) {
      return await generateIndividualResponseObj(
        directory,
        404,
        `Could not find directory: ${directory}`,
        null,
        console.error
      );
    }
    return await generateIndividualResponseObj(
      directory,
      500,
      `Failed to delete directory: ${directory}`,
      err,
      console.error
    );
  }
};

额外优化建议 #

• 启动Node服务时设置环境变量UV_THREADPOOL_SIZE=8，提升libuv线程池大小，最大不要超过32，可提升fs操作的并发处理能力。
• CentOS 7系统可将磁盘IO调度策略修改为deadline，更适合高IOPS的删除场景，性能优于默认的CFQ策略。
• 条件允许的话可将数据盘的文件系统从ext4更换为xfs，删除大量小文件的性能可提升数倍。

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