아이템7 다 쓴 객체 참조를 해제하라

자바처럼 가비지 컬렉터를 갖춘 언어는 메모리 관리에 더 이상 신경 쓰지 않아도 된다는 말은 사실이 아니다.

이번 item에서는 메모리 관리가 필요한(다 쓴 객체 참조를 해제해야할) 3가지 경우를 살펴본다.

다 쓴 참조(obsolete reference) : 프로그램에서 더 이상 사용하지 않는 객체의 reference

1. 메모리를 직접 관리하는 클래스의 메모리 누수

public class Stack {
	private Object[] elements;
	private int size = 0;
	private static final int DEFAULT_INITIAL_CAPACITY = 16;

	public Stack() {
		elements = new Object[DEFAULT_INITIAL_CAPACITY];
	}

	public void push(Object e) {
		ensureCapacity();
		elements[size++] = e;
	}

	public Object pop() {
		if (size == 0)
			throw new EmptyStackException();
		return elements[--size]; // 문제 : pop() 대상을 가비지 컬렉터가 회수하지 않음
	}

	private void ensureCapacity() {
		if (elements.length == size)
			elements = Arrays.copyOf(elements, 2 * size + 1);
	}
}

위 코드 예제에서, 다 쓴 참조를 가지게되는 코드로 인해 메모리 누수가 일어난다.

pop() 메서드는 size 변수를 1만큼 감소시키고, elements array를 --size만큼 반환한다.

하지만, Stack class가 elements 배열을 직접 가지고 저장소 풀을 만들어 원소를 관리한다. 따라서 elements의 원소들이 불필요한 것인지 가비지 컬렉터는 알 수가 없다.

그래서 자기 메모리를 직접 관리하는 클래스라면 프로그래머는 항시 메모리 누수에 주의해야 한다.

public Object pop(){
	if (size == 0)
		throw new EmptyStackException();
	Object result = elements[--size];
	elements[size] = null; // 다 쓴 참조 해제
	return result;
}

2. 캐시 메모리 누수

WeakHashMap 사용

WeakHaspMap은 key를 참조하는 reference가 없으면, 해당 키를 자동으로 GC가 버려주는 HashMap의 한 종류이다.

캐시 외부에서 키(key)를 참조하는 동안만 엔트리가 살아 있는 캐시가 필요한 상황이라면 WeakHashMap을 사용하면 메모리 누수를 관리할 수 있다.

미사용 엔트리 관리

캐시를 만들 때 보통은 캐시 엔트리의 유효 기간을 정확히 정의하기 어렵기 때문에 시간이 지날수록 엔트리의 가치를 떨어뜨리는 방식을 흔히 사용한다.

이런 방식에서는 쓰지 않는 엔트리를 이따금 청소해줘야 한다.

Scheduled ThreadPoolExecutor 같은 백그라운드 스레드를 활용하거나 캐시에 새 엔트리를 추가할 때 부수 작업으로 수행하는 방법으로 진행하면 된다.

LinkedHashMap은 removeEldestEntry 메서드를 써서 후자의 방식으로 처리한다.

3. 리스너 혹은 콜백 누수

리스너(listener) 혹은 콜백(callback) 내에서도 누수가 발생할 수 있다. 클라이언트가 콜백을 등록만 하고 명확히 해지하지 않는다면, 뭔가 조치해주지 않는 한 콜백은 계속 쌓여갈 것이다. 이럴 때 콜백은 약한 참조(weak reference)로 저장하면 가비지 컬렉터가 즉시 수거해간다. 예를들어 WeakHashMap에 키로 저장하면 된다.