예전에 GC(Garbage Collection) 에 대해 간단히 정리한 적이 있지만, 내용이 다소 얕았던 것 같아 이번에 다시 깊이 있게 정리해보려 한다. GC는 자바 메모리 관리에서 매우 중요한 개념이기 때문이다.

📌 JVM(Java Virtual Machine)

자바의 Garbage Collection(GC) 은 JVM이 메모리를 자동으로 관리하기 위한 핵심 메커니즘이다.
이 개념을 제대로 이해하려면 먼저 JVM의 구조와 메모리 영역에 대해 알아둘 필요가 있다.

우선 JVM 동작 구조에 대해 정리할려고 한다.

1. 개발자가 소스코드를 작성하면, 컴파일러가 이를 바이트코드(Bytecode) 로 변환한다.

2. 이후 클래스 로더(Class Loader) 가 동적 로딩(Dynamic Loading) 을 통해 필요한 클래스들을 Runtime Data Area(프로그램 실행 시 실제 메모리가 할당되는 영역)에 로드하고 링크한다.

3. Runtime Data Area에 로드된 바이트코드는 Execution Engine(실행 엔진) 에 의해 해석되어 실행된다.

4. 이 과정에서 Execution Engine 은 Garbage Collector(GC) 를 동작시켜 메모리를 자동으로 관리하고, 동시에 스레드 동기화(Thread Synchronization) 등의 작업도 수행한다.

JVM 구조

이처럼 JVM은 아래와 같이 구성되어 있다.

• 클래스 로더(Class Loader)

• 실행 엔진(Execution Engine)

  • 인터프리터(Interpreter)
  • JIT 컴파일러(Just-in-Time)
  • 가비지 콜렉터(Garbage collector)

• 런타임 데이터 영역 (Runtime Data Area)

  • 메소드 영역
  • 힙 영역
  • PC Register
  • 스택 영역
  • 네이티브 메소드

• JNI - 네이티브 메소드 인터페이스 (Native Medthod Interface)

• 네이티브 메소드 라이브러리 (Native Method Library)

---

클래스 로더(Class Loader)

클래스 로더(Class Loader)는 로딩, 링크, 초기화 단계로 나뉘어져 있다.

로딩

• 자바 바이트 코드(.class)를 메서드 영역에 저장
  • 로드된 클래스를 비롯한 그의 부모 클래스 정보
  • 클래스 파일과 Class, Interface, Enum의 관련 여부
  • 변수나 메서드등의 정보

링크

• 검증: 읽어들인 클래스가 JVM 명세에 명시된 대로 구성되어 있는지 검
• 준비: 클래스가 필요로 하는 메모리를 할당
• 분석:클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경

초기화

• 클래스 변수들을 적절한 값으로 초기화( static 필드들을 설정된 값으로 초기화 등 )

---

실행 엔진(Execution Engine)

자바 바이트 코드(.class)는 기계가 바로 수행할 수 있는 언어보다는 가상 머신이 이해할 수 있는 중간 레벨로 컴파일 된 코드이기 때문에 실행 엔진(Execution Engine)이 기계가 실행 할 수 있는 형태로 변경해준다.

실행 엔진(Execution Engine)은 인터프리터와 JIT 컴파일러 두가지 방식을 혼합하여 바이트 코드를 실행한다.

인터프리터(Interpreter)

• 바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행한다.
• JVM안에서 바이트 코드는 기본적으로 인터프리터 방식으로 동작하지만 같은 메서드라도 여러번 호출이 된다면 매번 해석하고 수행해야 되서 전체적인 속도는 느리다.

🤔 C, C++ 같은 언어는 컴파일러를 통해 기계어로 직접 변환되므로, 인터프리터 없이 실행 속도가 빠르다.

JIT 컴파일러(Just-In-Time Compiler)

인터프리터(Interpreter)의 단점을 보완하기 위해 도입된 방식으로 반복 코드가 발견되면 바이트 코드 전체를 컴파일 하여 Native Code로 변경하고 이후에는 해당 메서드를 더 이상 인터프리트 하지 않고 캐싱 해두었다가 Native Code로 직접 실행하는 방식이다.

실행 속도가 인터프리터(Interpreter)보다 빠르다.

🤔 Native Code란, CPU가 직접 실행할 수 있는 기계어 코드(Machine Code)를 의미한다.

Garbage Collector

JVM(Java Virtual Machine)은 Garbage Collector를 통해 Heap 메모리 영역에서 더이상 사용하지 않는 메모리를 자동으로 회수해준다. 이 부분은 뒤에서 더 자세하게 정리할려고 한다.

