Java의 가상 머신 가비지 수집 메커니즘에 대한 자세한 그래픽 및 텍스트 설명

Java Virtual Machine에서는 객체와 배열의 메모리가 힙에 할당되고, 가비지 컬렉터에 의해 복구된 메인 메모리는 힙 메모리에 있습니다. 동적으로 생성된 객체나 배열이 Java 프로그램 실행 중에 제때에 재활용되지 않고 계속 누적되면 결국 힙 메모리가 가득 차서 OOM이 발생하게 됩니다.

JVM은 GC 메커니즘이라고 하는 가비지 수집 메커니즘을 제공합니다. GC 메커니즘을 통해 힙에 있는 가비지 개체는 작업 중에 지속적으로 재활용될 수 있으므로 프로그램의 정상적인 작동이 보장됩니다.

가비 개체 결정

우리 모두는 소위 "쓰레기" 개체가 프로그램 실행 중에 더 이상 유용하지 않은 개체, 즉 더 이상 살아 있지 않은 개체를 의미한다는 것을 알고 있습니다. 그렇다면 힙에 있는 개체가 "쓰레기"이고 더 이상 살아 있지 않은지 여부를 어떻게 판단할 수 있을까요?

참조 카운팅 방법

각 객체에는 객체가 참조된 횟수를 저장하는 데 사용되는 참조 카운팅 속성이 있습니다. 참조 개수가 0이면 해당 객체를 참조하지 않았음을 의미하며, 해당 객체는 사용되지 않으며 가비지 객체로 판단할 수 있다. 그러나 이 방법에는 객체 간의 상호 참조 또는 순환 참조 문제를 해결할 수 없다는 큰 버그가 있습니다. 두 객체가 서로 참조할 때 다른 객체와 참조 관계가 없으며 동일한 번호를 갖습니다. 0이 아니므로 재활용되지 않지만 실제로 이 두 개체는 더 이상 유용하지 않습니다.

도달성 분석(루트 검색 방법)

참조 카운팅을 사용하여 발생하는 문제를 피하기 위해 Java는 도달성 분석 방법을 사용하여 가비지 개체를 결정합니다.

이 방법은 모든 개체의 참조 관계를 트리로 상상할 수 있습니다. 트리의 루트 노드 GC 루트에서 참조된 모든 개체는 트리의 노드에 도달할 수 있는 개체와 노드에 없는 다른 개체를 통과합니다. 도달할 수 없는 객체입니다.

그렇다면 어떤 객체가 GC의 루트 노드로 사용될 수 있을까요?

• 가상 머신 스택에서 참조되는 개체(프레임 스택의 로컬 변수 테이블)

• 메서드 영역의 정적 속성에서 참조되는 개체

• 메서드 영역의 상수에서 참조되는 개체

• Local 메소드 스택 JNI에서 참조하는 객체

참조 상태

가비지 수집 메커니즘은 참조 계산이든 도달 가능성 분석이든 객체 참조와 관련됩니다. Java에는 4가지 참조 상태가 있습니다.

• 강력함 참조 - 우리가 사용하는 대부분의 참조는 실제로 강력한 참조이며 가장 일반적으로 사용되는 참조입니다. 객체에 강력한 참조가 있는 경우 이는 해당 객체가 도달 가능한 상태에 있으며 가비지 수집기가 해당 객체를 재활용하지 않는다는 의미입니다. 시스템 메모리가 매우 부족하더라도 Java 가상 머신은 오류를 발생시키고 프로그램을 종료시킵니다. 강력하게 참조된 개체를 재활용하는 것보다 비정상적으로 참조된 개체에 대한 참조입니다. 따라서 강력한 참조는 Java 메모리 누수의 주요 원인 중 하나입니다. OutOfMemoryError

• 소프트 참조 - 객체에는 소프트 참조만 있습니다. 메모리 공간이 충분하면 가비지 수집기가 이를 회수하지 않습니다. 메모리 공간이 부족하면 해당 객체의 메모리가 회수됩니다. 가비지 수집기가 이를 수집하지 않는 한 프로그램은 해당 객체를 사용할 수 있습니다.

