node.js - 对事件循环、多线程、Node.js 中 readFile() 的执行顺序有疑问？

Question

fs.readFile("./large.txt", "utf8", (err, data) => {
console.log('It is a large file') 

//this file has many words (11X MB). 
//It takes 1-2 seconds to finish reading (usually 1)

});

fs.readFile("./small.txt","utf8", (err, data) => {

for(let i=0; i<99999 ;i++)
console.log('It is a small file');

//This file has just one word. 
//It always takes 0 second
}); 

结果:

控制台总是会先打印“It is a small file” 99999 次(打印完成大约需要 3 秒)。
然后，在它们全部打印完后，控制台不会立即打印“这是一个大文件”。 (它总是在 1 或 2 秒后打印)。

我的想法:

因此，第一个 readFile() 和第二个 readFile() 函数似乎不是并行运行的。如果两个 readFile() 函数并行运行，那么我预计在“It is a small file”被打印 99999 次之后，
第一个 readFile() 提前完成读取(仅 1 秒)，控制台将立即打印出第一个 readFile() 的回调(即“这是一个大文件”。)

我的问题是:

(1a) 这是否意味着第一个 readFile() 只有在第二个 readFile() 的回调完成其工作后才会开始读取文件？

(1b) 据我了解，在 nodeJs 中，事件循环将 readFile() 传递给 Libuv 多线程。但是，我想知道它们是按什么顺序传递的。如果这两个 readFile() 函数不是并行运行的，为什么总是先执行第二个 readFile() 函数？

(2) 默认情况下，Libuv 有四个用于 Node.js 的线程。那么，在这里，这两个 readFile() 是否在同一个线程中运行？在这四个线程中，我不确定是否只有一个用于 readFile()。

非常感谢您抽出宝贵时间!欣赏!

Answer 1

我无法相信 Node 会延迟大文件读取，直到小文件读取的回调完成，因此我对您的示例进行了更多检测:

const fs = require('fs');

const readLarge = process.argv.includes('large');
const readSmall = process.argv.includes('small');

if (readLarge) {
    console.time('large');
    fs.readFile('./large.txt', 'utf8', (err, data) => {
        console.timeEnd('large');
        if (readSmall) {
            console.timeEnd('large (since busy wait)');
        }
    });
}

if (readSmall) {
    console.time('small');
    fs.readFile('./small.txt', 'utf8', (err, data) => {
        console.timeEnd('small');
        var stop = new Date().getTime();
        while(new Date().getTime() < stop + 3000) { ; } // busy wait
        console.time('large (since busy wait)');
    });
}

(请注意，我用 3 秒的忙等待替换了您的 console.logs 循环)。

在 node v8.15.0 上运行这个，我得到以下结果:

$ node t small # read small file only
small: 0.839ms
$ node t large # read large file only
large: 447.348ms
$ node t small large # read both files
small: 3.916ms
large: 3252.752ms
large (since busy wait): 247.632ms

这些结果看起来很正常；大文件需要大约 0.5 秒才能自行读取，但是当忙等待回调干扰 2 秒时，此后它相对较快(大约 1/4 秒)完成。调整忙等待的长度可以保持这种相对一致，所以我愿意说这是某种调度开销，并不一定表明大文件 I/O 在忙等待期间没有运行。

但后来我对 Node 10.16.3 运行了相同的程序，这就是我得到的:

$ node t small
small: 1.614ms
$ node t large
large: 1019.047ms
$ node t small large
small: 3.595ms
large: 4014.904ms
large (since busy wait): 1009.469ms

哎呀!不仅大文件读取时间增加了一倍多(约 1 秒)，而且在忙等待结束之前，似乎根本没有完成任何 I/O!即，看起来主线程中的繁忙等待确实阻止了大文件上发生任何 I/O。

我怀疑这种从 8.x 到 10.x 的变化是 Node 10 中这种“优化”的结果: https://github.com/nodejs/node/pull/17054 .这种将大文件的读取拆分为多个操作的更改似乎适合在通用情况下平滑系统的性能，但在这种情况下可能会因不自然的长主线程处理/忙等待而加剧。据推测，如果没有主线程让步，I/O 就没有机会前进到要读取的大文件中的下一个字节范围。

看起来，对于 Node 10.x，为了维持大文件的 I/O 性能，拥有一个响应式主线程(即，一个频繁产生，并且不会像本例中那样忙等待的主线程)很重要读。