머리말
메모리 누수 문제에 대해 이야기하기 전에 JavaScript의 가비지 수집 메커니즘을 살펴보겠습니다. JavaScript에는 자동 가비지 수집 메커니즘이 있습니다. 그들이 차지하고 있는 메모리를 해제하세요. 이를 위해 가비지 수집기는 고정된 간격(또는 코드 실행 중 예약된 수집 시간)으로 작동합니다. 일반적으로 사용되는 두 가지 방법은 명확한 표시(Clear Marking)와 참조 카운팅(Reference Counting)입니다.
1. 마크 스윕
자바스크립트에서 가장 일반적으로 사용되는 가비지 수집 방법은 마크 앤 스윕입니다. 가비지 수집기는 실행 시 메모리에 저장된 모든 변수를 표시합니다(모든 표시 방법을 사용할 수 있음). 그런 다음 환경의 변수와 환경의 변수가 참조하는 변수의 태그를 제거합니다. 이후에 표시된 변수는 환경 내의 변수가 더 이상 해당 변수에 접근할 수 없으므로 삭제할 변수로 간주됩니다. 마지막으로 가비지 수집기는 메모리 정리 작업을 완료하여 표시된 값을 삭제하고 해당 값이 차지하는 메모리 공간을 회수합니다.
2. 참조 카운팅
참조 카운팅의 의미는 각 값이 참조되는 횟수를 추적하고 기록하는 것입니다. 변수가 선언되고 참조 유형 값이 변수에 할당되면 이 값에 대한 참조 수는 1입니다. 동일한 값이 다른 변수에 할당되면 해당 값의 참조 카운트가 1 증가합니다. 반대로, 이 값에 대한 참조를 포함하는 변수가 다른 값을 얻으면 이 값에 대한 참조 수가 1씩 감소합니다. 이 값에 대한 참조 횟수가 0이 되면 더 이상 이 값에 접근할 수 없다는 뜻이므로, 차지하는 메모리 공간을 회수할 수 있습니다. 이렇게 하면 다음에 가비지 수집기가 실행될 때 참조가 0인 값이 차지한 메모리를 해제하게 됩니다.
Netscape Navigator 3.0은 참조 카운팅 전략을 사용한 최초의 브라우저였지만 곧 심각한 문제에 직면했습니다. 다음 예를 참조하십시오.
function problem(){ var objectA = new Object(); var objectB = new Object(); objectA.someOtherObject = objectB; objectB.anotherObject = objectA; }
설명: objectA 및 objectB는 즉, 두 개체의 참조 수는 2입니다. 표시 및 스윕 전략을 사용하는 구현에서는 함수가 실행된 후 두 개체가 모두 범위를 벗어나므로 이 상호 참조는 질문. 그러나 참조 계산 전략을 사용하는 구현에서는 objectA 및 objectB가 함수가 실행된 후에도 계속 존재하게 됩니다. 왜냐하면 해당 참조 수가 결코 0이 되지 않기 때문입니다. 이 함수를 여러 번 호출하면 많은 양의 메모리가 재활용되지 않습니다.
이러한 이유로 넷스케이프는 Navigator 4.0에서 참조 카운팅 방식을 포기했습니다. 그러나 참조 카운팅으로 인한 문제는 여기서 끝나지 않았습니다. 9 이전 IE의 일부 개체는 기본 JavaScript 개체가 아니었습니다. 예를 들어, BOM과 DOM의 개체는 C++를 사용하여 COM(Component Object Model) 개체 형태로 구현되며, COM 개체의 가비지 수집 메커니즘은 참조 계산 전략을 사용합니다. 따라서 IE의 JavaScript 엔진이 표시 및 스윕 전략을 사용하여 구현되었더라도 JavaScript에서 액세스하는 COM 개체는 여전히 참조 계산 전략을 기반으로 합니다. 즉, COM 개체가 IE에 포함될 때마다 순환 참조 문제가 발생합니다.
예:
var element = document.getElementById("some_element"); var myObject = new Object(); myObject.element = element; element.someObject = myObject;
DOM 요소(element)와 기본 JavaScript 개체(myObject) 사이에 순환 참조가 생성됩니다. 그중 myObject 변수에는 요소 개체를 가리키는 element라는 속성이 있고, element 변수에는 myObject를 다시 가리키는 someObject라는 속성도 있습니다. 이 순환 참조로 인해 예제의 DOM이 페이지에서 제거되더라도 재활용되지 않습니다.
해결책: 변수와 이전에 참조한 값 사이의 연결을 끊으려면 변수를 null로 설정하세요.
myObject.element = null; element.someObject = null;
위 내용을 읽은 후 주제에 대해 이야기하겠습니다.
클로저로 인해 메모리 누수가 발생하지 않습니다.
IE9 이전 버전에서는 JScript 개체와 COM 개체에 대해 서로 다른 가비지 수집을 사용하기 때문입니다. 따라서 클로저는 이러한 IE 버전에서 몇 가지 특별한 문제를 야기합니다. 특히 HTML 요소가 클로저의 범위 체인에 저장되어 있으면 해당 요소가 파괴될 수 없음을 의미합니다.
function assignHandler(){ var element = document.getElementById("someElement"); element.onclick = function(){ alert(element.id); }; }
위 코드는 요소 이벤트를 클로저로 생성합니다. 그러면 순환 참조가 생성됩니다. 익명 함수는 AssignHandler()의 활성 개체에 대한 참조를 저장하므로 요소에 대한 참조 수를 줄일 수 없게 됩니다. 익명 함수가 존재하는 한 요소의 참조 번호는 1 이상이므로 차지하는 메모리는 절대 재활용되지 않습니다.
해결 방법 서문에서 언급한 대로 element.id의 복사본을 변수에 저장합니다. , 따라서 클로저의 변수에 대한 순환 참조를 제거하고 요소 변수를 null로 설정합니다.
function assignHandler(){ var element = document.getElementById("someElement"); var id = element.id; element.onclick = function(){ alert(id); }; element = null; }
요약: 클로저는 메모리 누수를 일으키지 않지만 IE9 이전 버전에서는 JScript 개체와 COM 개체에 대해 서로 다른 가비지 수집을 사용하기 때문에 메모리를 재활용할 수 없으므로 IE에서는 문제가 됩니다. 메모리 누수와는 아무 관련이 없습니다.