Node.js同步异步I/O执行顺序解析

本篇文章向大家介绍《Node.js文件I/O：同步异步执行顺序详解》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

本文旨在解析Node.js中文件I/O操作的执行优先级问题，特别是异步`fs.readFile`与同步代码的交互。我们将通过一个典型的案例，深入分析为何异步操作会导致变量初始化顺序与预期不符，并提供两种核心解决方案：使用同步文件读取`fs.readFileSync`确保阻塞式初始化，或通过`fs.promises.readFile`结合`async/await`实现非阻塞的有序异步处理，帮助开发者正确管理Node.js应用的启动流程和数据加载。

在Node.js环境中，处理文件I/O是常见的任务。然而，由于Node.js的异步非阻塞特性，不当的文件读取方式可能导致代码执行顺序与开发者预期不符，尤其是在程序启动时需要初始化全局变量的场景。

Node.js异步I/O机制概述

Node.js基于事件循环（Event Loop）模型实现非阻塞I/O。这意味着当发起一个异步I/O操作（如文件读取、网络请求）时，Node.js不会等待该操作完成，而是立即将控制权返回给主线程，继续执行后续代码。当异步操作完成后，其回调函数会被放入事件队列，等待事件循环在主线程空闲时执行。

考虑以下代码示例，它尝试从cfg.json文件加载配置到serverAddr变量：

const fs = require('fs');

async function loadData() {
    fs.readFile('cfg.json', 'utf8', (err, data) => { // 异步操作
        if (err) {
            console.error(err);
            return;
        }
        const map = JSON.parse(data);
        console.log("1: " + serverAddr); // 此时serverAddr可能仍是旧值
        serverAddr = map.serverAddr;
        console.log("2: " + serverAddr); // 此时serverAddr已被更新
    });
    console.log("3: " + serverAddr); // 在fs.readFile回调执行前输出
    console.log("4: " + serverAddr); // 在fs.readFile回调执行前输出
}

var serverAddr = "NOT INIT";
console.log("5: " + serverAddr); // 最先输出
loadData();
console.log("6: " + serverAddr); // 在fs.readFile回调执行前输出

cfg.json文件内容：

{
    "serverAddr": "https://google.com/"
}

实际运行输出：

5: NOT INIT
3: NOT INIT
4: NOT INIT
6: NOT INIT
1: NOT INIT
2: https://google.com/

问题根源：fs.readFile的异步特性

从输出可以看出，console.log("1: ...") 和 console.log("2: ...") 这两行位于所有其他console.log之后才执行。这正是fs.readFile异步特性的体现：

1. console.log("5: NOT INIT") 首先执行。
2. loadData()函数被调用。
3. fs.readFile()被发起。这是一个异步操作，它将文件读取任务交给底层系统，并立即返回，不会阻塞当前函数的执行。
4. loadData()函数内部的 console.log("3: ...") 和 console.log("4: ...") 紧接着执行，此时文件尚未读取完毕，serverAddr变量依然是其初始值 "NOT INIT"。
5. loadData()函数执行完毕，控制权回到全局作用域。
6. 全局作用域的 console.log("6: ...") 执行，serverAddr仍然是 "NOT INIT"。
7. 当文件读取操作完成时（可能在主线程空闲后），fs.readFile的回调函数才会被事件循环调度执行。此时，console.log("1: ...") 和 console.log("2: ...") 才得以执行，并且在回调函数内部，serverAddr被更新为从文件中读取到的值。

关于await无效的说明： 示例中提到尝试在fs.readFile前添加await，但收到TS错误提示'await' has no effect on the type of this expression.ts(80007)。这是因为fs.readFile是一个基于回调（callback-based）的API，它不返回Promise对象。await关键字只能用于等待Promise对象的解析。如果需要使用async/await来处理异步文件I/O，需要使用Node.js提供的Promise-based API或者将回调式API进行Promise化。

解决方案一：使用同步文件读取 fs.readFileSync

如果应用程序在启动时必须先完成某些配置加载，并且可以接受短暂的阻塞，那么使用同步文件读取是一个简单直接的方案。fs.readFileSync会阻塞Node.js进程，直到文件完全读取并返回内容。

const fs = require('fs');

function loadDataSync() {
    try {
        const data = fs.readFileSync('cfg.json', 'utf8'); // 同步操作，会阻塞
        const map = JSON.parse(data);
        console.log("1: " + serverAddr); // 此时serverAddr仍是旧值（在函数外定义）
        serverAddr = map.serverAddr;
        console.log("2: " + serverAddr); // 此时serverAddr已被更新
    } catch (err) {
        console.error("Error reading config file synchronously:", err);
    }
}

