Кратко: в языках с явным управлением памятью (C) программист сам выделяет и освобождает память; в языках с неявным управлением (JavaScript) за это отвечает сборщик мусора (GC). Это порождает разные классы ошибок, разные требования к отладке и разные компромиссы по производительности.
1) Отладка
- C:
- Ошибки часто проявляются немедленно (crash, сегфолт) или как коррумпированные данные — use-after-free, double-free, buffer overflow.
- Инструменты: gdb, Valgrind, AddressSanitizer, LeakSanitizer. Они дают детальные трассы выделений/освобождений.
- Проблема: локализация источника ошибки может быть сложна — коромпция памяти проявляется позже.
- JavaScript:
- Ошибки с памятью обычно проявляются как постепенно растущее потребление памяти или "out of memory" в долгих процессах; crashes реже.
- Инструменты: Chrome DevTools / Node --inspect, heap snapshots, allocation sampling, профилировщики GC.
- Проблема: GC скрывает большинство мелких ошибок, поэтому нужно снимать снимки кучи и сравнивать, искать удерживаемые корни.
2) Производительность
- C (явная):
- Более предсказуемая латентность: освобождение происходит синхронно; можно оптимизировать под конкретные паттерны.
- Меньшие накладные расходы при высокочастотных аллокациях, если использовать пул/арены.
- Риски: фрагментация кучи, ручная оптимизация сложна.
- JavaScript (неявная, GC):
- Выгодно массово аллоцировать короткоживущие объекты (генерационная GC). Частые аллокации дешёвы, но сборки могут вызывать паузы/латентность.
- Производительность зависит от реализации GC (пропускная способность vs паузы). Можно уменьшать задержки через оптимизацию аллокаций (избегать удержания больших объектов).
- Современные движки делают escape analysis, оптимизации: в горячих путях JS-инстансы могут оптимизироваться.
3) Утечки памяти — как возникают
- C:
- Прямая утечка: выделили память, забыли вызвать free — память никогда не вернётся.
- Фрагментация/утечки через потерю указателя на блок.
- Инструменты обнаружения: LeakSanitizer, Valgrind.
- Пример (типичная ошибка):
- `char *p = malloc($100$); /* используем */ /* забыли free(p); */`
- JavaScript:
- GC не убирает объекты, на которые есть ссылки из корней (глобальные переменные, замыкания, таймеры, обработчики событий, структуры данных).
- Утечки часто логические: "невыпавшие" ссылки, detached DOM nodes, незакрытые таймеры.
- Инструменты: heap snapshots, retained size, object retainer paths.
- Пример (типичная ошибка):
- Замыкание удерживает большой массив:
- `function factory() { const big = new Array($1000000$); return () => big; }` — если возвращаемая функция живёт долго, `big` не GC.
4) Типичные ошибки и короткие примечания по их решению
- C:
1. Use-after-free: `free(p); /* потом используем p */` — проявляется как UB; решать: устанавливать `p = NULL` после free, проверять доступы.
2. Double-free: дважды вызвать `free(p)` — crash; решать: обнулять указатель и строгий ownership (RAII в C++).
3. Buffer overflow: `char buf[$10$]; strcpy(buf, user_input);` — коррумпция стека/кучи; решать: bounds checking, strncpy, безопасные библиотеки.
4. Забытая free (утечка): повторно использовать пулы, статический анализ, автоматизация проверки (asan/lsan).
- JavaScript:
1. Удержание через глобальные переменные: `window.cache = bigObj;` — решать: очищать cache, использовать локальные области или WeakMap.
2. Замыкание над большим объектом: callback хранит ссылку на большой контекст — решать: разрывать ссылки, пересоздавать мелкие структуры, использовать WeakRef/WeakMap там, где возможно.
3. Забытие очистки таймеров/обработчиков: `setInterval` без `clearInterval`, `addEventListener` без удаления — решать: привязывать жизненный цикл, использовать once или dispose.
4. Detached DOM nodes: хранение ссылок на элементы, удалённые из документа — решать: удалять ссылки или использовать weak refs в среде, где они поддерживаются.

5) Практические рекомендации
- Для C: придерживаться дисциплины ownership, использовать RAII (в C++), минимизировать время жизни, применять sanitizers и статический анализ.
- Для JS: профилировать heap snapshots, избегать глобальных состояний, использовать WeakMap/WeakRef для кэшей, внимательно управлять жизненным циклом слушателей и таймеров.
- В обоих: писать модульные тесты, стресс-тесты на память и профилировать реальное поведение под нагрузкой.
Короткое резюме: C даёт контроль и предсказуемость, но требует строгой дисциплины (частые критические ошибки и утечки низкого уровня); JavaScript скрывает многие ошибки, облегчая разработку, но логические утечки и GC-латентности требуют профилирования и контроля ссылок.