PHP 재활용 주기 소개

이 글은 PHP 재활용 주기에 대해 소개합니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

다음 절차는 배열 및 객체 유형에만 적용됩니다.

전통적으로 PHP에서 사용되는 참조 계산 메모리 메커니즘은 순환 참조 메모리 누수를 처리할 수 없습니다. 그러나 PHP 5.3.0은 이 메모리 누수 문제를 처리하기 위해 » 참조 카운트 시스템의 동시 주기 수집 문서에 있는 동기화 알고리즘을 사용합니다.

알고리즘에 대한 완전한 설명은 이 섹션의 범위를 벗어나므로 기본적인 부분만 소개합니다. 먼저, 몇 가지 기본 규칙을 설정해야 합니다. 참조 횟수가 증가하면 계속 사용되며 더 이상 가비지에는 포함되지 않습니다. 참조 횟수가 0으로 줄어들면 변수 컨테이너가 지워집니다(무료). 즉, 가비지 사이클은 참조 카운트가 0이 아닌 값으로 감소할 때만 발생합니다. 둘째, 가비지 사이클 동안 참조 횟수가 1만큼 감소하는지 확인하고 참조가 0인 변수 컨테이너를 확인하여 어떤 부분이 가비지인지 알아냅니다.

가능한 쓰레기 주기 감소에 대한 모든 참조 횟수를 확인하지 않기 위해 이 알고리즘은 가능한 모든 루트를 나눕니다(가능한 루트는 zval 변수 컨테이너임). 이를 루트 버퍼(보라색으로 표시, 의심스러운 쓰레기라고 함)에 저장합니다. 이는 또한 가능한 각 쓰레기 루트가 버퍼에 한 번만 나타나도록 보장합니다. 가비지 수집은 루트 버퍼가 가득 찬 경우에만 버퍼 내의 모든 다른 변수 컨테이너에서 수행됩니다. 위 이미지의 A단계를 살펴보세요.

B단계에서는 각 보라색 변수 삭제를 시뮬레이션합니다. 삭제를 시뮬레이션할 때 보라색이 아닌 일반 변수의 참조 카운트가 "1"만큼 줄어들 수 있습니다. 일반 변수의 참조 카운트가 0이 되면 이 일반 변수의 삭제를 다시 시뮬레이션합니다. 각 변수는 한 번만 삭제되도록 시뮬레이션할 수 있으며, 시뮬레이션된 삭제 후에는 회색으로 표시됩니다(원본 기사에서는 동일한 변수 컨테이너가 "1"만큼 두 번 감소하지 않도록 보장한다고 했는데 이는 잘못된 것입니다).

C단계에서 시뮬레이션은 각 보라색 변수를 복원합니다. 복구는 조건부입니다. 변수의 참조 횟수가 0보다 크면 복구되도록 시뮬레이션됩니다. 마찬가지로 각 변수는 한 번만 복원할 수 있습니다. 복원 후에는 기본적으로 B단계의 역동작입니다. 이러한 방식으로 복구할 수 없는 나머지 파란색 노드 더미는 D 단계에서 이를 탐색하여 삭제해야 하는 파란색 노드입니다.

알고리즘은 모두 단순 순회(가장 일반적인 심층 검색 순회)를 사용하는 시뮬레이션된 삭제, 시뮬레이션된 복구 및 실제 삭제에 관한 것입니다. 복잡성은 보라색으로 의심되는 가비지 변수뿐만 아니라 시뮬레이션 작업을 수행하는 노드 수와 긍정적인 관련이 있습니다.

이제 이 알고리즘에 대한 기본적인 이해를 마쳤으므로 다시 돌아가 이것이 PHP와 어떻게 통합되는지 살펴보겠습니다. 기본적으로 PHP의 가비지 수집 메커니즘은 켜져 있으며 이를 수정할 수 있는 php.ini 설정인 zend.enable_gc가 있습니다.

가비지 수집 메커니즘이 켜져 있으면 루트 버퍼가 가득 찰 때마다 위에서 설명한 루프 검색 알고리즘이 실행됩니다. 루트 캐시 영역은 고정된 크기를 가지며 10,000개의 가능한 루트를 저장할 수 있습니다. 물론 PHP 소스 파일 Zend/zend_gc.c에서 상수 GC_ROOT_BUFFER_MAX_ENTRIES를 수정한 다음 PHP를 다시 컴파일하여 이 10,000개의 값을 수정할 수 있습니다. 가비지 수집이 꺼지면 루프 검색 알고리즘이 실행되지 않습니다. 그러나 구성에서 가비지 수집이 활성화되었는지 여부에 관계없이 루트가 항상 루트 버퍼에 존재할 수 있습니다.

가비지 수집 메커니즘이 꺼지면 루트 버퍼가 가능한 루트로 가득 차 있으면 더 많은 가능한 루트가 기록되지 않습니다. 기록되지 않은 가능한 루트는 이 알고리즘으로 분석 및 처리되지 않습니다. 순환 참조 순환의 일부인 경우에는 지워지지 않으며 메모리 누수가 발생합니다.

가비지 수집이 불가능할 때에도 가능한 루트를 기록하는 이유는 가능한 루트를 찾을 때마다 가비지 수집이 켜져 있는지 확인하는 것보다 가능한 루트를 기록하는 것이 더 빠르기 때문입니다. 그러나 가비지 수집 및 분석 메커니즘 자체에는 많은 시간이 걸립니다.

zend.enable_gc 구성을 수정하는 것 외에도 gc_enable() 및 gc_disable() 함수를 각각 호출하여 가비지 수집 메커니즘을 켜고 끌 수도 있습니다. 이러한 함수를 호출하는 것은 가비지 수집 메커니즘을 켜거나 끄기 위해 구성 항목을 수정하는 것과 동일한 효과를 갖습니다. 루트 버퍼가 가득 차지 않은 경우에도 주기적으로 수집을 강제하는 기능. 이 목적으로 gc_collect_cycles() 함수를 호출할 수 있습니다. 이 함수는 이 알고리즘을 사용하여 재활용된 주기 수를 반환합니다.

가비지 수집을 켜고 끄고 자율 초기화를 허용하는 이유는 애플리케이션의 일부 부분이 시간에 민감할 수 있기 때문입니다. 이 경우 가비지 수집을 사용하고 싶지 않을 것입니다. 물론 애플리케이션의 특정 부분에 대해 가비지 수집을 끄면 메모리 누수가 발생할 위험이 있습니다. 일부 루트는 제한된 루트 버퍼에 맞지 않을 수 있기 때문입니다. 따라서 gc_disable() 함수를 호출하여 메모리를 해제하기 직전에 gc_collect_cycles() 함수를 먼저 호출하는 것이 현명할 수 있습니다. 이렇게 하면 루트 버퍼에 저장된 가능한 모든 루트가 지워지기 때문에 가비지 수집 메커니즘이 꺼지면 빈 버퍼를 남겨서 가능한 루트를 저장할 더 많은 공간을 확보할 수 있습니다.

위 내용은 PHP 재활용 주기 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!