84669인 학습
152542인 학습
20005인 학습
5487인 학습
7821인 학습
359900인 학습
3350인 학습
180660인 학습
48569인 학습
18603인 학습
40936인 학습
1549인 학습
1183인 학습
32909인 학습
전역 변수에 null을 할당하여 이를 적극적으로 역참조하고 메모리를 해제하는 것이 참조 계산 전략인가요? JS의 가비지 수집 메커니즘이 마크 앤 클리어만 사용한다는 뜻이 아닌가요? 마크 클리어 전략에는 역참조가 포함되지 않습니까?
변수 선언은 힙에 메모리를 할당합니다. 해당 참조를 null로 표시하면 이 변수에 해당하는 메모리 공간을 회수할 수 있음을 인터프리터에 알립니다.
그러나 이것은 JS의 구문 설계이며 인터프리터 구현 시 메모리 관리의 세부 사항을 포함하지 않습니다. 실제로 브라우저 GC 전략도 다릅니다. Chrome/Firefox/Safari는 표시 및 스윕을 사용하는 반면 이전 버전의 IE는 참조 계산을 사용합니다.
역참조는 null을 할당하는 형태만 있는 것이 아닙니다. 인터프리터는 범위를 통해 변수의 수명 주기를 결정하고 변수 범위를 벗어날 때 변수의 메모리 공간을 회수할 수 있습니다.
[Mark Clearance]와 [Reference Counting]은 서로 다른 두 가지 GC 알고리즘인 반면, [Dereference]는 JS의 문법 기능입니다. 둘은 직교할 수 있습니다(관련이 없음).
js 사양에서는 mark andclear를 사용하도록 되어 있지만 구현하면 항상 Mark and Clear가 되지 않을 수 있습니다.
여기서 헷갈리는 이유는 재활용의 겉모습만 보고 청소의 본질을 보지 못하기 때문입니다.
참조 카운팅은 이름에서 알 수 있듯이 객체에 대한 참조를 계산하고 참조가 0이면 재활용됩니다.
마킹과 클리어는 두 단계로 나누어집니다. 마킹 단계는 루트부터 시작하여 접근 가능한 객체를 비교한 후, 클리어 단계에서 마킹되지 않은 객체를 재활용합니다.
사실 소스코드 구현을 보지 않으면 어떤 전략이 사용되었는지 표면적으로 알기가 어렵습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
변수 선언은 힙에 메모리를 할당합니다. 해당 참조를 null로 표시하면 이 변수에 해당하는 메모리 공간을 회수할 수 있음을 인터프리터에 알립니다.
그러나 이것은 JS의 구문 설계이며 인터프리터 구현 시 메모리 관리의 세부 사항을 포함하지 않습니다. 실제로 브라우저 GC 전략도 다릅니다. Chrome/Firefox/Safari는 표시 및 스윕을 사용하는 반면 이전 버전의 IE는 참조 계산을 사용합니다.
역참조는 null을 할당하는 형태만 있는 것이 아닙니다. 인터프리터는 범위를 통해 변수의 수명 주기를 결정하고 변수 범위를 벗어날 때 변수의 메모리 공간을 회수할 수 있습니다.
[Mark Clearance]와 [Reference Counting]은 서로 다른 두 가지 GC 알고리즘인 반면, [Dereference]는 JS의 문법 기능입니다. 둘은 직교할 수 있습니다(관련이 없음).
js 사양에서는 mark andclear를 사용하도록 되어 있지만 구현하면 항상 Mark and Clear가 되지 않을 수 있습니다.
여기서 헷갈리는 이유는 재활용의 겉모습만 보고 청소의 본질을 보지 못하기 때문입니다.
참조 카운팅은 이름에서 알 수 있듯이 객체에 대한 참조를 계산하고 참조가 0이면 재활용됩니다.
마킹과 클리어는 두 단계로 나누어집니다. 마킹 단계는 루트부터 시작하여 접근 가능한 객체를 비교한 후, 클리어 단계에서 마킹되지 않은 객체를 재활용합니다.
사실 소스코드 구현을 보지 않으면 어떤 전략이 사용되었는지 표면적으로 알기가 어렵습니다.