전공은 아니라 어설프게 취미로 배우는 수준에서 배우고 있긴 한데 제가 아는 선에서 이야하면, 클래스는 거기에 따른 생성자와 소멸자가 있습니다. 생성자는 예를들어 사냥개로 치자면 뽀삐란 이름으로 객체를 맹글면 생성자는 개목걸이를 걸어주고 뭐 그러는 역할을 한다고 생각하시면 됩니다. 개가 태어날때부터 목걸이차고 태어나진 못하니까요. 그리고 소멸자는 이제 토끼를 잡았으면 목적을 다 했으니 개를 잡아야겠죠. 개를 잡으면서 옆집 아저씨도 먹으러 오라고 부르고 하는겁니다. 물론 따로 정하지 않으면 그냥 잡아먹고 끝나는거구요. 자바는 사냥이 끝나고 그냥 개가 사료만 축내고 있으면 알아서 잡아줍니다. 이걸 가비지 컬렉터라고 합니다. 다만 이것은 무조건 바로바로 털어주는건 아니기 때문에 빠르게 돌릴 필요가 있으면 직접 지정을 해서 빨리 치워버리라는 겁니다.

친절한 설명 감사드립니다. 원래 가비지 콜렉터는 흩어져있는 메모리 를 모아주는 역할을 했었는데요.. 요즘엔 사용한 메모리를 제대로 반납하지 않은 것을 없애주는 역할을 하나요 ? 그것은 굉장히 위험한듯 합니다. 앱이 죽을때 사용하던 모든 힙을 반납하도록 또는 OS가 따라다니다가 바로 되찾아가야 바람직한 것이 아닐까요 ? 빗맵처럼 앱이 이게 힙에 있는지 아닌지 모른다면 반납하도록 만드는 것은 말이 안되고.. OS가 알아서 해야 한다는 얘기로 보입니다.

http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29

가비지 컬렉터는 예전부터 반납되지 않은 메모리를 회수하는 데에 사용되었습니다. 연결이 끊긴 클래스나 더이상 사용이 없는 자료들을 찾아 회수합니다. 꽤 오래 사용되던 방식이고 확실하게 죽은 것만 회수하기에 위험하지는 않습니다. 그냥 C++에선 수동으로 하던 게 자동으로 되었을 뿐이니까요.

대신 가비지 컬렉션이 일어나는 순간 조금의 버벅임이 있을 수는 있지요. 자바쪽(안드로이드의 경우 달빅 머신)에서 알아서 호출하기 때문에 안드로이드의 경우 운영체제의 일부라고 볼 수 있습니다.

그래서 GC만 믿고 짜면 메모리가 잘못 회수될 일은 코드에 문제가 없는 이상 잘 없지만  회수 안되는 일은 종종 있지요.

물론 jni같은 것까지 치면 더 복잡한 문제입니다만...

GC가 메모리를 회수 하지 못하는 것은 "순환 참조"입니다. 그 외의 경우에는 Dalvik VM의 GC에 메모리 릭은 없습니다. 실질적으로 순환참조를 사용해야 개발할 수 있는 경우는 거의 존재하지 않고 순환참조가 발생했다는 것은 잘못된 코딩을 했다는 것을 의미합니다.

또 JNI로 Native 코드가 호출된 경우에도 제대로 짠 소프트웨어라면 제대로 메모리가 해제됩니다. 왠만한 개발환경은 메모리 릭이 발생한 시점에 스텍 트레이스와 할당 로그등을 제공해줍니다. 제대로 훈련받은 개발자라면 이런 도구로 메모리 릭을 잡는 것에 익숙해져있습니다.