Java에서의 재활용 객체 마킹과 객체의 2차 마킹 과정에 대한 자세한 설명

이 글은 주로 자바 재활용 객체 마킹 관련 내용과 객체의 2차 마킹 과정을 소개하는 글인데, 편집자가 보기에 필요하신 분들은 참고하시면 좋을 것 같습니다.

1. 사물의 표시

1. 표시란 무엇입니까? 표시하는 방법?

첫 번째 질문은 모두가 알고 있다고 생각합니다. 표시는 가비지 수집기 청소를 용이하게 하기 위해 죽은 물체를 표시하는 것입니다. 표시 방법에는 일반적으로 참조 카운팅과 도달 가능성 분석의 두 가지 방법이 있습니다.

참조 카운팅은 객체에 참조 카운터를 추가하는 것입니다. 참조가 있을 때마다 1씩 증가합니다. 참조가 유효하지 않으면 1씩 감소합니다. 카운터가 0에 도달하면 재활용 가능으로 표시됩니다. 이 판단은 매우 효율적이지만 많은 주류 가상 머신에서는 이 방법을 사용하지 않습니다. 주로 여러 개체 간의 순환 참조 문제를 해결하기 어렵기 때문입니다. 많이 사용되지는 않지만 여전히 배울 가치가 있습니다.

public class Test {
private Object obj;
Public static void main(){
Test t1=new Test();
Test t2=new Test();
t1.obj=t2;
t2.obj=t1;
t1=null;
t2=null;
//如果对象在这行发生gc，那么t1和t2对象是否能被回收
System.gc();
}
}

도달 가능성 분석의 기본 아이디어는 "GC Roots"라는 개체를 시작점으로 사용하여 이러한 노드에서 검색을 시작하고 직접 또는 간접적인 참조 관계가 있는 개체를 검색하는 것입니다. 이러한 개체는 체인 형태로 결합되어 참조 체인이라고도 하는 "관계 네트워크"를 형성합니다. 마지막으로 가비지 수집기는 이 관계 네트워크에 없는 일부 개체를 수집합니다. 사진과 같이

GC Roots 객체에 연결된 객체는 확실히 살아 있는 객체이며, 오른쪽의 다이 객체는 GCROOTS와 관련이 없으므로 재활용 가능한 객체로 표시됩니다. 현재 주류 상용 가상머신도 비슷한 방법을 사용하고 있습니다. 그렇다면 "GC Roots"로 사용할 수 있는 개체는 무엇입니까? Java에는 "GC Roots"로 사용할 수 있는 객체 유형이 네 가지 있습니다.

1: 스택 프레임의 참조 객체(1장에서 명사). (스택에서)

2: 정적 속성에 의해 참조되는 개체입니다. (메서드 영역에서)

3: 상수로 참조되는 객체. (메서드 영역에서)

4: 로컬 메소드 스택에서 JNI가 참조하는 객체입니다. (로컬 메소드 스택에서)

2. 객체의 2차 재활용

객체에 표시가 있다고 했는데, 표시가 되어 있으면 반드시 재활용된다는 뜻 아닌가요? Object 클래스에 finalize() 메서드가 있다는 것을 기억하실지 모르겠습니다. 모든 클래스는 Object 클래스를 상속하므로 이 메서드가 기본적으로 구현됩니다.

finalize의 작동 원리는 다음과 같아야 합니다. 가비지 수집기가 객체가 차지한 저장 공간을 해제할 준비가 되면 먼저 finalize()를 호출하고 다음 가비지 수집 프로세스 중에만 객체의 메모리가 실제로 따라서 finalize()를 사용하면 가비지 수집 중에 몇 가지 중요한 청소 작업을 수행할 수 있습니다. finalize()는 언제 호출됩니까?

모든 객체가 가비지인 경우가 있습니다. Collection System.gc()를 실행할 때와 같이 자동으로 호출됩니다.
2. finalize 메서드는 프로그램이 종료될 때 각 개체에 대해 한 번씩 호출됩니다.

3. 명시적으로 finalize 메소드 호출

여기서 재활용이란 표시된 후를 말합니다. 문제는 이전 장에서 언급한 "관계 네트워크"(참조 체인)에 객체가 더 이상 존재하지 않지만 개발자가 finalize()를 다시 작성한 경우입니다. , 개체가 "관계 네트워크"에 다시 추가됩니다. 이는 개체가 여전히 우리에게 유용하고 재활용되어서는 안 되지만 표시가 되어 있음을 의미합니다.

​​​​​​​​​​​​​​​​​​​​​​​​​​가상 머신의 접근 방식은 두 번 표시하는 것입니다. "관계 네트워크"에 있지 않습니다. 두 번째로 객체가 finalize() 메서드를 구현했는지 여부를 먼저 확인해야 합니다. 구현되지 않은 경우 객체가 재활용 가능한지 직접 확인하고, 구현된 경우 해당 객체를 배치합니다. 우선 순위 스레드가 이를 실행한 다음, 이번에는 표시된 개체가 실제로 재활용됩니다.

요약: 간단히 말하면 객체가 처음으로 표시되고 다음 GC 이전에 객체의 finalize() 메서드가 실행됩니다. finalize() 메서드를 실행할 때 객체에 finalize() 메서드가 구현되었는지 여부를 판단합니다. 구현되지 않은 경우에는 직접 지워지고 객체는 finalize 메서드를 실행하기 위해 대기열에 배치됩니다. 그리고 두 번째로 표시됨
Java 루트 검색 알고리즘에서 판단됨 객체에 대한 접근성이 반드시 도달할 수 없는 객체를 정리해야 한다는 의미는 아닙니다. 이때, 실제로 개체가 죽었다고 판단하려면 적어도 두 가지 마킹 과정을 거쳐야 합니다. 개체가 루트 검색을 수행한 후 GC 루트와 관련된 참조 체인이 없음을 발견하면 일단 필터링되면 필터링 조건은 객체가 finalize() 메소드를 실행해야 하는지 여부입니다. 가상 머신에 의해 호출되면 가상 머신은 두 상황을 "실행할 필요 없음"으로 처리합니다.
즉, 객체가 finalize() 메서드를 재정의하면 해당 객체가 finalize() 메서드를 실행하는 데 필요하다고 판단한 다음 해당 객체를 F-Queue 대기열에 배치한 후 나중에 The 가상 머신에 의해 자동으로 생성된 우선순위가 낮은 Finalizer 스레드가 실행됩니다. 여기서 소위 실행이란 가상 머신이 이 메서드를 시작하지만 실행이 완료될 때까지 기다리지 않는다는 것을 의미합니다. 그 이유: 객체가 finalize() 메서드에서 느리게 실행되거나 무한 루프가 발생하는 경우(극단적인 경우) F-Queue 대기열의 다른 객체가 영구적으로 대기 상태가 되거나 심지어 원인이 될 수도 있습니다. 재활용 시스템의 전체 메모리가 충돌합니다. finalize() 메서드는 객체가 죽음의 운명을 피할 수 있는 마지막 기회입니다. 나중에 객체가 finalize()에 성공적으로 저장되기를 원하는 경우 GC는 F-Queue에 객체를 표시합니다. ----참조 체인의 모든 항목과 다시 연결하는 한, 개체가 이스케이프되지 않으면 두 번째로 표시될 때 "재활용 예정" 컬렉션에서 제거됩니다. 시간이 지나면 재활용됩니다. 코드 예시: "Java Virtual Machine에 대한 심층적인 이해"

해당 장을 참조하세요.

위 내용은 Java에서의 재활용 객체 마킹과 객체의 2차 마킹 과정에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!