Garbage Collection과 Memory Leak

정글의 malloc 구현 전산학 프로젝트를 진행하면서 묵시적, 명시적 가용리스트를 구현하고, 가용리스트 탐색 방식을 first, next, best fit으로 바꿔보기도 하며 수많은 동적 할당 방식을 접했다. 하지만 어떤 방식의 동적 메모리 할당을 택하더라도, 그것이 개발자의 판단에 기반하는 "동적" 할당인 이상, 할당한 당사자가 명시적으로 메모리를 해제할 의무가 있다. 그리고 그 의무로 인해 해제된 메모리에 접근하여 에러가 발생하거나, 해제를 하지 않아 memory leak이 발생하는 등의 각종 문제가 유발된다. 

 

Garbage Collection은 동적 할당의 해제를 자동화하는 시스템으로, 이를 통해 위의 각종 문제들을 개선한 환경을 보장한다. C에서는 개발자가 메모리를 사용 후 해제해야하는 전적인 책임을 갖지만, Java에서는 이 Garbage Collection의 존재로 인해 그러한 책임이 없는 더 추상화된 개발 환경을 제공한다.

 

하지만 이러한 high level화의 대신, 가비지 컬렉션은 몇가지 대가를 필요로 한다. 힙에 할당된 메모리들을 조사하며 가비지인지 체크하는 일련의 과정 자체가 오버헤드로써 작용하고, 가비지를 쌓아뒀다가 컬렉션 작동 시 일괄 해제하기 때문에, 메모리 사용 종료 후 불용시 명시적으로 해제하는 시스템(이 이상적으로 작동할 때)에 비해서는 메모리 효율이 나쁘다.

또한 가비지 컬렉션의 작동 과정에서 메모리의 실사용 여부를 판단하기 위해 모든 스레드를 일시 중단하고, (Java) method area의 클래스 참조, 각 스레드의 스택 영역의 모든 참조를 확인하기 때문에, 실시간 시스템에서는 치명적인 문제가 될 수 있다.

 

Garbage Collection의 존재는 이것이 없는 시스템보다는 Memory leak을 개선시키긴 하지만, '개선'하는 시스템일 뿐 완전히 해결하지는 못한다. 예를 들어 다 쓴 객체의 참조를 해제하지 않는다면 Garbage Collection의 target이 될 수 없어 컬렉터에 의해 메모리가 회수되지 못하고 잔존하여 memory leak이 발생하게 된다. 따라서 메모리 누수를 시각화하는 라이브러리 등을 이용하여 주기적으로 점검해야 문제를 차단할 수 있다.