var serverAddr = "NOT INIT";
console.log("5: " + serverAddr);
loadDataSync(); // 调用同步加载函数
console.log("3: " + serverAddr); // 在loadDataSync完成后执行
console.log("4: " + serverAddr); // 在loadDataSync完成后执行
console.log("6: " + serverAddr); // 在loadDataSync完成后执行

预期输出：

5: NOT INIT
1: NOT INIT
2: https://google.com/
3: https://google.com/
4: https://google.com/
6: https://google.com/

注意事项：

• 阻塞特性： fs.readFileSync会阻塞整个Node.js进程，直到文件读取完成。在服务器应用中，如果在请求处理过程中使用，可能导致服务器无法响应其他请求，造成性能瓶颈。因此，它主要适用于应用程序启动阶段的初始化工作。
• 错误处理： 同步API通常通过try...catch块来捕获错误。

解决方案二：正确处理异步操作 fs.promises.readFile (结合 async/await)

为了保持Node.js的非阻塞特性，同时又能以更线性的方式组织异步代码，推荐使用fs.promises模块提供的Promise-based API，并结合async/await语法。

const fs = require('fs').promises; // 引入fs的Promise版本

let serverAddr = "NOT INIT"; // 使用let更符合现代JavaScript实践

async function loadDataAsync() {
    try {
        console.log("3: " + serverAddr); // 在文件读取前输出
        const data = await fs.readFile('cfg.json', 'utf8'); // 等待Promise解析
        const map = JSON.parse(data);
        console.log("1: " + serverAddr); // 此时serverAddr仍是旧值
        serverAddr = map.serverAddr;
        console.log("2: " + serverAddr); // 此时serverAddr已被更新
        console.log("4: " + serverAddr); // 在文件读取后输出
    } catch (err) {
        console.error("Error reading config file asynchronously:", err);
    }
}

async function main() { // 定义一个async函数来封装顶层await
    console.log("5: " + serverAddr);
    await loadDataAsync(); // 等待loadDataAsync完成
    console.log("6: " + serverAddr); // 在loadDataAsync完成后执行
}

main(); // 调用主函数

预期输出：

5: NOT INIT
3: NOT INIT
1: NOT INIT
2: https://google.com/
4: https://google.com/
6: https://google.com/

注意事项：

• fs.promises： 引入fs.promises而非传统的fs模块，它提供了readFile等方法的Promise版本。
• await关键字： await只能在async函数内部使用。它会暂停async函数的执行，直到其后的Promise解决（resolved）或拒绝（rejected）。
• 顶层await： 在Node.js的最新版本中，模块的顶层await是支持的，但在某些旧版本或特定环境下可能需要将所有await操作封装在一个async函数中，再调用该async函数。
• 错误处理： async/await的错误处理通常通过try...catch块进行，可以捕获Promise链中的任何拒绝。

选择合适的I/O方式

• 启动初始化阶段（同步 fs.readFileSync）：

  • 优点： 代码简单直观，确保在程序逻辑开始执行前数据已完全加载。
  • 缺点： 阻塞主线程，可能导致启动时间略长，不适合在运行中频繁调用。
  • 适用场景： 应用程序启动时加载配置文件、环境变量等，这些数据是应用运行的先决条件。

• 运行时数据加载（异步 fs.promises.readFile 或 fs.readFile 回调）：

  • 优点： 非阻塞，保持Node.js的响应性，适合处理大量或耗时的I/O操作。
  • 缺点： 代码结构相对复杂（尤其是回调地狱），需要正确管理异步流程。
  • 适用场景： 处理用户请求、日志写入、数据库操作等，确保服务器在等待I/O时仍能处理其他任务。

总结

理解Node.js的异步执行模型是编写高效、响应式应用的关键。当遇到变量初始化顺序不符的“奇怪”行为时，首先应考虑是否存在异步操作未被正确等待。对于启动时的关键数据加载，可以选择fs.readFileSync以确保同步初始化；而在更通用的异步场景中，fs.promises.readFile结合async/await提供了更优雅、易读的解决方案，既保持了非阻塞特性，又避免了回调地狱。务必根据具体的业务需求和性能考量，选择最适合的文件I/O方法。

好了，本文到此结束，带大家了解了《Node.js同步异步I/O执行顺序解析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！