그래도 자바 최신 버전이 좋은 이유, GC.

썸네일 출처: Java Garbage Collection Types and Settings in Jelastic PaaS

내가 이 글을 작년 초에 작성해놓고 방치하다니 나란 놈은 정말 미친놈 아닌가... 아 망할 삼성...

어쩌면 자바 버전 가지고 지랄하는 글의 종지부를 찍을 수 있을 지 모르겠지만,
자바 8을 쓸 수밖에 없었던 현실 글을 쓰고 나니, 나도, 독자도, 아마 현타가 왔을 것이다.
하지만 몇몇 업체에서는 "지랄 우린 17 쓴다 어디서 구버전 선동이냐" 이런 반응도 일부 있었지만... 그래... 정말 일부였다.

시작하며

자, 이 글을 읽고 나서 그래도 양심(?)이 있으면 신규 프로젝트에 자바 8을 지속적으로 쓰는 일이 없어지길 바란다.
얘들아... 어자피 자바 프로젝트 할 때 너네들 어자피 웹 서버 프로젝트 할거잖아.
웹 어플리케이션 구성하는데 자바 버전이 중요한 이유가 뭐냐? 말해봐.

10년 이상 오래된 서버에서 구동해야 할 경우

아무리 고도화 프로젝트를 한 들, 서버를 교체하는 비용도 포함한다. 이는 구형 장비에 대한 잠재적인 하드웨어를 포함한 장애를 최소화하기 위함이다.
물론 10년된 장비에 자바 17을 구동한다는 건 무리긴 하다.
하지만, 신규 프로젝트에 그런 시나리오가 있다면, 돈 아낀다는 핑계로 까먹으려는 상도덕 애미리스인 프로젝트이므로 런각 재도록 하자.
거기서 프로젝트 하면, 하드웨어 문제조차 개발자에게 책임 떠넘길 확률 속이꽉찬남자 99.9%다.

익숙함이 우선이어야 할 경우

기존에 있던 시니어나 결정권자가 신규 프로젝트에서 아키한테 합당한 이유도 대지 않고 자바 버전에 대한 태클이 심하다면, 이 또한 런각이다. 기본적으로 불통과 아집이 심하므로, 미련을 버리고 떠나도록 하자.
익숙함은, 그저 그들에게만 유리한 조건이고, 너희들에게 절대 유리한 조건은 없다.
변화를 싫어하고, 날로 먹는 식으로 지속적인 월급루팡이라 해도 지나치지 않는 말이다.

GC와 자바 버전

이제 본론으로 들어가서, 자바 버전 선택을 결정지을 가비지 콜렉터를 간단하게 알아보도록 한다.
당연하겠지만 자바 GC에 대한 글은 구글이나 네이버 검색해도 좌르륵 나올 정도로 자바 개발자들에게는 기본적으로 알아야 할 지식이다. 하지만, 언제부터 적용하는지, 무슨 GC가 좋을지에 대한 글은 찾아보기 힘들다. 오늘 그걸 내가 가르쳐주도록 하겠다.
물론 결론은 그냥 최신 버전 쓰는게 최신 GC 효율성으로 인한 운영의 유리함이지만...

Mark and Sweep 이라는 용어를 알거나 숙지하고 있으면, GC에 대한 지식은 반 이상 가지고 있다고 해도 무방하다. 이녀석을 점찍어뒀다가(Mark), 어? 이제 쓸 일 없어졌네? 치운다(Sweep).
이제 시작하도록 하자.

직렬 가바지 콜렉터(Serial Garbage Collector)

이름만 들어도 그냥 한 쓰레드 가지고 놀 것 같은 느낌이 팍 드는 가바지 콜렉터가 되겠다.
이녀석은 자바가 시작됐을 때 나왔기 때문에 자바 역사와 함께하는 콜렉터이기도 하다.
당연히 싱글 스레드기 때문에 싱글 스레드에 대한 장단점이 매우 명확하다.

