Кратко: во всех трёх языках замыкание хранит ссылки на переменные окружения, но конкретная семантика (скоп/биндинг, момент привязки, время жизни) различается. Это даёт похожие классические проблемы — «все замыкания видят одно и то же изменяемое значение», удержание объектов в памяти и гонки при многопоточности — но поправки/поводы и способы решения разные.
Ниже — по языкам (поведение → типичные баги → исправления → утечки/параллелизм).
JavaScript (var / let / const)
- Семантика:
- `var` — функциональная (или глобальная) область видимости; переменная одна для всей функции. Замыкания захватывают саму переменную (по ссылке), поэтому все замыкания видят текущее значение переменной.
- `let`/`const` — блочная область видимости; в циклах ES6 компилятор/движок создаёт новую привязку для каждой итерации, поэтому каждая итерация имеет «свое» замыкание.
- `const` запрещает переназначение связывания, но объект, на который оно ссылается, может быть мутирован.
- Типичная проблема:
- С `var` в цикле все замыкания получают итоговое значение переменной (классический пример с `setTimeout` в цикле).
- Решения:
- Использовать `let`/`const` для блочной семантики.
- Или замыкать текущее значение через сразу вызываемую функцию (IIFE) или дополнительную функцию.
- Утечки памяти:
- Замыкание удерживает переменные/объекты в куче, пока существует ссылка на функцию. Если вы привязываете обработчики событий, таймеры или храните замыкание в долгоживущей структуре (например, глобальный слушатель), то большие объекты в окружении не будут собраны GC, пока не удалить ссылку/отписаться.
- Раньше в старых браузерах были специфические DOM-циклы-ссылки, но в современных движках GC справляется; всё равно нужно явно удалять слушатели.
- Параллелизм/конкурентность:
- JS однопоточный (за исключением Web Workers). Проблемы скорее асинхронные (таймеры/промисы): то, что код выполняется позже, означает, что замыкание прочитает актуальное значение переменной в момент выполнения — источник сюрпризов при использовании `var`.
Python
- Семантика:
- Замыкания захватывают переменные по имени (ссылка на объект через «cell»). Привязка значения фактически поздняя (late binding): при обращении берётся текущее значение переменной в момент вызова замыкания.
- Если нужно изменить связывание в замыкающей функции — использовать `nonlocal` (или `global`).
- Типичная проблема:
- В цикле несколько лямбд, ожидающих вызов, все будут возвращать одно и то же (последнее) значение переменной — «late binding».
- Решения:
- Замкнуть текущее значение через параметр со значением по умолчанию: `lambda x=i: x` — дефолт вычисляется в момент создания функции.
- Создать локальную копию внутри итерации.
- Утечки памяти:
- Замыкание удерживает объекты, на которые ссылаются переменные окружения. Python использует подсчёт ссылок плюс циклический GC; закрытия создают cell-объекты, которые участвуют в подсчёте ссылок.
- Возможна утечка, если возникает циклическая ссылка, особенно если в цикле есть объекты с `__del__` (GC может не удалить). Долговременные регистры обработчиков/колбэков также удерживают объекты.
- Параллелизм/конкурентность:
- GIL препятствует истинному параллельному выполнению байткода CPython, но потоки могут переключаться, и замыкания, захватившие изменяемое состояние, подвержены гонкам. Используйте блокировки/синхронизацию или multiprocessing для реального параллелизма.
C#
- Семантика:
- Лямбды/анонимные методы захватывают переменные окружения (не «значение» в момент создания, а саму переменную). Компилятор выносит захваченные локальные в генерируемый объект (display class); все делегаты, захватившие одну и ту же переменную, будут видеть её текущее значение.
- Поведение foreach: в старых версиях C# (до изменения) была известная проблема с foreach, где переменная цикла была общей; начиная с некоторых изменений (C# 5 для foreach на некоторых коллекциях) Microsoft исправляла поведение для foreach, но общее правило—внимательно смотреть версию и форму цикла.
- Типичная проблема:
- Замыкания в цикле — все делегаты используют одно и то же внешнее поле → неожиданные значения при позднем вызове; решение — создать локальную копию переменной внутри цикла: `var copy = i; action = () => Console.WriteLine(copy);`.
- Решения:
- Создавать новую локальную переменную в теле итерации (тем самым создаётся отдельное поле в display class).
- Утечки памяти:
- Захваченные переменные живут пока живёт объект-делегат. Частая утечка — подписка на события: если объект-подписчик передаёт делегат в долгоживущий издатель (publisher) и не отписывается, то подписчик и всё, что в нём захвачено, не будет собран GC.
- Поскольку захваченные переменные реализованы через heap-объект (display class), это может продлить время жизни больших структур/ресурсов.
- Параллелизм/конкурентность:
- C# многопоточен; замыкания не делают переменные потокобезопасными. Если несколько потоков используют/мутируют захваченное состояние, нужны синхронизация (lock/Interlocked/конкурентные коллекции). Асинхронные делегаты и продолжения (async/await) тоже могут выполнять код позже — те же проблемы «поздней привязки» возможны, если рассчитывали на иммутабельность.
Короткая шпаргалка по типовым паттернам/исправлениям
- Если ожидаете, что каждая итерация имеет своё значение, явно создавайте новую локальную переменную внутри итерации (JS: `let`, Python: `lambda x=i: x`, C#: `var copy = i`).
- Удаляйте обработчики/слушатели и обнуляйте долгоживущие ссылки, чтобы позволить GC освободить захваченные объекты.
- Для многопоточной среды синхронизируйте доступ к общему состоянию или избегайте захвата изменяемого состояния; используйте иммутабельные структуры, или локальные копии перед передачей в другой поток.
- Помните, что замыкание удерживает переменные в памяти до тех пор, пока существует самая «долговечная» ссылка на саму функцию/делегат/объект.
Вывод: семантика «замыкания захватывают переменные, а не значения» приблизительно верна для всех языков, но детали (scope/late-binding/блоковая привязка) отличаются: JS (`var` — проблемный, `let/const` — безопаснее), Python — late binding (решается default-параметром), C# — захват через display class (решается локальной копией). Утечки возникают при долгоживущих ссылках (обработчики, таймеры), а проблемы с параллелизмом — при совместном доступе к захваченному изменяемому состоянию без синхронизации.