Стек
- Что: память с LIFO-организацией под локальные переменные и вызовы функций (каждый вызов — фрейм со служебной информацией, return‑адресом, локалами).
- Свойства: область фиксированного/ограниченного размера, автоматически выделяется/освобождается при входе/выходе из функций, быстрый доступ по адресу (контролируется указателем стека).
- Производительность/сопряжённость: выделение/освобождение — константное время $O(1)$. Не подходит для объектов с динамическим временем жизни или большого размера.
Куча
- Что: глобальная область для динамических объектов (распространяется между потоками в большинстве реализации).
- Свойства: гибкая длительность жизни объектов, аллокация/деаллокация выполняется явно (в С/C++) или сборщиком мусора (в Java/C#). Поддерживает объекты переменного размера.
- Производительность: средняя аллокация обычно $O(1)$ (с фрагментацией или сложной политикой — возможны хуже случаи до $O(n)$). Возможна фрагментация, конкуренция между потоками, необходимость синхронизации или локальных кэшей.
Как в управляемых языках (Java, C#) возникают утечки памяти
- Модель: GC освобождает только недостижимые объекты; «утечка» — когда объекты остаются достижимыми, но больше не нужны.
- Частые причины:
- Длительно живущие ссылки: статические коллекции, кэш‑мапы, глобальные списки, пулы, которые не очищаются.
- Обработчики/слушатели и подписки: не отписались — объект остаётся достижимым.
- Замыкания и анонимные классы: непреднамеренное сохранение ссылки на внешний объект.
- Неправильное использование слабых ссылок: ожидание очистки через WeakReference, но держат сильную ссылку где‑то ещё.
- Нативные ресурсы: забытые дескрипторы/память в native code (JNI) или неосвобождённые ресурсы; финализаторы/ращеpы работают недетерминированно.
- Пулы объектов, буферы или очереди, которые растут без контроля.
- Как обнаружить: профайлеры памяти, дампы heap, анализ путей достижимости, метрики роста используемой памяти.
Как предотвратить/исправлять утечки (Java/C#)
- Отписка от событий, удаление из коллекций, закрытие/Dispose/using для ресурсов.
- Использование WeakReference/WeakHashMap для кэшей, где допустима автоматическая очистка.
- Минимизировать статические коллекции, ограничивать размеры кэшей (LRU, TTL).
- Явное управление нативными ресурсами (try/finally, using, SafeHandle).
- Инструменты: профайлеры (heap dump), анализатор утечек.
Фрагментация кучи в системах реального времени — что делать
- Проблема: фрагментация усложняет предсказуемую аллокацию/деаллокацию; компактирующие GC могут мигрировать объекты, но вводят непредсказуемые паузы.
- Стратегии для RT-систем:
- Избежать динамических аллокаций во время работы в реальном‑временном контексте: выделить всё заранее (preallocation).
- Использовать пулы фиксированных блоков (memory pools / object pools / slab allocator): выделение/освобождение детерминированы, минимальная фрагментация.
- Регионная/аренная аллокация (arena/region): быстрый массовый сброс всех объектов арены, не требует поиска свободных блоков.
- Сегрегированные свободные списки по размерам (size‑segregated free lists) для уменьшения фрагментации и ускорения аллокации.
- Buddy allocator с контролируемой фрагментацией (с учётом trade‑off в плотности).
- Отдельные пуллы для больших объектов (Large Object Heap) чтобы они не фрагментировали основную кучу.
- Использовать реал‑таймные/инкрементные сборщики: специализированные RT‑JVM или GC с гарантиями пауз (RTSJ, Real‑time Java, или коммерческие решения); в .NET — профили и GC‑режимы (хотя традиционный .NET GC не рассчитан на жесткое RT).
- Минимизировать перемещение/фиксацию объектов (pinning) и избегать частых аллокаций/деаллокаций малого размера.
- Планирование и валидация: проводить анализ WCET и стресс‑тесты поведения памяти, измерять фрагментацию и латентности под нагрузкой.
- Компромисс: компактирующий GC решает фрагментацию, но может нарушать жёсткие временные требования; поэтому в RT лучше комбинация предвыделения, пулов и детерминированных аллокаторов либо использование специального RT‑GC с гарантиями.
Краткий итог
- Стек = быстрый, LIFO, автоматический; куча = гибкая, динамическая, подвержена фрагментации.
- В управляемых языках утечки — из‑за достижимых, но ненужных ссылок и нативных ресурсов; решается очисткой ссылок, слабые ссылки, корректным освобождением ресурсов и профайлингом.
- В реальном времени предпочтительны предвыделение, пулы, арены и детерминированные аллокаторы; при необходимости — RT‑GC или тщательно настроенные стратегии разделения памяти.