메모리 구조와 가비지 컬렉션

하루에 하나씩 정리하는 CS 지식

메모리 구조와 가비지 컬렉션

1. 핵심

• 프로세스 메모리 구조는 크게 Stack, Heap, Code, Data 영역으로 나뉜다.

  • Stack: 함수 호출, 지역 변수 저장 (자동 관리).

  • Heap: 동적 메모리 할당 (수동 관리 필요).

  • Code/Data: 프로그램 코드와 전역 변수 저장.

• 가비지 컬렉션(GC): JS 엔진(V8)이 Heap 메모리를 주기적으로 탐색해, 더 이상 참조되지 않는 객체를 자동으로 해제한다.

• 브라우저 탭마다 독립된 프로세스가 있고, 각 탭의 JS 엔진이 이 구조를 갖는다.

2. 가비지 컬렉션 (Garbage Collection)

운영체제는 일반적으로 C/C++ 같은 언어에서 개발자가 직접 메모리를 해제해야 하지만, JS는 가비지 컬렉터(Garbage Collector) 가 자동으로 Heap을 관리한다.

• JS 엔진(V8)은 “도달 가능성(Reachability)”을 기준으로 객체를 추적

• 더 이상 어떤 변수에서도 참조되지 않는 객체는 ‘가비지(쓰레기)’로 판단

• GC가 주기적으로 스캔하면서 그런 객체를 Heap에서 해제

3. Issue

JS는 자동 GC 덕분에 메모리 관리 부담이 적지만, 개발자의 실수로 메모리 누수(memory leak) 가 자주 발생한다.

• 예: useEffect의 이벤트 리스너를 cleanup하지 않음.

• 예: 전역 변수에 DOM 참조를 계속 유지.

• 예: 클로저 안에서 불필요한 객체를 오래 참조.

결과적으로 Heap 메모리가 점점 늘어나 → 브라우저 탭이 느려지고, 최악의 경우 크래시 발생.

4. QA

❓ Q1. Java와 JavaScript 가비지 커렉션 차이점은?

💡 Java: “오래 사는 객체”를 기준으로 세대별 관리

• 서버 환경 중심 → 객체 수명 다양

• GC가 Young/Old 세대로 나눠서 관리 (Generational GC)

• Stop-The-World 발생 가능

💡 JavaScript: “즉시성 중심”

• 대부분 객체가 짧은 수명

• “도달 가능성(Reachability)” 기준으로 참조 해제

• UI 반응성을 위해 짧고 잦은 GC 수행

C/C++은 개발자가 직접 메모리를 해제해야 하지만, Java와 JS는 가비지 컬렉션(GC)을 통해 자동으로 관리한다. 단, Java는 객체의 수명(세대)을 기준으로, JS는 참조 여부를 기준으로 해제한다.