[이펙티브 자바] Item7. 다 쓴 객체 참조를 해제하라.

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

자바에서는 가비지 컬렉션 덕분에 메모리 관리를 C나 C++에 비해서는 편하다고 할 수 있지만 그렇다고 메모리 관리를 아예 신경쓰지 않아도 되는 것은 아니다. 

 

메모리를 직접 관리하는 클래스가 있다면 메모리 누수가 일어날 수 있고, 이 메모리 누수는 겉으로는 잘 드러나지 않기 때문에 시스템에 수년간 잠복해 있다가.. 심한 경우에는 디스크 페이지이나 OutoutMemoryError를 일으켜서 프로그램이 예기치 않게 종료될 수도 있다.. 

 

그러므로 어떤 경우에 메모리 누수가 발생할 수 있으며, 해결? 방법은 무엇인지에 대해서 item07에서 소개하고 있다. 

 

 

메모리 누수가 발생하는 경우 👾

: 어떤 객체에 대한 레퍼런스가 남아있다면 해당 객체는 가비지 컬렉션의 대상이 되지 않는다. 

 

- stack

package chapter01.item07.stack;

import java.util.Arrays;
import java.util.EmptyStackException;

/**
 * item07. 다 쓴 객체의 참조를 해제하라.
 */
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];
	}
	
	/**
	 * 원소를 위한 공간을 적어도 하나 이상 확보한다.
	 * 배열 크기를 늘려야 할 때마다 대략 2배씩 늘린다.
	 */
	private void ensureCapacity()
	{
		if (elements.length == size) {
			elements = Arrays.copyOf(elements, 2 * size + 1);
		}
	}
	
	
	public static void main(String[] args)
	{
		Stack stack = new Stack();
		for (String arg : args)
		{
			stack.push(arg);
		}
		
		while (true)
		{
			System.out.println("stack.pop() = " + stack.pop());
		}
	}
}

이펙티브 자바에서 예제로 제공한 Stack 샘플 코드인데 이 코드를 보면 문제가 없어보인다.. 

실제로도 각종 테스트를 다 하더라도 문제가 없다. 

 

하지만 '메모리 누수'라는 문제가 존재한다. 

이 코드를 보면 스택이 커졌다가 줄어들었을 때 스택에서 꺼내진 객체들을 가비지 컬렉터가 회수하지 않는다!

객체들을 더 이상 사용하지 않는데도 회수하지 않는다. 

왜냐하면 Stack이 객체들의 다 쓴 참조를 여전히 가지고 있기 때문이다. 

 

가비지 컬렉션에서는 객체 참조 하나를 살려두면 가비지 컬렉터는 그 객체뿐만 아니라 그 객체가 참조하는 모든 객체를 회수하지 못하기 때문에 잠재적으로는 성능에 악영향을 끼칠 수 있다. 

 

 

해결 방법1) 해당 참조를 다 썼을 때 null 처리 (참조 해제) 하면 된다. 

package chapter01.item07.stack;

import java.util.Arrays;
import java.util.EmptyStackException;

/**
 * item07. 다 쓴 객체의 참조를 해제하라.
 */
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];
// }
   
   /**
    * 원소를 위한 공간을 적어도 하나 이상 확보한다.
    * 배열 크기를 늘려야 할 때마다 대략 2배씩 늘린다.
    */
   private void ensureCapacity()
   {
      if (elements.length == size) {
         elements = Arrays.copyOf(elements, 2 * size + 1);
      }
   }
   
   // 메모리 누수 없이 제대로 구현한 pop 메서드
   public Object pop()
   {
      if (size == 0) {
         throw new EmptyStackException();
      }
      Object result = elements[--size];
      elements[size] = null; // 방법1) 다 쓴 참조 해제 -> 바람직한 방법은 아니다 -> 객체 참조를 null 처리하는 일은 예외적이어야 한다.
      return result;
   }
   
   public static void main(String[] args)
   {
      Stack stack = new Stack();
      for (String arg : args)
      {
         stack.push(arg);
      }
      
      while (true)
      {
         System.out.println("stack.pop() = " + stack.pop());
      }
   }
}

-> elements[size] = null  로 처리하면서 다 쓴 참조를 해제해줬는데 이렇게 객체 참조를 null 처리하는 일은 예외적인 경우여야 한다!! 

 

 

 

해결 방법 2) 그 참조를 담은 변수를 유효 범위(scope) 밖으로 밀어내는 것이다. 

변수의 범위를 최소가 되게 정의해서 더 이상 참조하지 않을 경우에는 유효 범위 밖으로 밀어내서 다 쓴 참조 객체를 해제할 수 있다. 

 

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

 

- cache

위에 예시에서는 스택을 예로 들었는데 캐시 역시 메모리 누수를 일으키는 주범이다. 

캐시 역시 객체 참조를 캐시에 넣고 나서 이 사실을 까먹고 있다가 그 객체를 다 쓴 뒤로도 한참 그대로 놔두게 되는 경우가 많다. 

 

package chapter01.item07.cache;

import java.time.LocalDateTime;

public class CacheKey
{
   private Integer value;
   private LocalDateTime created;
   
   public CacheKey(Integer value)
   {
      this.value = value;
      this.created = LocalDateTime.now();
   }
   
   @Override
   public boolean equals(Object obj)
   {
      return this.value.equals(obj);
   }
   