초기 자바 시절 CPU부터가 싱글 스레드가 대부분이었고, 그런 환경에서 태어나서 그렇지, 자바 어플리케이션이 멀티 스레드를 주로 사용할 경우, 생각 외로 오버헤드가 적은 콜렉터다.
하지만 스레드를 하나 가지고 지지고 볶기 때문에 성능 측면에서는 어쩔 수 없는 부분이기도 하다. 왜냐면 이 콜렉터가 돌아가기 시작하면 메인 스레드를 쳐먹기 때문에 앱이 일시적으로 동작이 멈추기 때문이다. 따라서 이 콜렉터를 이용할 경우 아래의 시나리오를 추천한다.

• Java로 만들어 클라이언트가 직접 운용하는 작은 규모의 응용 프로그램
• 당연하겠지만 싱글 스레드 기반의 절차지향적 콘솔 프로그램
• 임베디드 앱

병렬 가비지 콜렉터(Parallel Garbage Collector)

멀티 스레드 시대가 오고 나서 생긴 가비지 콜렉터다. 자바 1.4도 사용 가능할 정도로 오래됐으니 너무 걱정은 말자. 위 콜렉터 다음에 나왔기 때문에 얘 또한 역사가 길다. 게다가 자바 8까지 기본으로 채용되는 가비지 콜렉터다.
당연히 당시 시대에 맞게 멀티 스레드를 사용한다. 따라서 멀티 스레드를 적극적으로 이용하는 자바 앱에게는 오버헤드가 그만큼 발생한다는 게 단점이다.
대신, 멀티스레드기 때문에 찍고 치우는 속도도 빠르다.

직렬이 지연율(Latency) 위주의 콜렉터라면, 병렬은 처리량(Throughput) 위주의 콜렉터라고 보면 된다. 두 콜렉터의 장단점이 아주 명확하다는 뜻이 되겠다.

이 콜렉터는 자바 8까지 기본적으로 사용하는 가비지 콜렉터가 되겠다.
이 콜렉터를 이용할 경우 아래 시나리오를 추천한다.

• 데이터 처리가 자주 발생하는 응용 프로그램
• 중규모 서버
• 멀티 스레드가 필요할 정도의 동시성이 중요한 프로그램

Concurrent Mark Sweep(CMS) 가비지 콜렉터

얘는 말 그대로 아예 동시다발적으로 찍고 치우는 가비지 콜렉터가 되겠다. 따라서 이녀석의 처리속도는 매우 빠르며, 자바 8까지 사용 가능한 가비지 콜렉터다. 자바 9부터 폐기 예정이며 자바 14에 완전히 폐기되었다.
컨셉부터가 적은 지연율로 빠른 처리를 지향하기 때문에 너희들이 자바에 많이 쓰는 웹 어플리케이션에 가장 딱 맞는 가비지 콜렉터인데... 이녀석은 쉬지 않고 찾고 치우려 하기 때문에 크롬처럼 메모리를 심심하면 쳐묵하는 콜렉터다. 재수없으면 누수는 덤. 따라서 넉넉한 힙(Heap) 사이즈를 확보하고 운용하는 것이 좋겠는데... 근데 굳이 이것보단 후술할 콜렉터 사용을 추천한다. 툭하면 OutOfMemoryError 뜨는 걸 보고 싶다면 추천한다.

이 콜렉터를 이용할 경우 아래 시나리오를 추천한다.

• 대규모 서버
• 많은 데이터 처리량이 필요한 응용 프로그램
• 하지만 이런 시나리오가 여유로운 메모리를 보유한 환경에서 운용 가능한 프로그램

Garbage First(G1) 가비지 콜렉터