• 약한 참조 - 객체에는 약한 참조만 있으며 이는 불필요한 것과 유사합니다. 약한 참조는 소프트 참조와 유사하지만 참조 수준이 더 낮습니다. 약한 참조와 소프트 참조의 차이점은 약한 참조만 있는 객체의 수명 주기가 더 짧다는 것입니다. 가비지 수집기 스레드가 해당 관할권에 있는 메모리 영역을 검색하는 과정에서 약한 참조만 있는 객체가 발견되면 현재 메모리 공간이 충분한지 여부에 관계없이 해당 메모리가 회수됩니다.

• 더미 참조 - 객체는 가상 참조만 보유하므로 참조가 없는 것과 동일하며 언제든지 가비지 수집기에 의해 재활용될 수 있습니다. 가상 참조는 주로 가비지 수집 대상 개체의 활동을 추적하는 데 사용되며 일반적으로 사용하지 않습니다.

가비지 수집 알고리즘

도달성 분석 알고리즘을 통해 어떤 객체를 재활용해야 하는지 판단할 수 있습니다. 그렇다면 재활용은 어떻게 수행해야 할까요?

Mark-clear 알고리즘

먼저 ​​재활용 가능한 객체 메모리를 표시한 후 재활용된 메모리를 지워야 합니다.

표시 및 지우기 알고리즘(재활용 전)

표시 및 지우기 알고리즘(재활용 후)

그러나 이 경우 프로그램이 실행됨에 따라 메모리가 지속적으로 할당 및 해제되며, 그리고 그 중 많은 부분이 힙 불연속 여유 메모리 영역, 즉 메모리 조각화에서 생성됩니다. 이런 식으로 여유 메모리가 충분하더라도 충분히 큰 메모리를 할당하지 못할 수 있으며, GC가 자주 발생하여 효율성에 영향을 미치거나 심지어 OOM이 발생하는 경우도 있습니다.

Mark-Compact 알고리즘

Mark-Clear 알고리즘과 달리 Mark-Compact 알고리즘은 마킹 후 재활용 가능한 메모리를 직접 정리하지 않고, 남아 있는 모든 개체를 한쪽 끝으로 이동한 다음 재활용 가능한 메모리를 지웁니다.

마킹 - 데이터 정렬 알고리즘(재활용 전)

마킹 - 데이터 정렬 알고리즘(재활용 후)

이 방법의 장점은 메모리 조각화가 발생하지 않는다는 것입니다.

복사 알고리즘

복사 알고리즘은 먼저 메모리를 두 개의 블록으로 나누고 먼저 메모리 블록 중 하나에 메모리를 할당해야 합니다. 이 메모리 블록이 할당되면 가비지 수집이 수행된 다음 남아 있는 모든 개체가 On이면 첫 번째 메모리 블록이 완전히 지워집니다.

복사 알고리즘(재활용 전)

복사 알고리즘(재활용 후)

이 알고리즘은 메모리 조각화를 생성하지 않지만 메모리 공간의 절반만 사용하는 것과 같습니다. 동시에, 복제 알고리즘은 살아남은 개체의 수와 관련이 있습니다. 살아남은 개체의 수가 많으면 복제 알고리즘의 효율성이 크게 떨어집니다.

세대 수집 알고리즘

Java 가상 머신에서는 객체의 수명 주기가 길 수도 있고 짧을 수도 있습니다. 대부분의 객체는 짧은 수명 주기를 가지므로 오랫동안 메모리에 남아 있습니다. 개체의 수명 길이에 따라 개체가 서로 다른 영역에 배치됩니다. 세대별 수집 알고리즘을 사용하는 Java 가상 머신 힙에서는 일반적으로 이러한 세 가지 유형의 개체를 저장하기 위해 세 가지 영역으로 나뉩니다.

• 새 세대 - 새로 생성된 개체는 일반적으로 코드가 실행될 때 계속해서 수집됩니다. 새 개체를 만듭니다. 새로 생성된 개체 중 다수는 지역 변수이며 곧 가비지 개체가 됩니다. 이러한 객체는 Young Generation이라는 메모리 영역에 배치됩니다. 새로운 세대는 쓰레기 개체가 많고 살아남은 개체가 거의 없다는 특징이 있습니다.

• 구세대 - 일부 개체는 매우 일찍 생성되었으며 많은 GC 후에도 재활용되지 않았지만 항상 살아남았습니다. 이러한 객체들은 Old Generation이라는 영역에 배치됩니다. 구세대의 특징은 살아남은 개체가 많고 쓰레기 개체가 거의 없다는 것입니다.

