자바의 가비지 콜렉션(Garbage Collection)

여태까지 프로젝트 경험도 많지 않고, 기술도 많지 않아서 기능구현에 목적을 두고 코딩을 되는대로 해왔는데,,

그게 면접에서 좋게 보일리는 없다.. 메모리나 보안 등등 신경써야 할것들이 굉장히 많아보이긴 하는데 사실 잘 모름.

그래서 오늘부터라도 정리를 좀 해보려고 한다.

 

오늘은 Garbage Collector에 대해.

카카오 면접 후기를 봤는데 거기에서 면접 문제 중 하나로 등장을 했었다. 근데 난 전혀 들어본적조차 없었기에 카카오 취업의 꿈은

딱히 없긴 했지만 더더욱 사라져 버렸다.

 

어쨌든 중요한 개념인 것 같아 정리를 해본다. 모든 기준은 JAVA/ 웹 일듯 하다.

 

가비지 컬렉터에 앞서 항상 등장하는 듯한 개념인 JVM 과 메모리

(https://wanzargen.tistory.com/15 블로그의 글을 참고했다. )

메모리는 운영체제가 관리하고, 모든 프로그램들은 당연히 OS 위에서 돌아감.

프로그램이 돌아가려면 메모리가 있어야 하기 때문에 OS가 그 메모리들을 할당해준다.

자바 가상 머신인 JVM도 마찬가지기이기 때문에 필요하면 운영체제에게 메모리를 요청 & 할당을 받는다.

그렇게 일정 메모리를 할당하는데 만약 그 메모리가 부족하면 더 달라고 요청을 한다.

그렇게 JVM첫번째 할당받은 것은 101~200, 두번째 메모리 할당은 301~400이라면 이들의 상대적 주소는 0~200이다.

그래서 물리적으로 메모리가 분리되어 있을 수는 있지만 논리적으로는 하나의 메모리처럼 동작한다.

 (사실 이부분 시스템소프트웨어부분에서 배웠던 내용들인데 일단은 메모리부분은 더 찾아보진 않겠다. )

 

 

"Garbage"는 다들 알것같지만, 쓰레기값, 즉 정리되지 않은 메모리, 혹은 유효하지 않은 메모리주소 정도로 말할 수 있다.  

예를들어 배열에 값을 넣어서 선언을 해놨다가, 새롭게 String으로 값을 넣어버리면 기존의 값은 주소를 잃고 Garbage값이 되어버리는거다.

 

그렇다면 "Garbage Collector"란 메모리가 부족할 때, 쓰레기를 정리해주는 프로그램이다.

 

"Garbage Collector"는 언제 실행될까?

이는 JVM이 메모리를 부여받고 프로그램들을 실행하다가 메모리가 부족할 때, 추가적인 메모리를 요청할 때에 바로 그 때에 실행이 된다.

또, 서버 프로그램인 경우에는 24시간 내내 돌아가는데, 이 때는 JVM이 한가할 때 실행된다.

(자동으로 해줘서 좋은 것인듯)

 

사실 이런 개념적인 부분들보다는 어떻게 쓰이는지? 어떤 값들을 웹에서 gc로 정리를 해줘야 할 지, 메모리에 어떤 영향을 끼칠 지에대해 고민 하는 것이 더 중요할 것이다.

 

네이버에 d2에서 garbage collection에 관한 글들을 찾아보았다.

-https://d2.naver.com/helloworld/1329

-https://d2.naver.com/helloworld/37111

서론부터 GC를 잘 알아야 좋은 개발자라고 말씀하시는 개발자님.. 2011년에 쓰인 글인데도 불구하고..

 

대충 첫번째 글 먼저 정리를 해보자면

 

Garbage Collection 과정에 대하여.

 

과정에 대해 알기 위해서는 'stop-the-world'라는 용어를 알 필요가 있다고 한다.

'stop-the-world'란?

GC를 실행하기 위해서 JVM이 실행을 멈추는 것! stop-the-world가 발생하면 가비지컬랙터 스레드를 제외한 나머지는 모두 동작을 멈춘다.

어떤 알고리즘을 사용하더라도 stop-the world는 발생을 한다. 그래서 GC튜닝이란 이 'stop-the-world'의 시간을 줄이는 것을 의미한다.

 

java에서는 메모리를 명시적으로 해제하지 않기 때문에 위에서 언급했듯, 자바 컬렉터가 알아서 쓰레기 객체들을 찾아서 지우는 작업을 진행한다.

 

가비지 컬렉터의 전제조건은 두가지가 존재한다.

1. 대부분의 객체는 금방 접근 불가능 상태가 된다.

2. 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다.

 

위의 전제조건(가설)에 따라서 VM에서는 물리적 공간이 Young영역과 Old영역으로 나뉜다.

이름과 같이 Young 영역은 새롭게 생성한 객체의 대부분이 위치한다. 금방 접근 불가능상태가 되기 떄문에 객체가 이 영역에있다가 사라진다.

Old 영역은 Young영역에서 살아남은 객체가 이곳으로 복사된다. 여기서는 GC가 덜 발생한다.

 

Young 영역은 또 세가지로 나뉜다.

Eden영역

Survivor 영역(2개)

 

-과정을 풀어보자면 새로 생성한 객체는 Eden영역에 위치한다.

-Eden영역에서 gc가 발생 -> 살아남은 객체는 Survivor영역으로 이동. 이 영역에 계속 쌓인다.

-하나의 서바이벌 영역이 가득 차면 다른 서바이버 영역으로 이동한다. 이 과정을 계속하며 살아남은 객체는Old영역으로 이동한다.

-여기서 서바이벌끼리의 이동에서 하나의 서바이벌 영역은 꼭 비어있어야 한다.

 

너무 개념이 길기 때문에 개념정리를 마치도록 하고 모니터링 방법은 실제로 해보면서 경험하는 것이 좋을듯 하다.

https://d2.naver.com/helloworld/6043 이 글을 참고하며..

 

다음 GC튜닝에 대해 간략히 정리를 해보자면

자바에서 꼭 GC튜닝이 필수적이진 않다고 한다. 어느정도 기본적으로 괜찮게 되어있나봄.

그리고 String대신 StringBuffer나 StringBuilder를 생활화 하자고 함. 이것은 왜인지 안다!

String은 만약 정의된 값이 새롭게 덮어씌워지면 기존의 값이 쓰레기 값이 되는데, 다른 두가지는 그게 아니라 그 메모리값 위에 쓰는? 그런 형식이기 때문에 그렇다고 알고있다.

그리고 로그도 적게 쌓는 것이 좋다고 한다.

xml과 json파싱은 메모리를 굉장히 많이 사용한다고 함. 그런데 이 파싱을 쓰지 않을 수 없는 현실이라고 한다.

 

또한 하나의 좋은 방법은 old영역으로 넘어가는 객체의 수를 최소화 하는 것이 full gc의 실행시간을 줄이는 것이다.

 

성능을 좋게 하기 위해선 무조건 적으로 좋다고 알려진 방법을 쓰는게 아니라 알맞게 사용하는게 좋다고 한다.

그래서 heap 영역과 new 영역을 살피고, 시작을 해야하나보다.

 

이 이상은 해보지 않는 이상 이해가 안될듯 하여 여기까지 정리를 마쳐야겠다..