다 쓴 객체 참조를 해제하라 - [2장 객체 생성과 파괴(아이템7)]

자바에서는 가비지 컬렉터가 메모리 관리를 도와준다. 하지만 가비지, 컬렉터가 있다고 해도 메모리 누수가 발생하지 않는 것은 아니다. 이번 글에서는 다 쓴 객체 참조를 해제하여 메모리 누수를 방지할 수 있는 3가지 상황을 알아보고자 한다.

1. Stack에서의 메모리 누수 & 해결책

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);
    }
}

해당 코드에서 메모리 누수는 어디에서 일어날까? 이 코드에서는 스택이 커졌다가 줄어들었을 때 스택에서 꺼내진 객체들을 가비지 컬렉터가 회수하지 않는다. 프로그램에서 그 객체들을 더 이상 사용하지 않더라도 해당 스택이 그 객체들의 다 쓴 참조(obsolete reference)를 여전히 가지고 있기 때문에 가비지 컬렉터가 객체들을 회수하지 않는다. (다 쓴 참조 = 앞으로 다시 쓰지 않을 참조)

그래서 아래와 같이 해당 참조를 다 썼을 때 null 처리(참조 해제)하여 해당 객체를 더는 쓰지 않을 것임을 가비지 커렉터에 알려야 한다.

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

2. 캐시에서의 메모리 누수 & 해결책

1. 방법 1

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.containKey(key)){
            return cache.get(key);
        } else {
            // TODO DB에서 읽어오거나 REST API를 통해 읽어올 수 있습니다.
            Post post = new Post();
            cache.put(key, post);
            return post;
        }
    }
    
    public Map<CacheKey, Post> getCache(){
        return cache;
    }
}

class PostRepositoryTest{
    
    @Test
    void cache() throws InterruptedException {
        PostRepository postRepository = new PostRepository();
        Integer p1 = 1;
        postRepository.getPostById(p1);
        
        assertFalse(postRepository.getCache().isEmpty());
        
        p1 = null;
        
        // TODO run gc
        System.out.println("run gc");
        System.gc(); // 항상 이 시점에 gc가 실행된다는 보장은 없지만, 실행이 되기는 한다.
        System.out.println("wait");
        Thread.sleep(3000L);
        
        assertTrue(postRepository.getCache().isEmpty()); // AssertionFailedError
    }
}

해당 코드를 실행시켜보면 gc가 실행되더라도 postRepository가 비어있지 않다는 것을 알 수 있다.

public class PostRepository{

    ...	
    public PostRepository(){
        this.cache = new WeakHashMap<>();
    }
    ...
}

기존의 HashMap에서 WeakHashMap으로 바꾸었다. 그러면 더 이상 참조하는 곳(위에서는 p1)이 없으면 postRepository가 비어있게 된다. 'p1 = null;'이 없더라도 작동을 한다. (더 이상 참조하는 곳이 없기 때문)

이유를 설명하자면 getPostById라는 메서드 안에서 CacheKey가 생성되고, 해당 메서드가 끝나면 CacheKey가 더 이상 유효하지 않기 때문이다. 이 원리를 이용하면 아래와 같이 표현할 수도 있다.

2. 방법 2

public class PostRepository{

    private Map<CacheKey, Post> cache;
    
    public PostRepository(){
        this.cache = new WeakHashMap<>();
    }
    
    public Post getPostById(CacheKey key){
        if(cache.containKey(key)){
            return cache.get(key);
        } else {
            // TODO DB에서 읽어오거나 REST API를 통해 읽어올 수 있습니다.
            Post post = new Post();
            cache.put(key, post);
            return post;
        }
    }
    
    public Map<CacheKey, Post> getCache(){
        return cache;
    }
}

class PostRepositoryTest{
    
    @Test
    void cache() throws InterruptedException {
        PostRepository postRepository = new PostRepository();
        CacheKey key1 = new CacheKey(1);
        postRepository.getPostById(key1);
        
        assertFalse(postRepository.getCache().isEmpty());
        
        key1 = null;
        
        // TODO run gc
        System.out.println("run gc");
        System.gc(); // 항상 이 시점에 gc가 실행된다는 보장은 없지만, 실행이 되기는 한다.
        System.out.println("wait");
        Thread.sleep(3000L);
        
        assertTrue(postRepository.getCache().isEmpty());
    }
}

