Java의 GC

가비지 컬렉션(GC)의 필요성과 알고리즘

가비지 컬렉션(GC) 이란?

GC는 메모리 관리 기법 중 하나로, 프로그램이 더 이상 필요로 하지 않는 메모리를 자동으로 해제해 주는 기능입니다. 우리가 흔히 GC가 관리한다고 말하는 메모리는 프로그램 실행 중 동적으로 할당되는 힙(Heap) 영역을 의미하고, GC가 해제하는 대상은 어떤 변수에서도 참조되지 않는 메모리 공간입니다. 

 

C나 C++같은 언어에서는 개발자가 직접 메모리를 할당하고 해제해야 했습니다. 하지만 수동으로 메모리를 관리하는 건 꽤 번거로울 뿐 아니라 메모리 누수(Memory Leak)가 발생할 수 있습니다. 또한 이미 해제된 메모리에 접근하거나 다시 해제하려면 오류가 발생할 수 있습니다. Java에서는 이런 작업을 알아서 처리해주기 때문에 개발자의 부담을 덜어줍니다. 

 

이를 통해 메모리 관리 실수로 인한 오류를 방지할 수 있고, 개발자는 비즈니스 로직 구현에 집중할 수 있습니다. 하지만 단점도 존재하는데, GC가 어떤 메모리를 해제할 지 검사하는 과정 자체가 프로그램 실행을 방해하는 오버헤드로 작용할 수 있고, 메모리가 언제 해제될 지 예측하기도 어렵습니다. 그래서 실시간성이 중요한 프로그램에서는 GC를 사용하는게 적절하지 않을 수 있습니다. 

 

그렇다면 GC는 어떻게 해지할 동적 메모리를 알아서 판단하게 될까요? 

 

가비지 컬렉션(GC)의 알고리즘

GC는 알고리즘을 통해 동적 메모리를 해제하는데 대표적으로 레퍼런스 카운팅 방식과 마크 앤 스윕 방식이 있습니다. 

 

1. 레퍼런스 카운팅(Reference Counting)

레퍼런스 카운팅 방식은 힙 영역의 인스턴스들이 각자 자신에게 접근 가능한 레퍼런스의 개수를 세어 저장하고, 해당 숫자가 0이 되면 정리해야 하는 인스턴스로 판단하고 메모리를 해제하는 방식입니다. 즉, 레퍼런스 카운트가 0이 되면 GC의 대상이 되는 것입니다. 

 

 

하지만 이 방식에는 큰 단점이 있는데, Root Space와 연결되어 있지 않더라도 인스턴스들끼리 서로가 서로를 참조하는 순환 참조(Circular Refrence)가 일어나게 되면 레퍼런스 카운트가 1로 유지되기 때문에 메모리 누수가 발생할 수 있습니다. 

 

이러한 이유 때문에 레퍼런스 카운팅 방식보다는 순환 참조 문제를 해결할 수 있는 마크 앤 스윕 방식을 많이 사용하고 있습니다. 

 

2. 마크 앤 스윕(Mark-and-Sweep)

마크 앤 스윕 방식은 Root space에서 시작해 그래프 탐색을 통해 객체에 접근 가능한지 여부를 확인하고, 이를 해제의 기준으로 삼습니다. Root space에서부터 연결된 인스턴스를 찾아 마크하고, Root space로부터 접근할 수 없는 인스턴스는 스윕하여 메모리에서 정리하는 방식입니다. 

 

이 방식은 순환 참조가 발생하더라도, Root space로 부터 연결이 끊어진 객체들을 모두 정리할 수 있는 장점이 있습니다. Java에서도 이러한 마크 앤 스왑 방식을 채택하여 가비지 컬렉팅을 수행하고 있습니다. 

 

하지만 이 방식에도 단점이 존재합니다. 래퍼런스 카운팅 방식과 달리, GC를 의도적으로 실행해야 하므로, 애플리케이션이 실행중일 때 가비지 컬렉션이 수행되기 위해서 특정 시점에 컴퓨팅 리소스를 할당해주어야 합니다. 이는 애플리케이션 성능에 영향을 끼치기 때문에 이 시간을 최소화하는 것이 최적화의 핵심입니다. 

 

