가비지 컬렉터와 메모리 할당 전략

class Node {
    int value;
    Node next; // 다른 Node를 참조하는 변수

    public Node(int value) {
        this.value = value;
    }
}

public class CircularReferenceExample {
    public static void main(String[] args) {
        Node node1 = new Node(1);
        Node node2 = new Node(2);

        // 순환 참조 생성
        node1.next = node2;
        node2.next = node1;

	// 참조 해제
        node1 = null;
        node2 = null;
        
        System.gc();
    }
}

다음 코드에서 node1 과 node2는 순환참조 후에 모두 할당을 해제했습니다. 이 객체는 더 이상 사용하지 않은 객체이지만, 각각의 참조 카운터가 여전히 1이기 때문에 이 두 객체를 회수하지 못하는 문제가 발생합니다.

JVM에서는 해당 알고리즘을 사용하지 않는다고 했기 때문에 실제 해당 객체를 회수하는지 검증해보겠습니다.

할당을 해제한 경우와 해제하지 않은 경우의 힙 사용량이 달라진 것을 확인할 수 있습니다. 이를 통해 JVM은 참조 카운팅 알고리즘을 사용하지 않는 것을 간접적으로 확인할 수 있습니다.

그럼 JVM에서는 어떤 알고리즘을 사용할까요?

2-2. 도달 가능성 분석 알고리즘

이 알고리즘의 기본 아이디어는 GC루트라고 하는 루트 객체들을 시작 노드 집합으로 쓰는 것입니다. 시작 노드들로부터 출발하여 참조하는 다른 객체를 탐색합니다. 이 탐색 과정에서 만들어지는 경로를 참조체인이라고 합니다. 특정 객체가 참조 체인에 없다면 회수 대상이 됩니다.

여기서 reachability라는 개념이 나오는데 어떤 객체에 유효한 참조가 있으면 'reachable'로, 없으면 'unreachable'로 구별합니다.

그렇다면, GC 루트는 구체적으로 어떤 것일까요?

런타임 데이터 영역은 위와 같이 스레드가 차지하는 영역들과, 객체를 생성 및 보관하는 하나의 큰 힙, 클래스 정보가 차지하는 영역인 메서드 영역, 크게 세 부분으로 나눌 수 있습니다. 위 그림에서 객체에 대한 참조는 화살표로 표시되어 있습니다.

힙에 있는 객체들에 대한 참조는 다음 4가지 종류 중 하나입니다.

힙 내의 다른 객체에 의한 참조
Java 스택, 즉 Java 메서드 실행 시에 사용하는 지역 변수와 파라미터들에 의한 참조
네이티브 스택, 즉 JNI(Java Native Interface)에 의해 생성된 객체에 대한 참조
메서드 영역의 정적 변수에 의한 참조

이들 중 힙 내의 다른 객체에 의한 참조를 제외한 나머지 3개가 GC 루트로, reachability(도달 가능성)를 판가름하는 기준이 됩니다.

2-3. 다시 참조 이야기

객체의 생사 판단과 참조와는 떼어서 생각할 수 없습니다. 참조 카운팅 알고리즘이든, 도달가능성 분석 알고리즘이든 모두 참조를 통해 분석하기 때문입니다.

JVM이 발전하며 기존의 참조의 개념으로 표현할 수 없는 '버리기는 아까운' 객체를 표현하는 방식이 생겨납니다. "메모리가 여유롭다면 그냥 두고, GC 하고 나서도 메모리가 부족하면 그때 회수하자."라는 개념이 도입됩니다.

a. 강한 참조

Object obj = new Object();

전통적인 참조를 의미합니다. 관계가 남아 있는 객체는 GC가 절대로 회수하지 않습니다.

b. 부드러운 참조

import java.lang.ref.SoftReference;

public class SoftReferenceExample {
    public static void main(String[] args) {
        Object obj = new Object(); // 강한 참조
        SoftReference<Object> softRef = new SoftReference<>(obj); // 부드러운 참조 생성

        obj = null; // 강한 참조 해제
        System.gc(); // GC 호출

        if (softRef.get() != null) {
            System.out.println("부드러운 참조 객체는 아직 남아 있음");
        } else {
            System.out.println("부드러운 참조 객체는 수거됨");
        }
    }
}

유용하지만 필수는 아닌 객체를 표현합니다. 부드러운 참조만 남은 객체라면 메모리 오버플로우가 나기 전에 두 번째 회수를 위한 회수 목록에 추가됩니다. SoftReference클래스 형태로 구현됩니다.

c. 약한 참조

import java.lang.ref.WeakReference;

public class WeakReferenceExample {
    public static void main(String[] args) {
        Object obj = new Object(); // 강한 참조
        WeakReference<Object> weakRef = new WeakReference<>(obj); // 약한 참조 생성

        obj = null; // 강한 참조 해제
        System.gc(); // GC 호출

        if (weakRef.get() != null) {
            System.out.println("약한 참조 객체는 아직 남아 있음");
        } else {
            System.out.println("약한 참조 객체는 수거됨");
        }
    }
}

부드러운 참조와 비슷하지만, 연결 강도가 더 약합니다. 대상 객체를 참조하는 경우가 WeakReferences 객체만 존재하는 경우 GC의 대상이 됩니다. 다음 GC 실행 시 무조건 힙 메모리에서 제거됩니다.

