本文详解 EventEmitter 中 on() 事件重复执行的根本原因，指出未清理监听器导致的“一次 emit 触发多次 resolve”问题，并提供使用 once()、手动移除监听器及异步资源管理的最佳实践。
本文详解 eventemitter 中 `on()` 事件重复执行的根本原因，指出未清理监听器导致的“一次 emit 触发多次 resolve”问题，并提供使用 `once()`、手动移除监听器及异步资源管理的最佳实践。
在 Node.js（包括 VS Code 扩展这类非浏览器环境）中，EventEmitter 的 .on() 方法会永久注册监听器——只要事件被触发，所有已注册的监听器都会依次执行，且不会自动销毁。这正是你遇到“event.on() 触发两次”的核心原因：当多个 getSession() 调用先后执行到 this.event.on("available", resolve) 时，它们各自向同一个 EventEmitter 实例添加了独立的监听器；而后续一次 this.event.emit("available") 会同步通知所有未移除的监听器，导致多个 Promise 同时被 resolve，甚至引发对已占用资源的重复访问或索引越界（如 index === -1 错误）。
更严重的是，这些监听器一旦注册便持续存在，造成内存泄漏和逻辑污染——即使 Promise 已完成，监听器仍驻留在事件队列中，下次 emit("available") 时仍会被调用。
✅ 正确做法是：确保每个异步等待只响应一次事件，并在响应后立即清理监听器。推荐两种安全方案：
方案一：使用 once()（最简洁可靠）
public async getSession(sessionName: string) {
let index = this.sessionArray.findIndex(
(a) => a.sessionName === sessionName && !a.inUse
);
if (index === -1) {
// 使用 once()：仅响应下一次 emit，且自动移除监听器
await new Promise<void>((resolve) => {
this.event.once("available", () => resolve());
});
// 重新查找（此时 session 应已释放）
index = this.sessionArray.findIndex(
(a) => a.sessionName === sessionName && !a.inUse
);
// ⚠️ 增强健壮性：检查是否仍无可用项（如并发竞争或逻辑异常）
if (index === -1) {
throw new Error(`No available session named "${sessionName}" after 'available' event.`);
}
}
this.sessionArray[index].inUse = true;
return { session: this.sessionArray[index], id: index };
}</void>
方案二：手动 on() + removeListener()（显式控制）
public async getSession(sessionName: string) {
let index = this.sessionArray.findIndex(
(a) => a.sessionName === sessionName && !a.inUse
);
if (index === -1) {
const listener = () => {
// 移除自身，防止重复触发
this.event.removeListener("available", listener);
resolve();
};
await new Promise<void>((resolve) => {
this.event.on("available", listener);
});
index = this.sessionArray.findIndex(
(a) => a.sessionName === sessionName && !a.inUse
);
if (index === -1) {
throw new Error(`Session "${sessionName}" still unavailable after 'available' event.`);
}
}
this.sessionArray[index].inUse = true;
return { session: this.sessionArray[index], id: index };
}</void>
补充建议
- 避免全局共享 EventEmitter 实例用于状态协调：若 SessionManager 是单例，当前设计可行；但需确保 freeSession() 调用时机准确（例如在业务逻辑真正完成释放后），否则可能提前触发 emit 导致竞态。
- 考虑改用 Promise 队列或信号量（Semaphore）：对于复杂资源池场景，可引入 p-limit 或自定义队列机制，比事件驱动更可控。
- 单元测试覆盖并发路径：模拟多个 getSession() 并发调用 + 单次 freeSession()，验证是否仅一个 Promise 被 resolve。
总结：EventEmitter.on() 不是“等待一次”的语义，而是“持续监听”；务必用 once() 或显式清理，才能保证异步等待的原子性与可预测性。