key1은 해당 메서드가 끝나기 전까지 유효한데 'key1 = null;'을 해주었기 때문에 테스트 코드가 적상 작동하는 것을 알 수 있다. 방법 1과 다르게 이 경우에 'key1 = null;'이 없다면 정상 작동하지 않는다.

3. 방법 3

세 번째 방법은 객체를 넣거나 빼거나 할 때 직접 관리하는 것이다. 제일 오래된 것을 찾아서 삭제하거나 LRU 캐시 등을 사용하는 것이다.

4. 방법 4

마지막 방법은 백그라운드 스레드를 사용하는 것이다.

public class PostRepository{

    private Map<CacheKey, Post> cache;
    
    public PostRepository(){
        this.cache = new HashMap<>();
    }
    
    public Post getPostById(CacheKey key){
        if(cache.containKey(key)){
            return cache.get(key);
        } else {
            // TODO DB에서 읽어오거나 REST API를 통해 읽어올 수 있습니다.
            Post post = new Post();
            cache.put(key, post);
            return post;
        }
    }
    
    public Map<CacheKey, Post> getCache(){
        return cache;
    }
}

@Test
void backgroundThread() throws InterruptedException {
    ScheduledExecutorService executor = Executors.newSchedultedThreadPool(1);
    CacheKey1 = new CacheKey(1);
    postRepostiory.getPostbyId(key1);
    
    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); // 처음 1초 후에, 매 3초 마다 실행하도록 하였다.
    
    Thread.sleep(20000L);
    
    executor.shutdown();
}

20초 동안 애플리케이션이 실행되고 있는 동안 백그라운드에서 3초마다 계속해서 제일 뒤에 있는 객체를 하나씩 삭제한다.

3. 리스너(listener) 혹은 콜백(callback)에서의 누수 & 해결책

public class ChatRoon {
    
    private List<WeakReference<User>> users;
    
    public ChatRoom() {
        this.users = new ArrayList<>();
    }
    
    public void addUser(User user) {
        this.users.add(new WeakReference<>(user));
    }
    
    public void sendMessage(String message) {
        users.forEach(wr -> Objects.requireNonNull(wr.get()).receive(message));
    }
    
    public List<WeakReference<User>> getUsers() {
        return users;
    }   
}

@Test
void chatRoom() throws InterruptedException {
    ChatRoom chatRoom = new ChatRoom();
    User user1 = new User();
    User user2 = new User();
    
    chatRoom.addUser(user1);
    chatRoom.addUser(user2);
    
    chatRoom.sendMessage("hello");
    
    user1 = null
    
    System.gc();
    
    Thread.sleep(5000L);
    
    List<WeakReference<User>> users = chatRoom.getUsers();
    assertTrue(users.size() == 1);
}

해당 테스트 코드를 그냥 실행시키면 틀리게 된다. WeakReference를 삭제해주는 기능은 WeakHashMap에 들어있는 기능이기 때문이다. 그래서 만약 위의 테스트 코드가 성공하기 위해서는 커스텀한 List를 만들 필요가 있다.

List안에 WeakReference가 있는 경우를 설명하기 위한 것이지, 리스너 혹은 콜백의 상황에서는 weak reference로 저장하면 가비지 컬렉터가 즉시 수거해 간다.

해당 글은 백기선 님의 '이펙티브 자바 완벽 공략'을 수강하고 작성한 것입니다.

'📂 JAVA > 이펙티브 자바' 카테고리의 다른 글

try-finally 보다는 try-with-resources를 사용하라 - [2장 객체 생성과 파괴(아이템9)] (0)	2023.01.03
finalizer와 cleaner 사용을 피하라 - [2장 객체 생성과 파괴(아이템8)] (0)	2023.01.03
불필요한 객체 생성을 피하라 - [2장 객체 생성과 파괴(아이템6)] (0)	2022.11.29
자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 - [2장 객체 생성과 파괴(아이템5)] (0)	2022.11.28
인스턴스화를 막으려거든 private 생성자를 사용하라 - [2장 객체 생성과 파괴(아이템4)] (0)	2022.11.28