<aside> 📌 유효하지 않은 메모리인 가비지 발생, 그럼 JVM의 가비지 컬렉터가 불필요한 메모리를 정리한다. 대신 자바에서는 명시적으로 불필요한 데이터를 표현하기 위하여 null 선언 JAVA나 Kotlin에서는 메모리 누수를 막기 위하여 주기적으로 메모리를 검사하여 정리해준다.

</aside>

Major GC - Minor GC

<aside> 📌 JVM의 Heap 영역은 두가지 전제 조건으로 설계되었다. 1. 대부분의 객체는 금방 접근이 불가능한 상태가 된다. 2. 오래된 객체에서 새로운 객체로의 참조는 아주 적게 존재한다. ⇒ 객체는 대부분 일회성이며, 메모리에 남는 경우는 드물다. 따라서 생존기간에 따라 물리적으로 Young, Old 두 가지 영역으로 나누었다.

</aside>

Old - *Young*

Old

• Young 영역에서 Reachable 상태를 유지하여 살아남은 객체가 복사되는 영역
• Young 영역보다 초기 크게 할당 되며, 영역이 큰 만큼 가비지는 적게 발생
• Old 영역에 대한 가비지 컬렉션을 Major GC라고 부른다.

*Young*

• 새롭게 생성된 객체가 할당되는 영역
• 대부분 객체가 금방 접근 불가 상태가 되기 때문에, 많은 객체가 Young 영역에 생성되었다가 사라진다.
• Young 영역에 대한 가비지 컬렉션을 Minor GC라고 부른다.

<aside> ❓ Young 보다 Old가 더 큰 이유?? Young 영역의 수명이 짧은 객체들은 큰 공간이 필요하지 않으며 큰 객체들은 Young 영역이 아니라 Old에 할당

</aside>

<aside> ❓ 드물게 Old영역에서 Young 사라진 객체를 참조한다면? 이러한 경우를 대비하여 Old 영역에는 512bytes의 덩어리로 된 카드 테이블 존재

</aside>

<aside> ❓ Card Table? Old 영역에서 Young 영역으로 참조가 일어날 때 마다 그에 대한 정보를 표시하는 곳 도입 이유는 Old에서 사용되는 Young 영역의 객체를 확인하기 위하여 Old를 전부 검사하는 것은 비효율적 그래서 따로 조회용 테이블을 만듦 Young 영역에 대한 GC가 실행될 때에는 Card Table 조회를 통하여 GC 대상인지 검사

</aside>

가비지 컬렉션의 동작 방식

<aside> 📌 기본적으로 Young과 Old 영역은 서로 다른 메모리 구조로 되어 있기 때문에, 세부적인 동작 방식은 다르다. 하지만 기본적으로 가비지 컬렉션이 실행된다 하면 공통적인 2단계를 따른다.

1. Stop the World
2. Mark and Sweep

</aside>