JavaScript 가비지 수집 메커니즘 분석_javascript 기술

회사에서 전문가들이 토론 중에 메모리 누수에 대해 이야기하는 것을 자주 듣곤 하는데, 저는 늘 놀랍습니다. 최근에는 주로 웹 개발에 에너지를 쏟고 있습니다(이 책에는 아주 좋은 내용이 있습니다. 제목) 허세입니다. 저자는 실제로 JavaScript 가비지 수집 메커니즘을 아주 잘 작성했으며 메모리 누수에 대해 어느 정도 이해했습니다.

C# 및 Java와 마찬가지로 JavaScript에는 자동 가비지 수집 메커니즘이 있습니다. 즉, 실행 환경이 코드 실행 중에 사용되는 메모리를 관리해야 한다는 의미입니다. 개발 중에 메모리 할당 및 쓸모 없는 메모리 재활용을 고려할 필요가 없습니다. 프로세스. JavaScript 가비지 수집 메커니즘은 매우 간단합니다. 더 이상 사용되지 않는 변수를 찾은 다음 해당 변수가 차지하는 메모리를 해제합니다. 그러나 이 프로세스는 비용이 많이 들기 때문에 시간이 많이 걸리지 않으므로 가비지 수집기는 주기적으로 데이터를 수집합니다. 일정한 간격으로 시행합니다.

가변 생명주기

위 내용을 읽은 후 더 이상 사용되지 않는 변수가 무엇인지 묻는 학생들이 있을 것입니다. 더 이상 사용되지 않는 변수는 수명 주기가 종료된 변수입니다. 물론 로컬 변수만 사용할 수 있습니다. 전역 변수의 수명 주기는 브라우저가 페이지를 언로드할 때까지 끝나지 않습니다. 지역 변수는 함수가 실행되는 동안에만 존재하며, 이 과정에서 해당 값을 저장하기 위해 스택이나 힙에 지역 변수에 해당하는 공간이 할당되며, 이 변수는 함수가 끝날 때까지 함수에서 사용됩니다. (클로저 내부 함수로 인해 외부 함수는 끝이라고 볼 수 없습니다. 클로저를 이해하려면 JavaScript 범위 체인과 JavaScript 클로저가 정확히 무엇인지 살펴보면 됩니다.)

함수가 종료되면 지역 변수는 더 이상 필요하지 않으며 해당 변수가 차지하는 메모리를 해제할 수 있습니다. 고양이 한 마리와 아주 간단한 일에도 돈이 많이 드는 이유는 무엇일까요? 이것은 가비지 수집의 빙산의 일각에 불과합니다. 함수가 종료된 것처럼 보이지만 실제로는 가비지 수집기가 해당 변수에서 수영해야 하며 이는 쓸모가 없습니다. 더 이상 유용하지 않은 변수를 표시합니다. 쓸모없음을 표시하는 전략에는 여러 가지가 있으며, 일반적으로 두 가지 방법이 있습니다

표시 및 청소

이것은 JavaScript에서 가장 일반적인 가비지 수집 방법입니다. 함수에서 변수를 선언하는 등 변수가 실행 환경에 들어갈 때 가비지 수집기는 변수가 환경을 떠날 때 이를 "환경에 들어갑니다"라고 표시합니다. 함수 실행이 종료됨)은 이를 "환경 종료"로 표시합니다. 표시 방법은 특수 비트 반전, 목록 유지 등 여러 가지가 있지만 중요한 것은 어떤 전략을 사용하느냐는 원칙적으로 환경에 들어가는 변수가 차지하는 메모리는 불가능합니다. 언제든지 발생할 수 있습니다.

가비지 수집기는 런타임 시 메모리에 저장된 모든 변수를 표시한 다음 환경의 변수와 환경의 변수가 참조하는 변수(클로저)를 제거합니다. 이러한 작업이 완료된 후에도 표시는 계속 존재합니다. 삭제된 이유는 환경의 변수가 더 이상 이러한 변수에 액세스할 수 없기 때문입니다. 그러면 가비지 수집기가 표시된 변수가 차지하는 공간을 차지하게 됩니다.

대부분의 브라우저는 가비지 수집을 위해 이 방법을 사용합니다. 차이점은 표시 방법과 가비지 수집 간격에 있습니다. IE 버전이 낮을 뿐이고 역시 IE입니다. . .

참조 카운팅