---

런타임 데이터 영역 (Runtime Data Area)

JVM(Java Virtual Machine)의 메모리 영역으로 자바 애플리케이션을 실행할 때, 사용되는 데이터들을 적재하는 영역이다.

Method Area

• 클래스 정보, 메서드 코드, 상수, static 변수 등을 저장하는 영역
• JVM이 실행되는 동안 공유되는 메모리 영역
• Runtime Constant Pool도 포함되어 있어, 클래스나 인터페이스의 상수, 문자열, 메서드 참조 등을 저장

Heap

• JVM에서 생성되는 모든 객체와 배열이 저장되는 영역
• GC(Garbage Collector)가 관리하는 주요 영역
• 객체의 생명주기에 따라 메모리가 할당되고, 더 이상 참조되지 않으면 GC에 의해 회수된다.

Heap영역은 메서드 영역과 함께 모든 스레드가 공유하며, JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다.

즉, new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타임등 Reference Type이 저장되는 곳이다.

유의할 점은, 힙(Heap) 영역에 생성된 객체와 배열은 모두 참조 타입(Reference Type) 으로서, JVM 스택(Stack) 영역의 변수나 다른 객체의 필드에서 참조된다는 점이다.

즉, 힙에 생성된 객체의 참조 주소는 스택이 가지고 있으며, 스택에 있는 참조 변수를 통해서만 힙 영역의 인스턴스에 접근하고 조작할 수 있다.

다시 말해, 힙의 객체는 스택의 참조 타입 변수와 연결되어 있는 구조이다.

예를 들어 그림을 보면, 스택에는 name, party, birth, weight 네 개의 변수가 존재한다.

이 중 birth(200406)와 weight(3.5)는 기본 타입으로 스택 안에 값이 직접 저장되어 있지만,

name과 party는 참조 타입으로 각각 100번지와 200번지의 주소값만 가지고 있다.

이 주소를 따라가면 힙 영역의 "심두리"(100번지)와 "강아지"(200번지) 객체를 찾을 수 있다.

즉, 스택의 name 변수를 통해서만 힙에 있는 "심두리" 객체를 조작할 수 있고, party 변수 역시 "강아지" 객체를 참조하고 있는 것이다.

그런데 만약 name 변수를 제거하거나 다른 객체를 참조하게 되면 힙의 "심두리" 객체는 더 이상 어떤 변수에서도 참조되지 않게 된다.

이렇게 참조하는 스택 변수나 필드가 사라진 객체는 의미 없는 데이터가 되어 쓰레기 객체(Garbage Object) 로 취급된다.

이때 JVM은 가비지 컬렉터(Garbage Collector) 를 실행하여 이런 쓰레기 객체를 힙 영역에서 자동으로 제거함으로써 불필요한 메모리를 정리하고 효율적으로 관리한다.

🤔 GC를 의도적으로 System.gc()를 사용하여 호출 가능하지만, 오버헤드가 굉장히 크므로 Garbage Collector에게 메모리 해제를 믿고 맡기는걸 추천

이처럼 Heap영역은 가비지 컬렉션(GC) 대상이 되는 공간이고, 효율적인 가비지 컬렉션(GC)을 수행하기 위해 크게 Young Generation, Old Generation으로 나눈다.

Young Generation

생명 주기가 짧은 객체를 가비지 컬렉션(GC) 대상으로 하는 영역

• Eden: new를 통해 새로 생성된 객체가 위치, 정기적인 쓰레기 수집 후 살아남은 객체들을 Survivor로 디동
• Survivor 0 / 1: 각 영역이 채워지게 되면, 살아남은 객체는 비워진 Survivor로 순차적 이동
• Minor GC가 발생

Old Generation

생명 주기가 긴 객체를 GC대상으로 하는 영역, Young Generation에서 마지막까지 살아남은 객체가 이동

• Major GC(Full GC)가 발생

🤔 왜 굳이 Young Generation과 Old Generation으로 나눴을까?
GC 설계자들은 애플리케이션을 분석한 결과, 대부분의 객체가 수명이 짧다는 사실을 발견했다. GC는 실행 자체가 비용이 드는 작업이므로, 메모리 전체를 탐색하기보다는 특정 영역만 검사하여 해제하는 것이 효율적이다. 따라서 상대적으로 금방 사라지는 객체가 많은 Young Generation에서 우선적으로 메모리를 회수하도록 설계되었다.

가비지 컬렉션(GC)에서 사용하는 알고리즘

1. Reference Counting

