如何通过C++ Node-Addon-API实现真正异步返回？及AsyncWorker相关问询

我需要通过Node-Addon-API调用C++库启动外部硬件进程，该进程运行时长不确定，由独立于Node的库线程处理。进程完成后，希望执行发起调用对象的JavaScript回调。找到的示例代码如下：

#include <napi.h>

class MyAsyncWorker;
MyAsyncWorker *gAsyncWorker{};
bool gDelete;

class MyAsyncWorker : public Napi::AsyncWorker {
    int work_units{0};
public:
    MyAsyncWorker(Napi::Function& callback)
    : Napi::AsyncWorker(callback)
    {}
    void DoWork() { // called by library thread
        ++work_units;
    }
    void Execute() override { // called by a Node thread?
        while (!gDelete) {
            if (work_units > 50) {
                OnOK();
                gDelete = true;
            } else { using namespace std::chrono_literals;
                std::this_thread::sleep_for(10ms);
            }
        }
    }
    void OnOK() override {
        Napi::HandleScope scope(Env());
        Callback().Call({Env().Undefined()});
    }
};

Napi::Value JS_start_async_worker(const Napi::CallbackInfo& info)
{
    Napi::Env env = info.Env();
    Napi::Function callback = info[0].As<Napi::Function>();
    gAsyncWorker = new MyAsyncWorker(callback);
    gAsyncWorker->Queue();
    return env.Undefined();
}

bool hardware_has_data() {  return std::rand() < 0.01; }

void library_thread() {
    while(true) {
        if (!gDelete) {
            if(gAsyncWorker && hardware_has_data())
                gAsyncWorker->DoWork();
        } else {
            delete gAsyncWorker;
            gAsyncWorker = nullptr;
            gDelete = false;
        }
    }
}
std::thread l(library_thread);

Napi::Object Init(Napi::Env env, Napi::Object exports) {
    exports.Set(Napi::String::New(env, "start_async_worker"), Napi::Function::New(env, JS_start_async_worker));
    return exports;
}

NODE_API_MODULE(addon, Init)

免责声明：请忽略示例中粗糙的线程原语（实际无任何线程原语），仅为简化示例而编写。

对应的JavaScript代码：

someObject.start_async_worker(()=>{ console.log("done"); });

问题 #

关于示例中MyAsyncWorker的生命周期及Node下线程安全的相关实现是否合法，我有三个疑问：

1. 是否允许创建如示例中全局生命周期的AsyncWorker？会导致问题吗？
2. 据我理解，调用->Queue()后，Node会为AsyncWorker::Execute()创建额外线程。但若有成千上万个此类异步任务，如何减轻Node的线程负担？因为库无需为每个任务单独创建线程。
3. 如何正确销毁AsyncWorker对象？

解答 #

1. 全局生命周期AsyncWorker的合法性与问题 #

允许创建全局的AsyncWorker，但绝对不推荐，会引发一系列严重问题：

• 无法处理并发任务：全局指针只能同时绑定一个AsyncWorker，多次调用start_async_worker会直接覆盖旧对象，导致旧任务的回调永远无法触发，还会造成内存泄漏。
• 线程安全隐患：示例中无任何同步机制，库线程和Node线程同时读写gAsyncWorker、gDelete这些全局变量，极易出现竞态条件——比如库线程刚要调用DoWork()，Node线程已经把指针置空，直接触发程序崩溃。
• 上下文绑定风险：AsyncWorker的Env和Callback都和创建时的Node上下文绑定，如果全局对象长期存在，一旦对应的JS上下文被销毁（比如模块卸载），后续调用回调会触发非法内存访问。

2. 减轻大量异步任务的Node线程负担 #

你的理解是对的，AsyncWorker::Queue()默认会将任务放入Node的线程池执行（线程池默认大小为4，可通过UV_THREADPOOL_SIZE调整），但上万个任务会直接占满线程池，而你的场景里库已有独立线程，完全不需要Node额外创建线程。

正确的优化思路是：

• 砍掉Execute()里的轮询逻辑，AsyncWorker仅用来持有回调和Node环境。
• 当库线程检测到硬件任务完成时，直接通过Node的线程安全API将回调调度到Node事件循环执行，推荐用Napi::ThreadSafeFunction——这是专门为跨线程JS回调设计的API，支持复用，不用为每个任务创建新的AsyncWorker，能大幅降低线程开销。
• 如果是批量任务，可以合并多个硬件事件的回调请求，进一步减少调度次数。

3. AsyncWorker的正确销毁方式 #

AsyncWorker的销毁必须遵循Node-Addon-API的规则，不能随意手动delete：

• 如果用AsyncWorker的默认流程（Queue()后自动执行Execute()和OnOK()/OnError()），AsyncWorker会在OnOK()或OnError()执行完成后自动销毁（默认是DeleteOnExit模式）。
• 如果是自定义流程需要手动管理：
  1. 销毁操作必须在Node线程执行（不能在库线程直接delete，因为AsyncWorker持有Node环境对象，非Node线程操作会触发安全问题）。
  2. 在OnOK()或回调执行完成后，调用this->Destroy()，或者通过SetCleanupHook设置清理逻辑。
  3. 绝对禁止在库线程直接delete AsyncWorker，必须通过Node事件循环调度到Node线程执行销毁。

如果改用Napi::ThreadSafeFunction，销毁逻辑会更清晰：所有任务完成后调用Release()，最后调用Abort()清理资源即可。

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