Коротко: утечки event listeners возникают, когда вы добавляете слушатели и не снимаете их (или не используете once), из‑за чего замыкания слушателей удерживают объекты в памяти. Диагностика — смотреть предупреждения Node, считать слушателей и делать heap‑снапшоты; исправление — удалять слушатели, использовать `once` или аккуратно управлять временем жизни.
1) Пример с утечкой (синтетика)
```js
const EventEmitter = require('events');
const emitter = new EventEmitter();
// Асинхронная операция, вызываемая много раз — при каждой итерации добавляем слушатель
async function doWork(iteration) {
// Большой объект, который попадает в замыкание слушателя
const bigObj = Buffer.alloc(10 * 1024 * 1024); // ~10MB
// Ошибка: добавляем новый listener на каждую итерацию, не удаляем
emitter.on('result', () => {
// замыкание удерживает bigObj
console.log('result for', iteration, bigObj[0]);
});
// симулируем асинхронную работу
await new Promise(r => setTimeout(r, 10));
emitter.emit('result');
}
(async () => {
for (let i = 0; i < 1000; i++) {
await doWork(i);
// память будет расти, т.к. слушатели накапливаются
}
})();
```
Почему это утечка: каждый вызов `doWork` добавляет новый callback в список слушателей `result`. Этот callback закрывает `bigObj`, поэтому сборщик мусора не может освободить `bigObj`. Количество слушателей растёт, и с ними — удерживаемая память.
2) Диагностика
- Node выдаёт предупреждение, когда слушателей стало много: `MaxListenersExceededWarning` (по умолчанию порог $‘10‘$). Включите `--trace-warnings`, чтобы увидеть стек.
- Программно:
- `emitter.listenerCount('result')` — число слушателей.
- `emitter.listeners('result')` — сами слушатели (для анализа).
- Профилирование памяти:
- Запустить Node с `--inspect` и сделать heap snapshot в Chrome DevTools, искать retained objects и замыкания функций.
- Использовать `heapdump` или `clinic --inspect`/`clinic heap`/`clinic flame`.
- Мониторинг:
- `process.memoryUsage()` периодически — наблюдать рост RSS/heap.
- Инструменты типа `0x`, `clinic` помогут найти горячие места.
3) Фикс — удалять слушатели или использовать once
Вариант 1: `once` (если слушатель нужен один раз)
```js
// заменяем on → once, listener автоматически снимается после первого вызова
emitter.once('result', () => {
console.log('one-time result', iteration);
});
```
Вариант 2: вручную удалять слушатель
```js
function doWork(iteration) {
const bigObj = Buffer.alloc(10 * 1024 * 1024);
const listener = () => {
console.log('result for', iteration);
emitter.removeListener('result', listener); // снимаем после использования
};
emitter.on('result', listener);
}
```
Вариант 3: использовать scoped/EventEmitter per task или поток сообщений
- Создавать отдельный `EventEmitter` для задачи, или использовать промисы/async iterators вместо глобальных эмиттеров.
```js
// вместо глобального emitter — вернуть промис
function doWorkAsync(iteration) {
const bigObj = Buffer.alloc(10 * 1024 * 1024);
return new Promise(resolve => {
const listener = () => {
emitter.removeListener('result', listener);
resolve(bigObj);
};
emitter.on('result', listener);
});
}
```
4) Почему слушатели приводят к росту памяти — простая модель
- Пусть при каждой итерации добавляется по $n$ новых слушателей, каждый слушатель удерживает в замыкании в среднем $s$ байт полезной информации. Тогда прирост удерживаемой памяти за одну итерацию:
$$\Delta M=n\cdot s$$ - После $t$ итераций суммарная дополнительная память:
$$M(t)=M_0+t\cdot n\cdot s$$ Если слушатели не удаляются, $t$ растёт и память растёт линейно (или быстрее, если слушатели создают дополнительные объекты).
5) Практические рекомендации
- Используйте `emitter.once` для одноразовых ответов.
- Если слушатель должен жить ограниченное время — явно `removeListener`/`off`.
- Не храните большие объекты в замыканиях слушателей; держите только необходимые идентификаторы и освобождайте ресурсы.
- Следите за `emitter.listenerCount(event)` и включайте предупреждения.
- Профилируйте heap при подозрении на утечку (heap snapshot, retained size).
- Установите разумный `EventEmitter.defaultMaxListeners = X` или локально `emitter.setMaxListeners(n)` чтобы ловить аномалии раньше.
Если нужно, могу показать код диагностики (скрипт, который по таймеру логирует `process.memoryUsage()` и `emitter.listenerCount(...)`) или пример heap‑snapshot анализа.