[Java] 가비지 컬렉션(Garbage Collection)

C/C++ 프로그래밍을 할 때 메모리 누수(Memory Leak)를 막기 위해 객체를 생성한 후 사용자하지 않는 객체의 메모리를 프로그래머가 직접 해제 해주어야 했지만, JAVA에서는 JVM(Java Virtual Machine)이 구성된 JRE(Java Runtime Environment)가 제공되며, 그 구성 요소 중 하나인 Garbage Collection(이하 GC)이 자동으로 사용하지 않는 객체를 파괴한다.

GC에 대해서 알아보기 전에 'stop-the-world'라는 용어를 알아야한다. 'stop-the-world'란, GC를 실행하기 위해 JVM이 애플리케이션 실행을 멈추는 것입니다. 어떤 GC 알고리즘을 사용하더라도 'stop-the-world'는 발생하게 되는데, 대개의 경우 GC 튜닝은 이 'stop-the-world' 시간을 줄이는 것이라고 한다다.

GC를 해도 더이상 사용 가능한 메모리 영역이 없는데 계속 메모리를 할당하려고 하면, OutOfMemoryError가 발생하여 WAS가 다운될 수도 있다. 행(Hang) 즉, 서버가 요청을 처리 못하고 있는 상태가 된다. 따라서 규모 있는 JAVA 애플리케이션을 효율적으로 개발하기 위해서는 GC에 대해 잘 알아야한다고 한다.

 

가비지 컬렉션(Garbage Collection)

JVM은 가비지 컬렉션이라는 프로세스를 통해 메모리를 관리한다. 가비지 컬렉션은 자바 프로그램에서 사용되지 않는 메모리를 지속적으로 찾아내서 제거하는 역할을 한다.

자바에서는 메모리를 GC라는 알고리즘을 통하여 관리(automatic memory management)하기 때문에, 개발자가 메모리를 처리하기 위한 로직을 만들 필요가 없고, 절대로 만들어서는 안된다.

자바에서 쓰레기는 객체이다. 하나의 객체는 메모리를 점유하고, 필요하지 않으면 메모리에서 해제되어야 한다. 

코드에서 a라는 객체가 만들어져 메모리의 한부분을 점유하게 되고, 특정 메소드 호출한 후 수행이 완료되어 해당 객체가 더이상 필요없는 객체, 쓰레기가 됩니다. 이 쓰레기 객체를 효과적으로 처리하는 작업을 GC(Garbage Collection)라고 한다.

• 시스템에서 가비지 컬렉션을 수행하는 부분을 가비지 컬렉터라 부른다.

JVM의 메모리는 총 5가지 영역(class, stack, heap, native method, PC)으로 나뉘는데, GC는 힙 메모리만 다룬다.

일반적으로 다음과 같은 경우에 GC의 대상이 됩니다.

1. 객체가 NULL인 경우 (ex. String str = null)
2. 블럭 실행 종료 후, 블럭 안에서 생성된 객체
3. 부모 객체가 NULL인 경우, 포함하는 자식 객체

• GC는 Weak Generational Hypothesis 에 기반한다.

 

메모리 해제 과정(3단계)

실행순서 : 참조되지 않은 객체들을 탐색 후 삭제(Marking) → 삭제된 객체의 메모리 반환(Normal Deletion) → 힙 메모리 재사용(Compacting)

1. Marking

• 프로세스는 마킹을 호출한다. GC가 메모리가 사용되는지 아닌지를 찾아낸다.
• 참조되는 객체는 파란색으로, 참조되지 않는 객체는 주황색으로 보여진다.
• 모든 오브젝트는 마킹 단계에서 결정을 위해 스캔되어진다. 모든 오브젝트를 스캔하기 때문에 매우 많은 시간을 소모하게 된다.

2. Normal Deletion

• 참조되지 않는 객체를 제거하고, 메모리를 반환한다.
• 메모리 Allocator는 반환되어 비어진 블럭의 참조 위치를 저장해두고 새로운 오브젝트가 선언되면 할당되도록 한다.

3. Compacting

• 퍼포먼스를 향상시키기 위해, 참조되지 않는 객체를 제거하고 또한 남은 참조되어지는 객체들을 묶는다.
• 이들을 묶음으로서 공간이 생기므로 새로운 메모리 할당 시에 더 쉽고 빠르게 진행 할 수 있다.

 

Generational Gabage Collection

세대 간의 GC

배경

위와 같이 모든 객체를 Mark & Compact 하는 JVM은 비효율적이다. 다음과 같은 그래프를 보면,

Y축은 할당된 바이트의 수이고 X축은 바이트가 할당될 때의 시간이다. 보시다시피 시간이 갈수록 적은 객체만이 남는다. 위와 같은 그래프에 기반한 것이 Weak Generational Hypothesis 이다.

