Кратко: утечка памяти из‑за thunks возникает когда ленивые вычисления накапливают отложенные комбинаторы (thunks), удерживающие ссылку на промежуточные значения, мешая сборщику мусора. Это типично для наращивающихся аккумуляторов (left fold), ленивых полей и сложных отложенных структур.
Как это происходит (пример):
- При вычислении суммирования через `foldl` создаётся цепочка отложенных сложений
$((0+1)+2)+3+\dots$.
В KaTeX: $...((0+1)+2)+3+\dots$.
Каждое отложенное сложение — thunk, который хранит ссылку на предыдущие значения, поэтому память растёт.
Типичные сигналы: высокое использование памяти, профиль heap showing many thunks / large_retainer, GC не освобождает память.
Приёмы и строгая семантика, чтобы исправить
1) Использовать строгий аккумулятор
- Заменить `foldl` на `foldl'` из `Data.List`.
Пример:
code:
let s = foldl' (+) 0 xs
- Или писать рекурсию с жестким аккумулятором:
code:
let go !acc (y:ys) = go (acc + y) ys
go acc [] = acc
2) Bang patterns и строгие поля
- Включить `{ -# LANGUAGE BangPatterns #-}` и писать `!x` в аргументах/паттернах.
- Для полей данных:
code:
data Person = Person { age :: !Int, name :: String }
- Включить `StrictData` или использовать `!` для конкретных полей.
3) seq, $! и evaluate / deep forcing
- Принудительно принудить вычисление до WHNF: `x \`seq\` rest` или `f $! arg`.
- Для полного разворачивания (до NF) использовать `deepseq` / `force` / `rnf` (из `Control.DeepSeq`):
code:
import Control.DeepSeq (force)
result <- evaluate (force bigStructure)
4) UNPACK и примитивные/неупакованные типы
- Для числовых полей использовать `{-# UNPACK #-} !Int` и строгие неопакованные поля, чтобы уменьшить аллокации и thunks.
- Использовать `Data.Vector.Unboxed` / `primitive` / `unboxed` типы для интенсивных числовых расчётов.
5) Использовать строгие структуры и их версии функций
- `Map.Strict`, `HashMap.Strict`, `sequence`/`traverse` strict версии, `foldl'`, `Text`/`ByteString` strict варианты, и т.д.
6) Избегать ленивого построения больших промежуточных структур
- Предпочитать streaming / conduit / pipes / vector fusion, либо строить и потреблять поток строго.
- Не хранить большие ленивые списки как CAFы (top-level lazy values).
7) Профилирование и диагностика
- Запускать GHC RTS и профайлер: `+RTS -s`, `+RTS -h` и GHC профайлер (`-prof`, `-fprof-auto`) чтобы найти ретейнеры и thunks.
- Смотреть retainer graph и cost-centres, чтобы видеть что удерживает память.
8) Осторожно с семантикой
- Жёсткость меняет поведение при ошибках/бесконечных вычислениях (может заставить бросить исключение или зациклиться), поэтому тестируйте.
Короткий свод действий при утечке:
- Найти место накопления через профайлер.
- Если это аккумулятор — заменить на `foldl'` / строгую рекурсию (`!acc`) или принудить `seq`.
- Для сложных структур — заставить их NF через `deepseq` или сделать поля строгими/UNPACK.
- Для числовой нагрузки — использовать unboxed векторы / примитивы.
Если нужно, могу показать минимальные примеры «плохо / хорошо» с кодом и объяснить профиль — пришлите проблемный фрагмент.