Libgc собирает мусор по алгоритму mark and sweep…
Sumo 06.12.2022 19:54
/ 06.12.2022 20:02
В отличии от простого счетчика ссылок он может собирать группы объектов, которые имеют взаимные ссылки, но ни один из которых недоступен из корневых объектов. Своеобразный остров.
Универсального способа бороться с утечками памяти нет. Чем больше у вас неявных выделений объектов, чем более запутана структура объектов, тем больше вероятность, что вы выстрелите себе в ногу и будете безвозвратно терять память.
Я для себя выбрал следующий подход: минимум переменных в MAIN; никаких статических классов и методов — только динамическое создание классов с конструкторами; никаких ормов в стиле эктив-рекорд — работаем только с таблицами и хешами, а орм не более чем навороченный генератор запросов; явная сборка мусора в больших циклах в шаблонах. И ничего никогда не течет. ;)
p.s. Без кода обсуждать очень тяжело. Если бы вы открыли код своего фреймворка с ормами, то можно было бы посмотреть и что-то конкретное сказать. Сейчас мы ведем очень теоретические рассуждения, которые приведут к совету разобраться как работают сборщики мусора. Сомнительно, что такой совет окажется полезным.
