📘 Effective Java

[Item 7~8] 다 쓴 객체 참조를 해제하라, finalizer와 cleaner 사용을 피하라.

loose 2022. 9. 3. 00:00
반응형

[Item 7] 다 쓴 객체 참조를 해제하라


책의 요지와는 별개로 신기했던건 Arrays.copyOf로 배열의 길이를 늘릴 수 있다는 점이다. (워낙 배열을 안쓰기도 해서 몰랐지만 항상 고정 크기인줄만 알았던 배열이 늘어난다는 건 신기했다.)

책에서 설명하는 것은 Stack 구조로 배열을 만들 때 pop 메소드가 일어나는 경우 해당 자리에 있던 객체는 가비지 컬렉터가 회수해가지 않는다고 한다.
그래서 단순히 배열의 요소 위치만 변경해서 사이즈를 줄이는 것 뿐만 아니라 다 쓴 객체를 null 값으로 지정해줘야 객체 참조가 해제가 된다.
이 행위를 해주지 않으면 프로그램은 해당 객체를 계속 들고 있기 때문에 메모리 누수 현상이 일어난다.

결론


Stack 클래스가 대표적으로 메모리 누수현상이 일어나는 케이스라고 한다.

다 쓴 객체를 null로 만드는 가장 좋은 상황은 scope에서 벗어났을 때라고 한다. 그게 바로 Stack이다.
그 다음으로는 캐시 기능 역시 메모리 누수를 일으키는 주범으로 설명하고 있는데 자바로 캐싱 기능을 직접 만들 수 있지만 보통 Spring에서는 EhCache와 같은 것들을 이용하면 시간 설정도 가능하고 캐시를 유동적으로 지우기 편리하다.

사실 Stack을 쓸 일도 배열을 쓸 일도 없거니와 scope 바깥으로 내보내는 코딩을 하는 경우가 그렇게 많지 않을 것 같다. 물론 평소엔 중요하지 않더라도 언젠가 이용하게 되고 위의 내용을 모른다면 서버 과부하는 피해갈 수 없을 것이다.

[Item 8] finalizer와 cleaner 사용을 피하라.


finalizer와 cleaner는 객체 소멸을 시켜주는 기능들이라고 한다. 사실 본 적도 없다. finalizer와 cleaner는 객체마다 상속받을 수 있는 메소드들인데, 가비지 컬렉터(gc)를 실행시키면 finalizer를 실행시켜 객체가 소멸되는 원리다.

스프링에선 기본적으로 객체들은 스프링이 모두 관리한다. 책에서도 사용 조차도 피하라고 하고 있으니 일단 패스..

728x90