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

wisdom·2022년 8월 17일

Effetctive Java

목록 보기

7/80

🔖 들어가며

가비지 컬렉션 언어에서는 메모리 누수를 찾기가 아주 까다롭다.
가비지 컬렉터는 객체 참조 하나를 살려두면 그 객체 뿐만 아니라 그 객체가 참조하는 모든 객체(그리고 또 그 객체들이 참조하는 모든 객체...)를 회수해가지 못한다. 그래서 단 몇 개의 객체가 매우 많은 객체를 회수되지 못하게 할 수 있고, 잠재적으로 성능에 악영향을 줄 수 있다

✔️ 예제

스택을 구현하는 다음의 코드를 보자.

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];
    }
    
    private void ensureCapacity() {
    	if(elements.length == size)
        	elements = Arrays.copyOf(elements, 2*size+1);
    }
}

이 코드에서 메모리 누수는 어디서 일어날까?
스택이 커졌다가 줄어들었을 때 스택에서 꺼내진 객체들을 가비지 컬렉터가 회수하지 않아 메모리 누수가 발생한다.
이는 스택이 그 객체들의 다 쓴 참조를 여전히 가지고 있기 때문이다.

해법은 해당 참조를 다 썼을 때 null 처리를 하여 참조를 해제하는 것이다.
예시에서는 pop 메서드에 원소를 꺼내고 더 이상 참조가 필요 없는 시점에 null 처리를 해주면 된다.

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

✔️ 메모리 누수의 원인

이제 메모리 누수를 일으키는 주범들을 살펴보자.

1️⃣ 자기 메모리를 직접 관리하는 클래스

일반적으로 자기 메모리를 직접 관리하는 클래스라면 프로그래먼느 항시 메모리 누수에 주의해야 한다.
원소를 다 사용한 즉시 그 원소가 참조한 객체를 다 null 처리해줘야 한다.

2️⃣ 캐시

객체 참조를 캐시에 넣고나서, 이 사실을 잊은 채 그 객체를 다 쓴 뒤로도 한참을 그냥 놔두는 일을 자주 접할 수 있다.
해법은 여러 가지다.

캐시 외부에서 키를 참조하는 동안만 엔트리가 살아있는 캐시가 필요한 상황이라면, WeakHashMap을 사용해 캐시를 만들자. 그러면 다 쓴 엔트리가 그 즉시 자동으로 제거될 것이다.
시간이 지날수록 엔트리의 가치를 떨어뜨리는 방식을 흔히 사용하는데, 이런 방식에서는 쓰지 않는 엔트리를 이따금 청소해줘야 한다. 백그라운드 스레드(Schedjuled ThreadPoolExecutor 같은)를 활용하거나 캐시에 새 엔트리를 추가할 때 부수 작업으로 수행하는 방법이 있다. LinkedHashMap은 removeEldestEntry 메서드를 써서 후자의 방식으로 처리한다.
더 복잡한 캐시를 만들고 싶다면 java.lang.ref 패키지를 직접 활용해야 할 것이다.