Управление сборкой мусора

Есть два подхода к влиянию, когда выполняется очистка памяти. Они влияют на то, как часто выполняется автоматический процесс, а другой вручную запускает очистку.

Сборщиком мусора можно управлять, настраивая пороги сбора, которые влияют на частоту, с которой работает сборщик. Python использует систему управления памятью на основе поколения. Новые объекты сохраняются в новейшей генерации - generation0 и с каждыми выжили коллекции, объекты продвинут на старшие поколения. Не Достигнув последнего поколения - generation2, они больше не способствовали.

Пороговые значения можно изменить с помощью следующего фрагмента:

 import gc
gc.set_threshold(1000, 100, 10) # Values are just for demonstration purpose

 

Первый аргумент представляет собой пороговое значение для сбора generation0. Каждый раз , когда число отчислений превышает число deallocations на 1000 сборщик мусора будет называться.

Старшие поколения не очищаются при каждом запуске, чтобы оптимизировать процесс. Вторые и третьи аргументы не являются обязательными и контролировать , как часто моют старшие поколения. Если generation0 был обработан 100 раз без очистки generation1, то generation1 будет обработано. Аналогичным образом , объекты в generation2 будут обрабатываться только тогда , когда те , в generation1 были очищены в 10 раз , не касаясь generation2.

Один экземпляр , в котором установка вручную пороги полезно, когда программа выделяет много мелких объектов без deallocating их , что приводит к сборщик мусора работает слишком часто (каждый generation0_threshold объект распределения). Несмотря на то, что сборщик работает довольно быстро, при работе с огромным количеством объектов возникает проблема с производительностью. Во всяком случае, нет единого размера, подходящего для любой стратегии выбора пороговых значений, и это зависит от варианта использования.

Ручной запуск коллекции можно выполнить, как показано в следующем фрагменте:

 import gc
gc.collect()

 

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

Хотя это возможно, это не поощряемая практика. Избегать утечек памяти - лучший вариант. В любом случае, в больших проектах обнаружение утечки памяти может быть сложной задачей, и запуск сборки мусора вручную можно использовать как быстрое решение до дальнейшей отладки.

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