Космические утечки в Хаскеле

Question

Я много раз читал, что ленивая оценка в Хаскеле может иногда приводить к утечкам из космоса. Какой код может привести к утечке пространства? Как их обнаружить? И какие меры предосторожности могут быть приняты программистом, чтобы избежать их?

Answer 1

Вы получите, вероятно, много ответов, с этим я столкнулся при попытке сделать какое-то "реальное" приложение. Я использовал многопоточность и некоторые MVars для передачи данных (MVar - это что-то вроде заблокированной общей памяти). Мой типичный образец был:

a <- takeMVar mvar
putMVar mvar (a + 1)

А потом, просто иногда, когда случалось надлежащее состояние, я делал что-то вроде:

a <- takeMVar mvar
when (a > 10) ....

Проблема в том, что содержимое mvar было по существу (0 + 1 + 1 + 1 + ....)... которое было довольно интенсивным для чисел типа 100k... Этот тип проблемы был довольно распространенным в моем коде; к сожалению, для многопоточных приложений очень легко попасть в такие проблемы.

Обнаружение... то, что я сделал, запустило haskell в режиме, который выдает данные о потреблении памяти, запустил и остановил различные потоки и посмотрел, стабильно ли занимаемая память или нет...

Анотомия утечки звука (с инструкциями по ее устранению)

Пример: утечка памяти Thunk в результате функции карты

Answer 2

Я столкнулся с этой проблемой при выполнении рекурсии больших структур данных. Сложившихся громов становится слишком много, и тогда вы получаете космическую утечку.

В Haskell вы должны постоянно знать о возможности столкновения с космической утечкой. Поскольку итерации не существует, в принципе, любая рекурсивная функция может вызвать утечку пространства.

Чтобы избежать этой проблемы, запомните рекурсивные функции или перепишите их рекурсивно.