d. 유령 참조

import java.lang.ref.PhantomReference;
import java.lang.ref.ReferenceQueue;

public class PhantomReferenceExample {
    public static void main(String[] args) {
        Object obj = new Object(); // 강한 참조
        ReferenceQueue<Object> queue = new ReferenceQueue<>(); // 참조 큐 생성
        PhantomReference<Object> phantomRef = new PhantomReference<>(obj, queue); // 유령 참조 생성

        obj = null; // 강한 참조 해제
        System.gc(); // GC 호출

        // 큐를 통해 수거된 유령 참조 감지
        if (queue.poll() != null) {
            System.out.println("유령 참조 객체가 수거됨");
        } else {
            System.out.println("유령 참조 객체는 아직 수거되지 않음");
        }
    }
}

참조 중에 가장 약합니다. 객체 자체에 접근할 수는 없고, 수거 후의 동작을 정의하는 데 사용됩니다. 객체가 수거된 후 참조 큐로 이벤트를 전달합니다.

2-4. 도달 불가능한 객체는 반드시 죽는 걸까?

도달 불가능하다고 해서 객체가 반드시 죽었다고 할 수 있을까요? 아닙니다. 아직 '유예'단계가 있습니다. 사망 선고를 내리려면 두 번의 표시(marking) 단계를 거쳐야 합니다.

도달 가능성 알고리즘으로 참조 체인을 찾지 못한 객체에는 첫 번째 표시가 이루어지며 이어서 필터링이 진행됩니다. 필터링 조건은 "종료자(finalizer) 메서드를 실행해야 하는 객체인가" 입니다.

finalize()를 실행해야 하는 객체로 판명되는 F-Q(F-Queue)라는 대기열에 추가됩니다. 그러면 가상 머신이 나중에 우선순위가 낮은 종료자 스레드를 생성해 F-Q에 들어있는 객체들의 finalize()를 실행합니다.

참고로 JVM은 스레드를 시작만 하고, 기다리지 않습니다. 즉 무한루프가 돌거나 너무 오래 걸리면 큐에 모든 객체는 대기해야 하고, 최악의 경우 GC시스템이 망가질 수 있습니다.

그래서 finalize()는 사용하지 않는 것을 권장하며, JDK 9부터는 Deprecated 가 되었습니다.

2-5. 메서드 영역 회수

힙 영역뿐만 아니라 메서드 영역도 GC의 영역입니다. 메서드 영역에서의 GC는 크게 2가지를 회수합니다. '상수' 및 '클래스'입니다.

상수

참조가 있는지 확인하고, 없으면 삭제합니다. (힙에서 객체 회수하는 방법과 유사)

클래스

클래스는 아래 3가지 조건을 부합하면 회수합니다.

이 클래스의 인스턴스가 모두 회수되었다. (힙에 해당 클래스와 하위 클래스의 인스턴스가 하나도 존재하지 않는다.)
클래스 로더가 회수되었다.
이 클래스에 해당하는 java.lang.Class 객체를 아무 곳에서 참조하지 않고, 리플랙션 기능으로 이 클래스의 메서드를 이용하는 곳도 없다.

이와 같이 회수 자체는 할 수 있지만, 힙에 비해 효율이 좋지 않습니다.

3. 다음으로

여태까지 저희는 어떤 객체의 생존 유무를 판단하는 원리를 알아봤습니다.

이 원리를 바탕으로 여러 GC들이 어떤 목표를 가지고 어떤 부분을 최적화하려고 했는지 알아보려고 합니다.

가장 초기에는 모든 프로그램을 멈추고 GC를 실행시켰지만, 비동기 동작이나 더 높은 처리량을 위해 점점 GC가 발전되는 것을 확인할 수 있을 것입니다.

다음에는 본격적으로 GC 알고리즘에 대해 알아보겠습니다.

출처 :

- 책 JVM 밑바닥부터 파헤치기

- https://d2.naver.com/helloworld/329631

'BE > JVM' 카테고리의 다른 글

JVM에서 객체 들여다보기 (2)	2024.12.17

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

gamxong

가비지 컬렉터와 메모리 할당 전략 - 1. 죽은 객체 판단

1. 그걸 왜 알아야 하는데?

2. 죽은 객체 찾기

2-1. 참조 카운팅 알고리즘

2-2. 도달 가능성 분석 알고리즘

2-3. 다시 참조 이야기

2-4. 도달 불가능한 객체는 반드시 죽는 걸까?

2-5. 메서드 영역 회수

3. 다음으로

출처 :

'BE > JVM' 카테고리의 다른 글

댓글

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역

가비지 컬렉터와 메모리 할당 전략 - 1. 죽은 객체 판단

1. 그걸 왜 알아야 하는데?

2. 죽은 객체 찾기

2-1. 참조 카운팅 알고리즘

2-2. 도달 가능성 분석 알고리즘

2-3. 다시 참조 이야기

2-4. 도달 불가능한 객체는 반드시 죽는 걸까?

2-5. 메서드 영역 회수

3. 다음으로

출처 :

'BE > JVM' 카테고리의 다른 글

관련글

댓글

티스토리툴바

단축키

내 블로그

블로그 게시글

모든 영역

2-4. 도달 불가능한 객체는 반드시 죽는 걸까?

2-5. 메서드 영역 회수