• 영구 생성 - 일부 정적 개체, 상수 등과 같이 가상 머신의 수명 주기와 함께 영구적으로 존재하는 일부 개체입니다. 이러한 개체는 영구 생성이라는 영역에 배치됩니다. 영구 생성의 특징은 이러한 개체는 일반적으로 가비지 수집이 필요하지 않으며 가상 머신이 실행되는 동안 유지된다는 것입니다. (Java 1.7 이전에는 영구 생성 객체가 메소드 영역에 저장되었습니다. Java 1.7 메소드 영역의 영구 생성 객체가 힙으로 이동되었습니다. Java 1.8에서는 영구 생성이 힙에서 제거되었습니다. 이 메모리는 )

세대 수집 알고리즘은 신세대와 구세대를 기반으로 가비지 수집도 수행합니다.

신세대 지역의 경우 GC마다 많은 쓰레기 객체가 재활용되고 소수만이 살아남게 됩니다. 따라서 복사 재활용 알고리즘을 사용하며, GC 중에 살아남은 소수의 객체를 복사할 수 있습니다.

신세대 영역에서는 1:1 비율에 따라 복제 및 재활용이 아닌 8:1:1 비율에 따라 Eden, SurvivorA, SurvivorB 3개 ​​영역으로 구분됩니다. 그 중 에덴(Eden)은 에덴동산을 뜻하며, 그 안에 생성된 수많은 새로운 사물을 묘사하는 생존자(Survivor) 영역은 생존자, 즉 GC를 겪은 후에도 여전히 살아남는 사물을 가리킨다.

1. Eden 영역은 외부 세계에 힙 메모리를 제공합니다. Eden 영역이 거의 가득 차면 Minor GC(New Generation GC)를 수행하고 살아남은 객체를 SurvivorA 영역에 넣고 Eden 영역을 클리어합니다.

2. Eden 영역이 클리어된 후에도 계속해서 힙을 제공합니다.

3. Eden 영역이 다시 채워지면 Eden 영역과 SurvivorA 영역에 대해 동시에 Minor GC(신세대 GC)가 수행되고 살아남은 개체가 저장됩니다. 이때, Eden 영역과 SurvivorA 영역이 동시에 클리어됩니다.

4. Eden 영역은 계속해서 외부에 힙 메모리를 제공하고, 즉 Eden 영역을 채운 후 위의 과정을 반복합니다. Eden 영역과 Survivor 영역에서 살아남은 개체는 다른 Survivor 영역에 배치됩니다.

5. Survivor 영역이 채워지고, 아직 복사되지 않은 개체가 있거나 일부 개체가 15개 정도 살아남은 경우; 이때 남은 객체는 Old Generation 영역에 배치되고 Old Generation 영역도 채워지면 Major GC(Old Generation GC)가 수행되어 Old Generation 영역에서 가비지 수집이 수행됩니다.

Old Generation 영역의 객체는 일반적으로 각 GC 동안 생존하는 객체가 더 많기 때문에 Mark-and-Organize 알고리즘을 사용하여 GC 동안 메모리를 유발하지 않고 살아남은 소수의 객체를 이동합니다. 분열.

GC 트리거 유형

Java Virtual Machine은 각 GC 트리거에 대한 정보를 출력하고, 로그를 기반으로 GC가 트리거된 이유를 분석할 수 있습니다.

• GC_FOR_MALLOC: 힙에 개체를 할당할 때 메모리 부족으로 인해 GC가 트리거됨을 나타냅니다.

• GC_CONCURRENT: 애플리케이션의 힙 메모리가 특정 양에 도달하거나 거의 가득 찬 것으로 이해될 수 있으면 시스템은 자동으로 GC 작업을 트리거하여 메모리를 해제합니다.

• GC_EXPLICIT: 애플리케이션이 System.gc, VMRuntime.gc 인터페이스를 호출하거나 SIGUSR1 신호를 수신할 때 GC가 트리거됨을 나타냅니다.

• GC_BEFORE_OOM: OOM 예외 발생을 준비하기 전 마지막 노력에 의해 GC가 트리거되었음을 나타냅니다.

위 내용은 Java의 가상 머신 가비지 수집 메커니즘에 대한 자세한 그래픽 및 텍스트 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!