   @Override
   public int hashCode()
   {
      return this.value.hashCode();
   }
   
   public LocalDateTime getCreated()
   {
      return created;
   }
   
   @Override
   public String toString()
   {
      return "CacheKey{" +
            "value=" + value +
            ", created=" + created +
            '}';
   }
}

 

package chapter01.item07.cache;

import java.util.HashMap;
import java.util.Map;
import java.util.WeakHashMap;

import org.springframework.cglib.core.WeakCacheKey;

/**
 * item07. 다 쓴 객체 참조를 해제하라.
 */
public class PostRepository
{
   private Map<CacheKey, Post> cache;
   
   public PostRepository()
   {
      this.cache = new HashMap<>();
   }
   
   public Post getPostById(Integer id)
   {
      CacheKey key = new CacheKey(id);
      
      if (cache.containsKey(key)) {
         return cache.get(key);
      }else {
         Post post = new Post(); // TODO DB에서 읽어오거나 REST API를 통해 읽어올 수 있다.
         cache.put(key, post);
         return post;
      }
   }
   
   public Map<CacheKey, Post> getCache()
   {
      return cache;
   }
}

@Test
void cache() throws InterruptedException
{
   PostRepository postRepository = new PostRepository();
   Integer p1 = 1;
   postRepository.getPostById(p1);
   
   assertFalse(postRepository.getCache().isEmpty());
   
   System.out.println("run gc");
   System.gc();
   System.out.println("wait");
   Thread.sleep(3000L);
   
   assertTrue(postRepository.getCache().isEmpty());
}

이렇게 구현한 후에 캐시를 테스트 해보면 가비지 컬렉션에서 캐시는 참조하고 있는 곳이 있기 때문에 GC의 대상이 되지 않아서 assertTrue에서 테스트 실패한다. (false 이기 때문에) 

 

 

package chapter01.item07.cache;

import java.util.HashMap;
import java.util.Map;
import java.util.WeakHashMap;

import org.springframework.cglib.core.WeakCacheKey;

/**
 * item07. 다 쓴 객체 참조를 해제하라.
 */
public class PostRepository
{
   private Map<CacheKey, Post> cache;
   
   public PostRepository()
   {
      this.cache = new WeakHashMap<>();
   }
   
   public Post getPostById(Integer id)
   {
      CacheKey key = new CacheKey(id);
      
      if (cache.containsKey(key)) {
         return cache.get(key);
      }else {
         Post post = new Post(); // TODO DB에서 읽어오거나 REST API를 통해 읽어올 수 있다.
         cache.put(key, post);
         return post;
      }
   }
   
   public Map<CacheKey, Post> getCache()
   {
      return cache;
   }
}

 책에 보면 '키를 참조하는 동안만 엔트리가 살이 있는 캐시가 필요한 상황이라면 WeakHashMap을 사용해 캐시를 만들자'

라는 말이 있는데 이와 같이 원래는 HashMap을 사용했을 때는 테스트 실패했지만,, WeakHashMap을 사용하면 다 쓴 엔트리는 즉시 자동으로 제거가 돼서 테스트 성공하는 것을 확인할 수 있다. 

 

💡 WeakHashMap을 아직 잘 몰라서 사실 이 부분은 이해가 되지 않았다,, 다음 강의에 설명이 있어서 듣고 내용을 더 추가해야겠다. 

 

 

 

해결 방법3) 백그라운드 스레드 활용하는 방법

@Test
void backgroundThread() throws InterruptedException
{
   ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
   PostRepository postRepository = new PostRepository();
   CacheKey key1 = new CacheKey(1);
   postRepository.getPostById(1);
   
   Runnable removeOldCache = () -> {
      System.out.println("running removeOldCache task");
      Map<CacheKey, Post> cache = postRepository.getCache();
      Set<CacheKey> cacheKeys = cache.keySet();
      Optional<CacheKey> key = cacheKeys.stream()
            .min(Comparator.comparing(CacheKey::getCreated));
      key.ifPresent((k)-> {
         System.out.println("removing " + k);
         cache.remove(k);
      });
   };
      
      System.out.println("The time is : " + new Date());
      
      executor.scheduleAtFixedRate(removeOldCache, 1, 3,
                            TimeUnit.SECONDS);
      
      Thread.sleep(20000L);
      
      executor.shutdown();
   
}

ScheduledThreadPoolExecutor를 통해 쓰지 않은 엔트리를 제거하는 과정을 백그라운드 스레드를 활용하는 방법이다. 

테스트 수행 결과 처음에는 제거할 엔트리가 있어서 제거한 후에는 이제 더 이상 제거할 것이 없기 때문에 'running removeOldCache task' 만 출력되는 것을 확인 할 수 있다. 

 

 

- 리스너 (listener) , 콜백 (callback) 

: 메모리 누수의 세번ㅉ?ㅐ 주범은 바로 리스너 혹은 콜백이라 부르는 것이다. 

클라이언트카 콜백을 등록만 하고 명확하게 해지하지 않는다면 뭔가 조치해주지 않는 한 콜백은 제거되지 않고 계속 쌓이게만 된다.. 

 

-> 이럴 때는 콜백을 약한 참조 (Weak reference)로 저장하면 가비지 컬렉터가 즉시 수거해간다. (ex. WeakHashMap 에 키로 저장)