Коротко — проблема в том, что `async function f(){ await f(); }` создаёт бесконечную цепочку обещаний (Promises), которая не вызывает немедленного переполнения стека, но приводит к росту потребления памяти и возможной блокировке цикла событий.
Почему это плохо
- Вызов `f()` создаёт новый Promise; `await f()` приостанавливает текущую функцию и ставит продолжение в очередь микрозадач (Promise-job). Повторяя это без базового условия вы получаете бесконечную последовательность отложенных продолжений — куча (heap) заполняется объектами Promise и замыканиями → утечка памяти и в конце — OOM/crash.
- Одновременно такие цепочки микрозадач могут «забить» event loop: микрозадачи выполняются до опустошения очереди микрозадач и могут помешать выполнению макрозадач (таймеры, I/O).
Чем это отличается от синхронной рекурсии
- Синхронная рекурсия растёт по размеру call stack и при достижении глубины приведёт к RangeError (stack overflow).
- Асинхронная рекурсия с `await` НЕ наращивает стек вызовов (из‑за паузы и постановки продолжения в очередь), но наращивает число незавершённых Promise-объектов в памяти и может создать длинную цепочку микрозадач, что приводит к утечке памяти и/или блокировке исполнения других задач.
Как безопасно писать асинхронные рекурсивные алгоритмы
1. Всегда иметь базовый случай (условие выхода), проверять его до `await`.
Пример:
async function f(n) {
if (n <= 0) return;
// работа
await f(n - 1);
}
2. Для больших глубин заменять рекурсию на итерацию (явный стек/очередь).
Пример (DFS с явным стеком):
async function traverse(root) {
const stack = [root];
while (stack.length) {
const node = stack.pop();
// обработать node
for (const ch of node.children) stack.push(ch);
// периодически отдаём управление event loop, чтобы не заблокировать его:
if (stack.length % 1000 === 0) await new Promise(r => setImmediate(r));
}
}
Параметр порога в примере — $1000$ — подбирайте по задаче.
3. Разбивать работу на батчи и использовать macrotasks для «выпуска пара»:
await new Promise(resolve => setImmediate(resolve)); // делает паузу на макрозадачу
Не используйте process.nextTick для «паузы» — он ближе к микрозадачам и не даёт выгоды.
4. Ограничивать параллелизм/рекурсивную глубину: если запускаете много асинхронных подзадач, используйте семафор/конвейер (p-limit и т.п.).
5. Возвращать промис без await — осторожно: `return f();` приводит к синхронному вызову и может вызвать обычный стек‑overflow, поэтому используйте это только при уверенности в глубине.
Короткое резюме
- `await f()` без условия выхода не даёт stack overflow, но ведёт к накоплению Promise‑объектов и возможному OOM / блокировке event loop.
- Решения: базовый случай, итеративные алгоритмы с явным стеком/очередью, батчи + `setImmediate`/`setTimeout(…,0)` для разрыва цепочки микрозадач и управление параллелизмом.