그림에서 Root Space는 스택 변수나 전역 변수처럼 힙에 있는 객체를 가리키는 시작점 역할을 하는 공간이다.

Reference Counting 방식에서는 힙에 있는 각 객체가 참조되는 횟수(reference count)를 가지고 있다고 생각하면 된다. 이 숫자는 해당 객체에 접근할 수 있는 경로가 몇 개인지를 나타낸다. 만약 참조 횟수가 0이 되면, 더 이상 객체에 접근할 수 없으므로 메모리에서 해제된다. Swift가 이 방식을 사용해 메모리를 관리한다.

하지만 Reference Counting은 순환 참조(Circular Reference) 문제를 가질 수 있다. 예를 들어, Root Space에서 모든 힙 객체에 대한 참조를 끊어도, 서로 참조하고 있는 객체들이 있다면 그들의 reference count는 0이 되지 않고 그대로 남는다. 그림 속 노란색 고리 안의 객체들이 이런 경우다. 결과적으로 더 이상 사용하지 않는 객체임에도 메모리에서 해제되지 않아 메모리 누수가 발생한다.

2. Mark and Sweep

Mark and Sweep 알고리즘은 Root Space에서 시작해 객체에 접근할 수 있는지 여부를 기준으로 메모리를 해제한다.

Root Space에서 연결된 객체를 탐색(Mark)하고, 연결되지 않은 객체는 제거(Sweep)한다. Root Space에서 닿을 수 있는 객체는 Reachable, 닿을 수 없는 객체는 Unreachable로 구분된다.

Mark and Sweep 방식을 사용하면 Reference Counting 방식에서 문제가 되는 순환 참조 객체도 안전하게 제거할 수 있다. 실제로 Java와 JavaScript가 이 방식을 사용해 메모리를 관리한다.

하지만 단점도 있다. Reference Counting처럼 객체가 필요 없어진 즉시 지워지지 않고, GC를 특정 시점에 실행해야 한다는 점이다. 즉, 애플리케이션이 실행되는 동안 GC가 리소스를 사용하므로, 성능과 사용자 경험을 고려해 적절히 GC를 실행하는 전략이 필요하다.

• Mark and Sweep은 의도적으로 GC를 실행해야한다.
• Mark and Sweep은 애플리케이션과 GC 실행이 병행 된다.

Mark and Sweep과 JVM GC 특징 요약

Mark and Sweep 방식에서는 애플리케이션과 GC가 동시에 실행될 수 있다.

Serial GC

• 단일 스레드로 GC 실행 → STW 시간이 길다.
• 작은 힙과 싱글 코어 환경에 적합.
• Compaction 수행.

Parallel GC

• 여러 스레드로 GC 실행 → STW 시간 단축
• 멀티 코어 환경에서 애플리케이션 처리 속도 향상.
• Java 8 기본 GC

CMS GC (Concurrent-Mark-Sweep)

• 대부분의 GC 작업을 애플리케이션과 동시에 수행 → STW 최소화
• 메모리와 CPU를 많이 사용, Compaction 기본 제공 X → 장기 운영 시 메모리 단편화 가능
• Java 9부터 deprecated, Java 14 이후 사용 중단.
• 단계: Initial Mark → Concurrent Mark → Remark → Concurrent Sweep

G1 GC (Garbage First)

• 힙을 여러 Region으로 나누어 Young/Old Generation으로 관리
• 필요에 따라 Region 개수를 동적으로 조정 → STW 최소화
• Java 9 이상 기본 GC

🤔 GC 실행을 위해 애플리케이션을 멈추는 것을 Stop The World(STW)라고 한다.

Stack

• 각 스레드마다 생성되는 스레드 전용 영역

• 메서드 호출 시 생성되는 프레임(Frame) 을 저장하고, 지역 변수, 매개변수, 연산 중간 값 등을 관리

• 메서드가 종료되면 해당 프레임은 제거됨

PC Register

• 각 스레드마다 독립적으로 존재

• 현재 실행 중인 JVM 명령어 주소(Program Counter) 를 가리킴.

• 메서드 호출과 복귀 시 JVM이 어디서 실행 중인지 추적하는 용도로 사용

Native Method Stacks

• C/C++로 작성된 네이티브 메서드(Native Method)를 위한 스택 영역

• JVM 내부에서 Java가 아닌 외부 라이브러리를 호출할 때 사용

• 스레드마다 독립적으로 존재하며, 로컬 변수와 호출 정보를 관리

---

참고

• JVM 구조
• ☕ JVM 내부 구조 & 메모리 영역 💯 총정
• [Java] GC(Garbage Collection)이란?