2-2 다 쓴 객체참조를 해제하라.

메모리 누수는 겉으로 잘 드러나지 않는다.

오래된 시스템에서는 코드리뷰, 힙프로파일러 리뷰를 하다보면 필요없는 메모리가 수년간 잠복하는 경우도 흔하다.

# 메모리를 직접 관리하는 클래스라면 누수에 주의하라. (Stack, Array 등)

아래 코드에서 메모리 누수가 심하게 발생하고 있다. 어디인지 쉽게 찾을 수 있는가?

// "메모리 누수(memory leak)"가 어디서 생기는지 보이는가?
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];
  }
 
  if (elements.length == size) // 공간이 부족하다면 스택 크기를 2배씩 늘린다.
    elements = Arrays.copyOf(elements, 2 * size + 1);
}

바로 element[--size] 이다. 더이상 사용하지 않는 메모리인데도 참조는 그대로 유지되고있다.

자바의 가비지컬렉터(GC)는 참조여부를 기준으로 메모리 할당을 해제한다. 사용하지도 않는 곳에서 메모리 누수가 발생하는 것이다. 위의 예제는 그나마 누수를 찾기 쉬운편이다. 캐시 (key-value)나 리스너와 콜백(callback)을 사용할 때 위와 같은 문제가 자주 발생한다고 생각하면 끔찍하다.

map.put(key1, "test a");
map.put(key2, "test b");
 
key1 = null; 
/* ... 다른 코드 ... */
 
// 서비스에서는 사용되지 않지만 map에 있는 key1의 데이터의 참조는 계속 남아있다.

또한 JVM의 GC가 이러한 메모리를 찾아서 할당 해제해준다고 한들, 큰 문제가 생길 수 있다.

GC안에는 크게 Young 영역과 Old 영역이 존재하는데, 이런식으로 계속해서 참조하고 있는 메모리는 Old 영역까지 옮겨지게 되고 Old 영역에 쌓인 메모리는 프로그램 구동을 잠깐 멈춰버리고 (Stop-the-World) 메모리 영역을 해제한다.

(G1GC 이전에는) 서버컴퓨터의 메모리가 워낙커서, Old 영역에 이러한 데이터가 쌓이게된다면 JVM의 GC가 Old 영역을 비우기 위해서 서버가 2~3분간 멈춰버릴 수 있다. 장애가 난것도, 로직에 오류가 있는 것도 아닌데 말이다. 

# 해결책

간단하다. 다쓴 객체는 참조를 해제해주면 된다.

public Object pop() {
  if (size == 0)
    throw new EmptyStackException();
  Object results = elements[--size];
  elements[size] = null;  // 만기  참조 제거
  return results;
}

다만 위와 같이 null을 사용하는 건 NullPointException 때문에 다른 문제가 또 생겨버린다.

이를 해결하기 위해서 자바에는 Weak 자료형 (WeakHashMap)등을 제공해준다. 기존의 자료형과 사용법은 동일하나 값을 직접 참조하는게 아니라 참조 객체(WeakReference)를 통해 가지고 있다가 해당 값이 더 이상 사용되지 않는다고 판단하면 (prime == null이 된다면) 해당 원소를 제거하고 GC해버린다. 

• Weak 자료형은 기존의 자료형과 똑같이 멀티스레드에 안전하지 않다.
• Weak 자료형을 거치지 않고, Key를 직접 참조해버리면 아무런 의미가 없어진다. WeakReference로 참조해야한다.

public class WeakHashMapTest {
 
    public static void main(String[] args) {
        WeakHashMap<Integer, String> map = new WeakHashMap<>();
 
        Integer key1 = 1000;
        Integer key2 = 2000;
 
        map.put(key1, "test a");
        map.put(key2, "test b");
 
        key1 = null;
        // map에서는 삭제된 것이 아니다. 해당 메모리가 그대로 유지되어있다.
        // 하지만 WeakReference 의 prime = null이 동작된다.
        // 즉 GC가 발생할 때 해당 원소의 메모리가 삭제된다.
 
    }
}

# 객체의 기본 종료자 (finalizer, Cleaner)를 사용하지 마라

Java 9 이후 없어진 메서드라 모를 수 있지만 자바의 Object 객체에는 finalizer()가 존재했었다. 

이를 호출했다고 해서 바로 삭제되는 것도아니고, Lock이 걸려 프로그램 전체가 블럭될 수 있는 치명적인 메서드였다.

@Override
public void finalize() {
    // ...
}

Java 9 이후에는 Cleaner 가 소멸자로 도입되었으며, 보통 AutoCloseable 인터페이스를 구현해서 등록된 스레드에 정의된 클린 작업을 수행한다.  이를 통해 try-with-resource 문의 동작을 직접 구현할 수 있다.

try(Worker worker = new Worker()) {
    worker.work();
} catch(...) {
 
}

public class CleaningRequiredObject implements AutoCloseable {
 
    private static final Cleaner cleaner = Cleaner.create​();
 
    private static class CleanData implements Runnable {
 
        @Override
        public void run() {
            // 여기서 클린 작업 수행
        }
    }
 
    private final CleanData;
    private final Cleaner.Cleanable cleanable
 
    public CleaningRequiredObject() {
        this.cleanData = new CleanData();
 
        // cleanable 등록
        this.cleanable = cleaner.register(this, state);
    }
 
    @Override
    public void close() {
        cleanable.clean();
    }
}

하지만 DB Connector를 직접 구현하는 수준이 아니라면, 보통은 사용할 일이 거의 없다.

Java9의 Cleaner를 사용한다고 한들 성능에 문제가 많고, 객체 직렬화(Serialize)를 통한 보안적인 문제와 수행 시점을 보장해주지 않는다는 건 여전히 똑같다. 정말 필요한 경우 (네이티브 메서드 - JNI를 직접 구현)가 아니라면 사용하지 말아야 할 메서드이다.