Эта статья иллюстрирует механизм сборки мусора PHP. Поделитесь для вашей справки следующим образом:
I. Концепция
Механизм сбора мусора представляет собой динамическую схему распределения хранилища. Он автоматически освобождает выделенные блоки памяти, которые больше не нужны программе. Механизм сбора мусора позволяет программистам уделять больше энергии бизнес-логике без чрезмерной заботы о выделении памяти программы. Среди популярных языков в настоящее время механизм сбора мусора является общей особенностью языков нового поколения, таких как Python, PHP, C#, Ruby и так далее.
II. PHP Механизм Переработки Мусора
1. До PHP 5.3 используемый механизм сбора мусора был просто “подсчетом ссылок”. А именно: (1) Каждому объекту памяти присваивается счетчик. Когда на объект памяти ссылается переменная, счетчик + 1; (2) Когда ссылка на переменную удаляется (после снятия (), счетчик-1; (3) Когда, это указывает, что объект памяти не используется, объект памяти уничтожается и сборка мусора завершена. И PHP выпускает содержимое процесса/потока после окончания жизненного цикла, что определяет, что PHP не нужно слишком много думать об утечках памяти на ранней стадии.
Однако, когда два или более объекта ссылаются друг на друга, образуя кольцо, счетчик объекта памяти не будет уменьшен до 0; в это время эта группа объектов памяти бесполезна, но не может быть восстановлена, что приводит к утечке памяти. Php5.3 начался с нового механизма сбора мусора. На основе подсчета ссылок был реализован сложный алгоритм для обнаружения наличия колец ссылок в объектах памяти, чтобы избежать утечек памяти.
2. С развитием PHP, увеличением числа разработчиков PHP и расширением сферы их деятельности в PHP 5.3 внедряется более совершенный механизм сбора мусора. Новый механизм сбора мусора решает проблему утечки справочной памяти, которая не может справиться с циклом.
Как говорится в официальном документе, каждая переменная PHP существует в контейнере переменных, называемых “zval”. Контейнер переменной zval содержит два байта дополнительной информации в дополнение к типу и значению переменной. Первый – “is_ref”, значение bool, которое определяет, принадлежит ли переменная к ссылочному набору. С помощью этого байта движок PHP может различать обычные переменные и ссылочные переменные. Поскольку PHP позволяет пользователям использовать и использовать пользовательские ссылки, в контейнере переменных zval также имеется внутренний механизм подсчета ссылок для оптимизации использования памяти. Второй дополнительный байт – “refcount”, чтобы указать количество переменных (также известных как символы), указывающих на этот контейнер переменных zval. Все символы существуют в таблице символов, где каждый символ имеет область действия. Простое понимание показано на следующем рисунке:
Как указано в официальном документе, Xdebug можно использовать для проверки количества ссылок:
php $a = "new string"; $c = $b = $a; xdebug_debug_zval( 'a' ); unset( $b, $c ); xdebug_debug_zval( 'a' ); ?>
Приведенная выше процедура выведет:
a:, a:,
Будьте осторожны: Начиная с версии PHP 7 NTS, ссылки на вышеуказанные процедуры больше не будут учитываться Количество цитирований a после $c=$b=$a также равно 1. Конкретные категории следующие: В PHP 7 zval может быть подсчитан по ссылке или нет. В структуре zval есть флаг, который определяет это. ① Для переменных типа null, bool, int и double значение refcount никогда не учитывается. (2) Для типов объектов и ресурсов количество ссылок соответствует php5; ③ Для строк Переменные без ссылок называются “фактическими строками”. и Эти строки, на которые ссылаются, повторно удаляются (т. Е. Имеется только одна вставленная строка с определенным содержимым) и гарантированно существуют в течение всего срока действия запроса, поэтому для них нет необходимости использовать количество ссылок. Если используется кэш операций, эти строки будут существовать в общей памяти, и в этом случае вы не сможете использовать подсчет ссылок (поскольку наш механизм подсчета ссылок неатомный); ④ Для массивов
Наш демонстрационный пример выглядит следующим образом:
Результат выглядит следующим образом:
Ссылка: https://stackoverflow.com/questions/34764119/confusion-about-php-7-refcount
III. Цикл Переработки
По умолчанию механизм сборки мусора PHP включен, а затем есть параметр php.ini, который позволяет вам изменять его. :zend.enable_gc 。
Когда механизм сборки мусора включен, алгоритм определяет, что поиск будет выполняться всякий раз, когда корневой буфер заполнен. Корневой буфер по умолчанию имеет фиксированный размер 10 000, который можно изменить, изменив константу GC_ROOT_BUFFER_MAX_ENTRIES в исходном файле PHP Zend/zend_gc.c, а затем перекомпилировав PHP. Когда механизм сбора мусора закрывается, алгоритм поиска никогда не выполняется, однако корень всегда будет существовать в корневом буфере, независимо от того, активирован ли механизм сбора мусора в конфигурации.
В дополнение к изменению конфигурации zend. enable_gc, он также может передавать Вызывать функции gc_enable() и gc_disable() соответственно для включения и выключения механизма сбора мусора во время работы php. Вызов этих функций аналогичен изменению элементов конфигурации для включения или выключения механизмов сбора мусора. Циклическая рециркуляция может быть применена даже в том случае, если корневой буфер может быть неполон. Вы можете сделать это, вызвав функцию gc_collect_cycles (). Эта функция возвращает количество циклов, восстановленных с помощью этого алгоритма.
Причина включения и выключения сбора мусора и автономной инициализации заключается в том, что некоторые части вашего приложения могут занимать много времени. В этом случае вы, возможно, не захотите использовать механизм сбора мусора. Конечно, отключение сборки мусора для какой-либо части вашего приложения чревато возможной утечкой памяти, поскольку некоторые из возможных корневых файлов могут не храниться в ограниченном корневом буфере. Поэтому Непосредственно перед вызовом функции gc_disable() для освобождения памяти было бы разумно сначала вызвать функцию gc_collect_cycles (). Потому что это очистит все возможные корни, которые были сохранены в корневом буфере, а затем оставит пустой буфер для хранения возможных корней, когда механизм сборки мусора будет закрыт.
IV. Влияние на производительность
1、 Экономия объема памяти
Во-первых, вся причина реализации механизма сборки мусора заключается в экономии памяти путем очистки переменных, на которые ссылается цикл, после выполнения предварительных условий. При выполнении PHP, как только корневой буфер заполнен или вызван gc_collect_cycles() При использовании функции выполняется сборка мусора.
2、 Увеличенное время выполнения
Вторая область, в которой сбор мусора влияет на производительность, – это время, необходимое для освобождения утечек памяти. Обычно механизм сбора мусора в PHP только увеличивает время, затрачиваемое на выполнение алгоритма переработки. Но в обычных (небольших) сценариях вообще не должно быть никакого влияния на производительность.
3. Экономия памяти позволит большему количеству этих сценариев запускаться на вашем сервере в то же время, когда в обычных сценариях запущен механизм рециркуляции. Потому что общий объем используемой памяти не достиг верхнего предела. Это преимущество особенно очевидно в длительно работающих сценариях. Например, долгосрочные наборы тестов или сценарии демонов. В то же время новый механизм сбора мусора для приложений-сценариев, которые обычно работают дольше, чем веб-сценарии, должен значительно изменить представление о том, что проблемы с утечкой памяти трудно решить.
Больше читателей, интересующихся контентом, связанным с PHP, могут ознакомиться с темами этого сайта: Введение в объектно-ориентированное программирование Php, Введение в базовую грамматику PHP, Краткое описание работы и использования операторов PHP, Краткое описание навыков сетевого программирования PHP, Полный набор навыков работы с массивами PHP и Строка Php. Краткое описание использования, вводный курс по работе с базой данных PHP + MySQL и общие навыки работы с базой данных PHP
Я надеюсь, что эта статья будет полезна для разработки PHP – программ для всех.