JVM에서의 가비지 컬렉션(GC) 과정

이제 Java 프로그램이 돌아가는 JVM에서 어떻게 가비지 컬렉팅을 진행하는지 알아보겠습니다. 

 

JVM의 GC는 기본적으로 마크 앤 스왑 방식으로 동작합니다. 마크 앤 스왑 방식은 Root Space에서 부터 해당 객체에 접근이 가능한지가 해제의 기준이 되는데, 이때 Root space는 JVM 메모리의 Stack의 로컬 변수, Method Area에 저장된 스택 변수, Native Stack의 C, C++로 작성된 JNI 참조입니다. 

 

JVM의 GC와 힙 영역

JVM의 GC는 의도적으로 마크 앤 스왑을 동작시켜야 하며, 언제 해당 작업을 수행하는 지 파악해야 합니다. 이 과정을 이해하기 위해서는 JVM의 힙 영역에 대한 이해가 필요합니다. 

 

JVM의 힙 영역은 크게 두 가지로 나뉘며, Young generation과 Old generation으로 구분됩니다. 이때 Young generation에서 발생하는 GC를 Minor GC, Old generation에서 발생하는 GC를 Major GC라고 합니다. 

 

 Young generation은 또 다시 세 영역인 Eden, Survival 0, Survival 1 영역으로 나뉘게 됩니다. Eden 영역은 새롭게 생성된 객체들이 할당되는 영역이고, Survival 영역은 Minor GC로 부터 살아남은 객체들이 존재하는 영역입니다. 이 Survival 영역에는 특별한 규칙이 있는데, Survival 0 혹은 Survival 1 둘 중 하나는 꼭 비어있어야 한다는 것입니다. 이 규칙 때문에 Survival 영역은 마크 앤 스왑이 발생할 때마다 번갈아 가면서 사용되게 됩니다. 

 

JVM의 GC 과정

먼저 객체를 생성하게 되면 위의 사진과 같이 Eden 영역에 인스턴스들이 생성되게 됩니다. 이렇게 새로운 객체가 생성되다보면 Eden 영역이 꽉차는 순간이 오게되는데 이때 Minor GC가 발생합니다. 

💡 Survival 0/Survival 1 영역도 가득 차면 순간이 발생하면 Minor GC가 발생합니다.

 

Minor GC를 통해 Young generation에 마크 앤 스왑을 진행하게 되며 Root space로 부터 연결 가능한 객체라 판단되는 객체들은 Survival 0 영역으로 옮겨지면서 Age Bit이 1증가하게 됩니다. 

 

Age Bit은 일정 수준을 넘어가게 되면 오래도록 참조될 객체라고 판단하여 해당 객체를 Old generation으로 넘겨주게 됩니다. 이 과정을 프로모션(Promotion)이라 합니다. Java 8의 Parallel GC 방식 사용 기준 Age Bit이 15가 되면 프로모션이 진행됩니다. 

 

시간이 많이 지나게 되면 Old generation도 다 채워질 때가 있습니다. 이때 Major GC가 발생하면서 마크 앤 스윕 방식을 통해 필요없는 메모리들을 비워주게 됩니다. 이 Major GC는 Minor GC보다 더 오랜 시간이 소요되게 됩니다. 

 

그렇다면 왜 굳이 힙 영역을 Young generation과 Old generation으로 나누었을까요? 

위 사진에서 보듯이 Minor collections가 Major collections보다 훨씬 많이 생존해있는 것을 확인할 수 있습니다. 이처럼 대부분의 객체는 생성된 후 곧바로 삭제되기 때문에, GC 설계자들은 애플리케이션을 분석한 결과 대부분의 객체들이 짧은 생애를 갖는다는 사실을 알게 되었습니다. 따라서 이러한 객체들이 빠르게 사라지므로, Young generation 영역에서 최대한 효율적으로 처리하는 방식으로 설계한 것입니다.