LeakCanary
LeakCanary를 이용하여 메모리 릭을 정복하자.
“A small leak will sink a great ship.” - Benjamin Franklin
적은 물이 새어 큰 배 가라앉힌다. 나는 PC 어플리케이션을 개발했었다. 당시 프로그래밍 습관으로는 new를 하면 delete를 꼭 한쌍으로 하였다. 그리고 delete 된 코드를 적절한 곳으로 이동 시켰다. 혹시라도 new를 하고 delete를 하지 않는 실수를 하여 leak를 발생시키지 않게 하기 위함이었다.
모바일 환경으로 전환을 하고 자바라는 언어를 접하고 한동안 언어의 이질감에 상당히 적응하기가 힘들었다. 내가 만든 인스턴스를 왜 내가 해제하지 못하는가? 가비지 컬렉터라는 것이 너무 귀찮고 불필요하고 개발자를 게으르게 하는 요인인 것 같았다. 그렇게 계속 자바에 길들어지고 지금은 가비지 컬렉터 환경에 너무 익숙해졌다.
그렇다고 가비지 컬렉터가 만능은 아니다. 개발을 할 때 항상 조심 또 조심해서 static으로 사용하지 않는 객체는 반드시 null 처리를 해 주어 가비지 컬렉터라 회수를 할 수 있게 신경 써야 한다. 또한 weak reference를 적절히 사용하여 메모리가 경계에 있을 때 OOM이 발생하지 않게 각별히 주의 해야 한다.
이런 것을 예전에는 이클립스 플러그인은 MAT로 관리할 수 있었지만(실제로는 난 잘 사용하지 않았다.) 얼마전 앱 자체에 심어 릭을 관리해 주는 모듈을 찾았다.
이미지 처럼 앱 내에서 메모리 릭을 감지하여 리포팅 해주는 툴 이다.
https://github.com/square/leakcanary
모바일 환경으로 전환을 하고 자바라는 언어를 접하고 한동안 언어의 이질감에 상당히 적응하기가 힘들었다. 내가 만든 인스턴스를 왜 내가 해제하지 못하는가? 가비지 컬렉터라는 것이 너무 귀찮고 불필요하고 개발자를 게으르게 하는 요인인 것 같았다. 그렇게 계속 자바에 길들어지고 지금은 가비지 컬렉터 환경에 너무 익숙해졌다.
그렇다고 가비지 컬렉터가 만능은 아니다. 개발을 할 때 항상 조심 또 조심해서 static으로 사용하지 않는 객체는 반드시 null 처리를 해 주어 가비지 컬렉터라 회수를 할 수 있게 신경 써야 한다. 또한 weak reference를 적절히 사용하여 메모리가 경계에 있을 때 OOM이 발생하지 않게 각별히 주의 해야 한다.
이런 것을 예전에는 이클립스 플러그인은 MAT로 관리할 수 있었지만(실제로는 난 잘 사용하지 않았다.) 얼마전 앱 자체에 심어 릭을 관리해 주는 모듈을 찾았다.
이미지 처럼 앱 내에서 메모리 릭을 감지하여 리포팅 해주는 툴 이다.
https://github.com/square/leakcanary
댓글
댓글 쓰기