javascript - 对于 node.js 中的本地文件，我应该使用异步文件 IO 方法而不是它们的同步等效方法吗？

Question

我有一个非常简单的实用程序脚本，它是用 JavaScript 为 node.js 编写的，它读取一个文件，进行一些计算，然后写入一个输出文件。当前形式的来源看起来像这样:

fs.readFile(inputPath, function (err, data) {
    if (err) throw err;
    // do something with the data
    fs.writeFile(outputPath, output, function (err) {
        if (err) throw err;
        console.log("File successfully written.");
    });
});

这工作正常，但我想知道在这种情况下使用这些函数的同步变化是否有任何缺点，如下所示:

var data = fs.readFileSync(inputPath);
// do something with the data
fs.writeFileSync(outputPath, output);
console.log("File successfully written.");

对我来说，这比回调变体更容易阅读和理解。在这种情况下是否有任何理由使用前一种方法？

我意识到对于我在本地运行的这个简单脚本，速度根本不是问题，但我有兴趣了解它背后的理论。什么时候使用异步方法有帮助，什么时候没有帮助？即使在生产应用程序中，如果我只是读取一个文件，然后等待执行下一个任务，是否有任何理由使用异步方法？

Answer 1

重要的是在同步 IO 发生时您的 Node 进程还需要做什么。对于由单个用户在命令行运行的简单 shell 脚本，同步 IO 完全没问题，因为如果您正在执行异步 IO，您要做的就是等待 IO 返回。

但是，在具有多个用户的网络服务中，您永远不能使用任何同步 IO 调用(这是 Node 的全部要点，所以当我这么说时请相信我)。这样做会导致所有连接的客户端停止处理，这是彻底的厄运。

经验法则:shell 脚本:好的，网络服务:verboten!

为了进一步阅读，我在 this answer 中做了几个类比.

基本上，当 Node 在网络服务器中进行异步 IO 时，它可以要求 OS 做很多事情:读取一些文件，进行一些数据库查询，发送一些网络流量，同时等待异步 IO 被准备好了，它可以在主事件线程中处理内存/CPU 的事情。使用这种架构， Node 获得了非常好的性能/并发性。但是，当发生同步 IO 操作时，整个 Node 进程只是阻塞并且什么都不做。它只是等待。无法接收新连接。没有处理发生，没有事件循环滴答，没有回调，什么都没有。仅 1 个同步操作就会使所有客户端的整个服务器停止运行。你绝对不能这样做。它有多快或类似的东西并不重要。本地文件系统或网络请求无关紧要。即使您为每个客户端花费 10 毫秒从磁盘读取一个小文件，如果您有 100 个客户端，客户端 100 将等待整整一秒，同时为客户端 1-99 一次又一次地读取一个文件。