낮은 버전의 IE에서는 가비지 수집에 참조 카운팅을 사용하기 때문에 메모리 누수가 자주 발생합니다. 참조 카운팅 전략은 변수가 선언되고 해당 변수에 참조 유형이 할당되면 해당 값에 대한 참조 횟수가 1만큼 증가합니다. 다른 값으로 변경되면 이 값에 대한 참조 수가 1만큼 감소합니다. 이 값에 대한 참조 수가 0이 되면 사용 중인 변수가 없으며 이 값에 액세스할 수 없음을 의미하므로 차지하는 공간은 가비지 수집기가 실행될 때 참조 횟수가 0인 값이 차지하는 공간은 지워집니다.

좋은 방법인 것 같은데 채택하는 브라우저가 왜 이렇게 적은 걸까요? 메모리 누수도 발생하나요? 주로 이 방법은 순환 참조 문제를 해결할 수 없기 때문입니다. 예를 들어 객체 A에는 객체 B를 가리키는 속성이 있고 객체 B에도 객체 A를 가리키는 속성이 있으므로 서로를 참조합니다

코드 복사 코드는 다음과 같습니다.

function test(){
var a={ };
var b={};
a.prop=b;
b.prop=a;
}

이렇게 하면 a와 b의 참조 시간은 모두 2입니다. test() 실행이 완료된 후에도 두 개체 모두 환경을 떠나는 마크와 명확한 전략에 따라 문제가 없습니다. 환경은 지워지지만 참조 카운팅 전략에서는 작동하지 않습니다. 왜냐하면 이 두 객체의 참조 수는 여전히 2이고 0이 되지 않으므로 이 함수가 차지하는 공간은 지워지지 않습니다. 여러 번 호출하면 계속해서 공간이 재활용되지 않아 메모리 누수가 발생합니다.

IE에서는 JavaScript 개체는 Mark and Clear를 통해 가비지 수집되지만 BOM 및 DOM 개체는 참조 계산을 통해 가비지 수집됩니다. 즉, BOM과 DOM이 포함되어 있는 한 순환 참조 문제가 발생합니다. 위의 예를 보면 너무 약하다고 생각하는 학생들도 있습니다. 사실 우리만 하는 일일까요?

코드 복사 코드는 다음과 같습니다.

window.onload=function externalFunction(){
var obj = document.getElementById("element");
         obj.onclick=function innerFunction(){};
    };

이 코드는 괜찮아 보이지만 obj는 document.getElementById("element")를 참조하고 document.getElementById("element")의 onclick 메서드는 당연히 obj를 포함하는 외부 환경의 변수를 참조합니다. 매우 숨겨져 있습니다.

솔루션

가장 간단한 방법은 순환 참조를 직접 수동으로 해제하는 것입니다. 예를 들어 현재 기능은 다음과 같이 수행할 수 있습니다.

코드 복사 코드는 다음과 같습니다.

window.onload=function externalFunction(){
var obj = document.getElementById("요소");

가비지 수집은 언제 실행되나요?


가비지 수집기는 주기적으로 실행됩니다. 많은 메모리가 할당되면 재활용 작업이 매우 어려워집니다. 가비지 수집 간격을 결정하는 것은 생각해 볼 만한 문제입니다. IE6의 가비지 수집은 메모리 할당량에 따라 실행됩니다. 환경에 256개의 변수, 4096개의 개체 또는 64k 문자열이 있으면 가비지 수집기가 실행됩니다. 매우 과학적인 것처럼 보이며 단락을 누를 필요가 없습니다. 매번 한 번씩만 호출되는데, 때로는 필요하지 않을 때도 있는데, 필요할 때 호출하면 좋지 않을까요? 하지만 환경에 너무 많은 변수가 있고 스크립트가 지금 너무 복잡하다면 이는 정상입니다. 결과적으로 가비지 수집기가 항상 작동하므로 브라우저가 재생할 수 없게 됩니다.

Microsoft는 IE7에서 조정을 수행했습니다. 트리거 조건은 더 이상 고정되지 않고 동적으로 수정됩니다. 가비지 수집기에 의해 복구된 메모리 할당량이 메모리 점유량의 15% 미만인 경우. 프로그램에서는 대부분의 메모리를 재활용할 수 없다는 의미입니다. 이때 설정된 가비지 수집 트리거 조건이 너무 민감합니다. 이때 재활용된 메모리가 85%보다 높으면 대부분의 메모리를 의미합니다. 메모리는 오래 전에 정리되어야 합니다. 이때 트리거 조건을 다시 설정하십시오. 이는 가비지 수집 작업을 훨씬 더 기능적으로 만듭니다.

C# 및 Java와 유사하게 가비지 수집 프로그램을 수동으로 호출할 수 있지만 리소스를 많이 소비하고 수동으로 호출하는 것이 브라우저가 판단할 수 있는 것보다 정확하지 않기 때문에 호출하지 않는 것이 좋습니다. 가비지 수집 프로그램을 수동으로 수행합니다.