이녀석부터 존재감이 없는 가비지 콜렉터다. 하지만 이녀석도 생각보다 오래된게 자바 7부터 나왔다. 물론 7 나오자마자 나온 건 아니고 4번째 업데이트부터 나온 녀석이다.
이녀석은 위에 CMS의 메모리 쳐묵하는 단점을 보완한 가비지 콜렉터다. 따라서 CMS 시나리오에 그대로 차용할 수 있으며, 자바 8에도 사용 가능한 가비지 콜렉터다.
이 콜렉터의 특징은 Region 이라는 특정 공간 사용에 있는데, 들어오는 대로 처리하는게 아니라 빈도에 따라 처리하는 특징을 가지고 있다. 따라서 CMS에 비해 처리량이 낮은 것이 아쉬운 점이 되겠다. 그래도 증권 같은 실시간 처리 등에도, 많은 데이터 처리량에도 좋은 선택이긴 한데, 이 효과를 누리려면 적어도 4GB 이상의 힙 메모리 사용이 필요하기 때문에 클라우드나 컨테이너에서는 적절하지 않은 선택일 수 있다.

Shenandoah 가비지 콜렉터

얘는 레드햇이 개발하고 자바 12부터 사용 가능한 가비지 콜렉터로, 아마 여기서부터는 한국어로 된 소개 문서를 찾기 어려울 것이다.
이 콜렉터는 CMS가 가진 단편화 문제와 G1이 가진 중단 시간을 모두 보완한 가비지 콜렉터인데, 얘가 가진 가장 큰 특징은, 힙 사이즈와 상관없이 일정한 중단 시간을 추구한다는 점이 되겠다. 왠만한 가비지 콜렉터가 가지지 못한 재밌는 점이 되겠다. 작은 스케일로도 운용 가능하기 때문에, 클라우드나 컨테이너로 자바 17 운용 시 이 가비지 콜렉터를 추천하도록 하겠다.

Z 가비지 콜렉터

현존하는 가장 최신의 가비지 콜렉터로, 자바 11부터 나왔지만, 자바 11 당시에선 실험적 기능이었고, 리눅스 전용이었다가, 자바 14에 맥과 윈도우 지원이 나오고 나서야 자바 15 버전부터 안정화되어 사용 가능하여, 실질적으로 자바 17부터 사용 가능한 가비지 콜렉터다.
얘는 ZPage 라고 G1의 Region을 개선한 페이징 방식을 사용하는데, 정적 크기를 가진 Region에 비해 2배수로 동적 공간을 가질 수 있기에 어떤 스케일에서도 유연한 동작이 가능하다.
최신 가비지 콜렉터답게 테라바이트급 힙 사이즈에서도 적은 지연율(Latency)율로 빠르게 찍고 버리는 동시성을 겸비한 자바의 현존 최고의 가비지 콜렉터라 하겠다.
이 콜렉터가 강조하는 것은, 중단 시간이 절대 10ms 를 넘지 않는다는 것이 되겠다.
그렇다고 단점이 없는 건 아닌데, 이녀석은 CPU 의존이 크기 때문에 CPU가 클 수록 좋은 효과를 누릴 수 있다는 것. 따라서 독립적인 환경이 보장되는 대규모 서버에서 운용할 생각이라면 이 가비지 콜렉터 사용을 추천한다.

따라서 위 두 가바지 콜렉터를 선택하지 않고 자바 17로 만든 어플리케이션을 운용할 거라면 차라리 자바 17을 쓰지 말도록 하자.

참고 문헌(?)

• Choosing a GC Algorithm in Java
• JVM Garbage Collectors
• Java garbage collection: The 10-release evolution from JDK 8 to JDK 18
• How to choose the best Java garbage collector

끗이야. 이정도면 답이 됐으려나?

지금은?

그러고 보니 이 글 쓸 당시에 자바 21은 커녕 20 나오지도 않았던 시절이다. 작년 초에 쓴 글이니까.
자바 21에는 GC 새로 나온 건 없다. ZGC가 향상됐을 뿐.
그래도 네가 신규 프로젝트로 갈 인간이라면 인간적으로 최신 안정화 버전인 자바 21을 쓰도록 하자. 내가 당시 권장했던 17은 당시 최신 LTS였으니까.

끗_최종.hwp