얼마 전 IE에서 자바스크립트 스크립트의 메모리 누수 문제를 소개한 적이 있는데, 이후 여러 열성적인 네티즌들과 토론을 거쳐 메모리 누수의 사실과 원리를 기본적으로 인식하게 되었습니다. 소규모 테스트 사례에서는 기본적으로 IE 스크립트의 ML 문제를 방지하는 것이 달성되었습니다. 그런데 최근 IE에서 '조심'만으로는 스크립트 ML을 막는 것이 매우 어려운 것으로 밝혀졌습니다. 초기 논의에 착오가 있는 걸까요?
'조심'이란 무슨 뜻인가요? 즉, 개체가 서로 참조할 때 개체가 삭제될 때(반드시 페이지 새로 고침은 아님) 서로의 참조 체인을 끊습니다. 특히 스크립트에서 생성된 개체와 DHTML의 개체 사이의 참조는 HTML 요소의 모든 참조를 지웁니다. ; 모든 HTML 요소에서 이벤트 핸들러 함수 콜백을 삭제하고 배열을 삭제할 때 내부 요소를 삭제합니다.
가장 중요한 것은 중복된 스크립트 개체와 DHTML 요소 개체를 만들지 않도록 노력하는 것입니다. 속성을 수정하면 효과를 얻을 수 있으며, 더 번거롭더라도 새 개체가 다시 생성되지 않습니다.
위 단계를 거친 후 IE의 메모리 사용량 증가율이 감소했습니다. 그러나 여전히 복잡한 스크립트 실행에 대한 지원(Bindows의 복잡성에 가깝습니다)을 완전히 충족할 수 없으며 이는 다음 사항에 반영됩니다.
1. 스크립트 실행 프로세스 중 메모리 사용량은 여전히
2. 최소화된 IE 창 방법을 사용하여 IE가 GC를 수행하도록 합니다. 이는 GC 물리적 메모리만 가능하며 가상 메모리에는 유효하지 않습니다.
3. 페이지가 원본 스크립트에서 빠져나옵니다. 실행 도메인(URL 변경) 및 메모리 해제 양이 너무 적거나 해제하지 마십시오.
4. IE에서 사용하는 메모리를 완전히 해제하려면 IEXPLORE.EXE 프로세스(즉, 모든 IE 창)를 닫아야 합니다. .
오늘 문득 잊혀진 Bindows가 생각나서 달려가서 살펴보니 2월말에 1.3버전이 출시되었다는 소식을 듣고 2월말에 데모를 시작하게 되었습니다. 홈페이지. 효과는 말할 필요도 없이 직접 확인해보시면 효율성이 상당히 높습니다. 데모에는 다차원 데이터 표시와 유사한 GRID도 있으며 실제로 고정된 행 및 열 헤더를 지원합니다. Dazzling은 Bindows의 영원한 기능이었습니다. 저는 깜짝 놀랐기 전에 Bindows가 메모리를 어떻게 처리하는지 살펴봐야 한다고 생각했습니다. 정말 보기 전까지는 모르겠고, 보면 깜놀!
www.bindows.net을 엽니다. 내 IE 메모리 사용량은 약 (28PM 18VM)M입니다. 데모 프로그램을 엽니다. 메모리는 약 (38PM 35VM)M에 도달했습니다. 몇 가지 작업을 더 수행한 후 메모리는 약 (80PM 75VM)M에 도달했습니다. 그래서 데모창을 닫았는데, IE는 15M 정도의 메모리를 해제했는데 (70PM 70VM)M 수준에서 멈추더군요. 현재 IE URL을 변경하고 구글로 점프한 후에도 IE의 메모리 사용량은 여전히 줄어들지 않는 것 같습니다 @_ @. 하하, Bindows에도 메모리 누수가 있습니다~. 정말 악당이네요, 555... 시간이 좀 지나서 보니 IE의 메모리 사용량이 제가 시작할 때와 거의 비슷하게 떨어졌네요 :). 정말 좋은 소식입니다. 더 이상 IE의 잘못을 저지를 수 없을 것 같아서 onunload 중에 Bindows의 처리 코드를 추적하기 시작했습니다.
onunload 코드로 한번에 점프하려면 어떻게 해야 하나요? 여기에 해킹이 있습니다. 먼저 IE에서 Alt V, u, b를 누르십시오(고급 IE 옵션에서 "스크립트 디버깅 비활성화"를 선택 취소해야 하며 U 단축키 옵션은 보기 메뉴에서만 사용할 수 있습니다). 그런 다음 Bindows 데모 돔 창을 즉시 닫고 VS.NET 2003을 스크립트 디버거로 선택한 다음 onunload 입구로 바로 이동합니다.
Bindows는 IE에서 스크립트 메모리 사용을 관리하는 데 매우 신중한 작업을 수행합니다. 복잡한 개체는 완전한 처리 방법을 구현했습니다. 어떤 용도로 사용됩니까? 호출되면 먼저 DHTML 개체 인스턴스와 스크립트 개체 인스턴스 사이의 참조 체인을 끊고 전역 캐시 변수의 데이터를 지우고 attachmentEvent 메서드를 사용하여 가져온 이벤트 처리 함수를 분리해야 합니다. ; 다른 이벤트 처리 콜백은 null을 할당하여 지우고, 스크립트 개체 간의 상위 또는 하위 관계 참조 체인을 잘라냅니다.
여기서 조금 혼란스러운 점은 IE의 GC 트리거가 불확실하다는 것입니다(현재 알려진 확실한 트리거는 IE 창을 최소화하는 것입니다). 페이지가 방금 로드되면 메모리가 즉시 해제되지 않습니다. 그러나 일정 기간 사용하면 IE에서 사용하는 메모리가 감소합니다. 따라서 앞서 논의한 방법에 대해서는 의심할 필요가 없으며 "스크립트 객체 간의 부모, 자식 관계 참조 체인을 끊는다"는 점을 제외하면 Bindows의 dispose 원리와 처리 방법은 기본적으로 제가 설명한 것과 동일합니다. 더 일찍.
참고: PM 물리적 메모리, VM 가상 메모리. 모두 작업 관리자에서 볼 수 있습니다.