반응형

자바 메모리 누수에 대한 이해 IT

2005.06.26. 17:35

복사 http://blog.deogtae.com/20014163264

번역하기 전용뷰어 보기

가비지 컬렉션은 프로그램의 관점에서 보아야한다. 프로그램에서 현재
도달 불가능한 객체들은 모두 쓰레기 객체이며, 이와 같은 노드 그래프를
염두에 두기 전에 루트 노드가 어떤 의미인지를 파악해야 한다. 눈에
보이지는 않지만 가상적으로 프로그램이라는 노드가 있다고 생각할 수
있으며, 이 프로그램이라는 노드로 부터 현재 직접 참조될 수 있는 상황에
있는 노드들이 모두 루트 노드들이다. 따라서, 루트 노드들은 쓰레기가 될
수 없다. 루트 노드들이 아닌 것은 모두 루트 노드들을 통하여 참조를
따라가서 참조될 수 있을 뿐이다.

좀더 일반화시켜 설명하면,
여기서 노드가 꼭 객체를 의미하는 것은 아니며, 프로그램일 수도 있고,
전역 변수나 필드가 될 수도 있다.
그러나, 그 개념은 어디든 통용될 수 있으며, 어떻게 그 개념을 실제 프로그래밍
언어에 매핑시키고 구현을 하느냐에 따라 달라질 뿐이다.
가령, 자바 프로그램의 경우, 루트 노드는 현재 존재하는 모든 스레드 스택내의
객체 참조 변수들과 static 참조 변수들이라고 일반적으로 설명하며,
프로그램에서는 이들을 통해서만 객체에 접근할 수 있기 때문이다.

그러나, 더 엄밀하게는 루트 노드는 프로그램 (더 정확히는 프로세스)라고 볼 수 있고,
스레드 스택 변수나 static 변수는 프로그램을 단순히 대리하여 다른 객체를 참조한다고
모델링할 수도 있으며, 이와같이 모델링하는 것이 더 근본적이고 명확하다.
이는 객체가 다른 객체를 직접 참조하는 것이 아니라 필드를 통하여 참조하는 것과
같은 이치이다. 즉, 필드가 객체를 대리하여 타 객체를 참조하는 것처럼
그과 같은 변수가 프로그램을 대리하여 타 객체를 참조하는 것이다.
혹은, 현재 스레드 스택 변수와 static 변수에 의해 직접 참조되는 객체들을
루트 노드로 할 수도 있다.
어떻게 개념적으로 매핑하든 그 결과는 동일하며, garbage collection에 대하여
개념적으로 가장 근본적인 설명은 프로그램에 의해 직간접적으로 참조될 수 없는 객체를
자동으로 제거하는 것이다.

스레드 스택 변수나 static 변수를 통하여 직간접적으로 참조될 수 없는 객체는
확실하게 쓰레기 객체이며 garbage collector에 의해 자동으로 제거될 수 있다.
그러나, 스레드 스택 변수나 static 변수를 통하여 참조될 수 있는 객체라
할지라도 논리적으로는 참조 불가능할 수 있다.
이는 reference counting이건 mark and sweep이건 동일하다.
그러나, 현재 기술로는 논리적으로 참조 불가능한 것 까지 기계적으로 찾아내지 못하고
그와 같이 명확한 부분만 자동화되어 있는 것이다.
논리적으로 참조 불가능한 것 까지 찾아내려면 인공지능 기술 혹은 이에 준하는
기술이 들어가야 한다.
그래서, 현재로서는 이를 해결하기 위해서 논리적으로 참조 불가능한 객체들의 참조들을
프로그래머가 끊어주는 처리를 해주어서 기계적으로 스레기 수집될 수 있는 상태로 만들어
주어야 하는 것이다.

이러한 이유로, 현재 소프트웨어 기술은 garbage collection 기법을 무엇을 사용하든
프로그래밍 언어를 무엇을 사용하든 memory leak 문제의 상당 부분이 여전히
프로그래머의 손에 남겨져 있는 것이며, 소프트웨어 기술이 발전할수록 프로그래머의 부담을
조금씩 경감시켜줄 수 있으나 완전히 없애주지는 못한다.

반응형
LIST

+ Recent posts