Weak Generational Hypothesis

신규로 생성한 객체의 대부분은 금방 사용하지 않는 상태가 되고, 오래된 객체에서 신규 객체로의 참조는 매우 적게 존재한다는 가설
이 가설에 기반하여 자바는 Young 영역과 Old 영역으로 메모리를 분할하고, 신규로 생성되는 객체는 Young 영역에 보관하고, 오랫동안 살아남은 객체는 Old 영역에 보관한다.

영역

1. Young 영역(Yong Generation 영역)
   • 새롭게 생성한 객체의 대부분이 여기에 위치한다.
   • 대부분의 객체가 금방 접근 불가능 상태가 되기 때문에 매우 많은 객체가 Young 영역에 생성되었다가 사라진다.
   • 이 영역에서 객체가 사라질때 Minor GC 가 발생한다고 말합니다.
2. Old 영역(Old Generation 영역)
   • 접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사된다.
   • 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생합니다.
   • 이 영역에서 객체가 사라질 때 Major GC(혹은 Full GC) 가 발생한다고 말한다.
3. Permanet 영역
   • Method Area라고도 한다.
   • JVM이 클래스들과 메소드들을 설명하기 위해 필요한 메타데이터들을 포함하고 있다.
   • JDK 8부터는 PermGen은 Metaspace로 교체된다.

과정

1. 어떠한 새로운 객체가 들어오면 Eden Space에 할당한다.

   

2. Eden space가 가득차게 되면, minor garbage collection이 시작된다.

   

3. 참조되는 객체들은 첫 번째 survivor(S0)로 이동되어지고, 비 참조 객체는 Eden space가 clear 될 때 반환된다.

   

4. 다음 minor GC 때, Eden space에서는 같은 일이 일어난다. 비 참조 객체는 삭제되고 참조 객체는 survivor space로 이동한다.
   • 그러나 이 케이스에서 참조 객체는 두 번째 survivor space로 이동하게 됩니다.
   • 게다가 최근 minor GC에서 첫 번째 survivor space로 이동된 객체들도 age가 증가하고 S1 공간으로 이동하게 된다.
   • 한번 모든 surviving 객체들이 S1으로 이동하게 되면 S0와 Eden 공간은 Clear 된다.
   • 주의해야할 점은 이제 우리는 다른 aged 객체들을 서바이버 공간에 가지게 되었다는 것이다.
5. 다음 minor GC 때, 같은 과정이 반복 됩니다.
   1. 그러나 이번엔 survivor space들은 switch 된다.
   2. 참조되는 객체들은 S0로 이동한다. 살아남은 객체들은 aged되고 Eden과 S1 공간은 Clear 됩니다.
6. 아래 그램은 promotion을 보여준다.
   • minor GC 후 aged 오브젝트들이 일정한 age threshold(문지방)을 넘게 되면 그들은 young generation에서 old로 promotion 된다.
   • 여기서는 8을 예로 들었다.
7. minor GC가 계속되고 계속해서 객체들이 Old Generation으로 이동된다.
8. 아래 그림은 전 과정을 보여주고 있다.
   • 결국 major GC가 old Generation에 시행되고, old Generation은 Clear 되고, 공간이 Compact 되어진다.

 

Minor GC와 Major GC의 차이점

Minor GC는 Eden 영역에서 새로운 객체에 대해 작동이 된다. JVM이 새로운 객체를 생성할 때 메모리가 부족하면 발생되는 GC이다.

반면, Major GC는 Tenured 영역에서 작동이 된다. 대부분의 경우에 Minor GC가 발생되고 그 다음으로 발생된다.

Minor GC vs Major GC vs Full GC | Plumbr – User Experience & Application Performance Monitoring

 

한계

• 어떤 방식의 GC를 사용하든 실행 시간에 작업을 하는 이상 성능 하락을 피할 수 없다.
• 쓰레기 수집기가 존재하더라도 더 이상 접근이 불가능한 객체만 회수하기 때문에 메모리 누수는 발생할 수 있다.
  • 메모리 누수(memory leak) 현상은 컴퓨터 프로그램이 필요하지 않은 메모리를 계속 점유하고 있는 현상이다. 할당된 메모리를 사용한 다음 반환하지 않는 것이 누적되면 메모리가 낭비된다. 즉, 더 이상 불필요한 메모리가 해제되지 않으면서 메모리 할당을 잘못 관리할 때 발생한다.

 

참고

• https://gyoogle.dev/blog/computer-language/Java/Garbage%20Collection.html
• https://12bme.tistory.com/57
• https://helloino.tistory.com/7
• https://blog.metafor.kr/163
• https://ko.wikipedia.org/wiki/%EB%A9%94%EB%AA%A8%EB%A6%AC_%EB%88%84%EC%88%98