GarbageCollector

GC 모니터링 가비지 컬렉션은 많은 Java 개발자들을 편하게 만들어 줬지만, 동시에 내부에서 일어나고 있는 일을 파악하기 어렵게 만들었다. 단독으로 실행하는 데스크탑 어플리케이션이나 사용자가 적은 백오피스 서버의 경우 문제가 되지 않지만, 사용자가 많은 서비스에서 성능을 극한까지 끌어올려야 하는 경우는 다르다. JVM 런타임 메모리에서는 어떤 일이 일어나고 있는지, 가비지 컬렉터는 어떻게 동작하는지 알고있어야 제대로 튜닝할 수 있다. 따라서 GC를 모니터링할 수 있는 도구가 필요하다. GC 로그 가장 기본적인 방법이자, 가장 중요한 것은 GC 로그를 출력하는 것이다. GC 로그는 메모리 할당에 실패한다거나, Full GC가 일어나는 등 특정한 이벤트가 발생할 때마다 기록된다. 이렇게 로그를 기록하는 것..

G1GC(Garbage-First GC) G1GC는 충분히 큰 메모리를 가진 멀티프로세서 환경을 위한 가비지 컬렉터이다. CMS GC처럼 STW에 의해 멈추는 시간을 최소화하면서도, thourghput 저하를 최소화하도록 만들어졌다. Java 9부터 최신버전(현재 20)까지 기본 가비지 컬렉터로 사용되고 있다. 그만큼 일반적인 상황에서 성능이 좋고 안정적이라는 뜻이다. G1GC는 이전 글에서 설명한 것들과 대부분 비슷한 특징을 갖는다. latency가 짧고, 일부 동작은 어플리케이션과 동시에 실행되며, STW도 발생한다. 또한, 세대별 가설을 따라 Young, Old 영역을 가지며, 대부분의 GC는 Young 영역에서 일어나고 가끔 일어나는 Old GC는 비교적 오래 걸린다. 여기까지는 일반적인 GC와 ..

가비지 컬렉션의 원칙 Java는 가비지 컬렉션을 이용해 메모리를 회수하지만, JVM 스펙에는 구체적인 구현에 대한 어떠한 정보도 없다. 따라서 JVM 종류에 따라 다양한 구현체가 존재하고, 필요에 따라 탈착형으로 바꿀 수도 있다. 구현에 대한 제약이 없다보니 심지어 Epsilon GC같이 메모리를 회수하지 않는 가비지 컬렉터도 있다. 그러나 이러한 특별 케이스를 제외하면 메모리 회수에 대한 큰 원칙이 2가지 있다. 하나는 사용하지 않는 메모리는 결국 회수되어야 한다는 것이다. 언제 어떤 방식으로든 회수되지 않으면 낭비되는 메모리가 쌓이다가 결국 어플리케이션이 필요한 메모리를 할당받지 못하고 에러를 발생시킬 것이다. 따라서 가비지 컬렉터는 할당된 메모리들을 모두 관리하면서 사용중인지 검사하고, 더이상 사용..