Коротко — причина утечки: из‑за ленивости накапливаются неизчисленные отложенные вычисления (thunks), которые удерживают память (и, иногда, ссылки на большие структуры), поэтому сборщик мусора не может освободить кучу.
Почему так происходит (конкретнее)
- Thunk: выражение, ещё не вычисленное; при накоплении их цепочек память растёт.
- Частые шаблоны, вызывающие это:
- левосторонний негордый свёртка: `foldl (+) 0 xs` накапливает цепочку $(\dots ((0+x_1)+x_2)+\dots )$.
- ленивые поля в структурах — значения не форсятся и удерживают ссылки.
- ленивое I/O или большие списки, которые удерживаются из-за sharing (сохранённой ссылки на голову списка).
- Результат: много thunks → рост кучи → возможный OOM.
Как устранить (способы, с примерами)
- Использовать строгие свёртки:
- Вместо `foldl` брать `Data.List.foldl'`:
- `foldl' (+) $0$ xs`
- Или реализовать строго с bang‑паттернами:
- sum' :: Num a => [a] -> a
go !acc [] = acc
go !acc (x:xs) = go (acc + x) xs
sum' = go $0$ - Форсировать значение явно:
- с `seq` или `$!`:
- let acc' = acc + x in acc' `seq` go acc' xs
- f $! x -- форсирует x перед передачей в f
- Делать поля данных строгими, если нужно:
- data Pair = Pair !Int !Text
- Это убирает отложенные вычисления внутри структуры и уменьшает удержание памяти.
- Для глубоко вложенных структур — `deepseq` (или `NFData`) чтобы форсировать полностью, а не только верхний уровень.
- Использовать стриминг/итераторы вместо накопления списков:
- Conduit, pipes, streamly, streaming, или Data.Vector (unboxed) — они позволяют обрабатывать поток без хранения всей промежуточной структуры.
- Использовать строгие контейнеры:
- Data.Map.Strict / HashMap.Strict — значения и операции часто делают более строгими.
- Уменьшить sharing, если оно ведёт к удержанию больших структур:
- Не сохранять ссылку на начало большого списка, проходить по элементам без сохранения в замыкании.
- При необходимости — юзать примитивные/unboxed типы (Vector.Unboxed, Int#) для меньшего потребления и меньшего количества thunks.
- Компиляторные опции/расширения:
- включить оптимизации (`-O2`), `{-# LANGUAGE BangPatterns #-}`, `{-# LANGUAGE StrictData #-}` или `{-# LANGUAGE Strict #-}` (но применять с осторожностью).
Как диагностировать утечку
- Запустить программу с RTS‑статистикой (`+RTS -s`) — увидеть пиковое использование памяти.
- Для детальной диагностики использовать профилирование кучи (GHC профилирование): собрать с профайлером и анализировать профайл (heap profile) — позволит найти, какие значения удерживают память.
- Логически проверить подозрительные места: `foldl`, ленивые поля, ленивое I/O, накопление результатов в списке.
Краткие рекомендации по приоритету действий
- Если свёртка — замените `foldl` на `foldl'` или сделайте аккумулятор строгим.
- Если структура хранит много ленивых частей — сделайте поля строгими или примените `seq`/`deepseq`.
- Если вы храните большой поток в памяти — используйте стриминг (Conduit/Streaming) или обрабатывайте без сохранения списка.
- Профилируйте, если не очевидно, где удерживается память.
Если пришлёте конкретный фрагмент кода, покажу точечные правки.