Java에서는 정수, 참조 등 기본형을 제외한 모든 객체가 스택 영역이 아닌 힙 영역에 할당됩니다. 이 디자인은 프로그래머가 변수의 수명 주기에 주의를 기울일 필요를 없애주지만 더 많은 쓰레기를 생성하는 대가를 치르게 됩니다.
접근성
모든 포인터를 역참조하여 프로그램에서 직접 접근할 수 있는 데이터에 접근할 수 있습니다.
지역성의 원리
프로그램의 저장 위치에 짧은 시간 내에 다시 접근할 가능성이 높다면 해당 프로그램은 시간적 지역성을 갖는다고 합니다. 액세스된 메모리 위치에 인접한 위치가 짧은 시간 내에 액세스될 가능성이 있는 경우 프로그램은 공간적으로 지역화됩니다.
일반적으로 프로그램은 코드의 10%를 실행하는 데 시간의 90%를 소비한다고 알려져 있습니다.
여러 가비지 컬렉터의 원리
마크-스윕 컬렉터
이 컬렉터는 먼저 객체 그래프를 순회하여 도달 가능한 객체를 표시한 다음 스택을 스캔하여 표시되지 않은 객체를 찾습니다. 객체를 삭제하고 메모리를 해제합니다. 이 유형의 수집기는 일반적으로 단일 스레드를 사용하여 작업하고 다른 작업을 중지합니다. 게다가 표시되지 않은 개체만 지우고 표시된 개체는 압축하지 않기 때문에 메모리 조각화가 많이 발생하여 메모리가 낭비됩니다.
Mark-Compact Collector
Mark-Sweep-Compact Collector라고도 하며 Mark-Sweep Collector와 동일한 마킹 단계를 갖습니다. 두 번째 단계에서는 스택을 압축하기 위해 표시된 개체가 스택의 새로운 영역에 복사됩니다. 이 수집기는 다른 작업도 중지합니다.
복사 컬렉터
이 컬렉터는 스택을 반 공간이라고 불리는 두 개의 도메인으로 나눕니다. 매번 공간의 절반만 사용되며 JVM에서 생성된 새 객체는 공간의 나머지 절반에 배치됩니다. GC가 실행되면 도달 가능한 객체를 공간의 나머지 절반에 복사하여 스택을 압축합니다. 이 방법은 수명이 짧은 개체에 적합합니다. 수명이 긴 개체를 계속 복사하면 효율성이 떨어집니다. 그리고 주어진 크기의 힙에 대해 항상 절반만 사용되기 때문에 두 배의 메모리 양이 필요합니다.
증분 수집기
증분 수집기는 스택을 여러 도메인으로 나누고 한 번에 하나의 도메인에서만 가비지를 수집하는 것으로 이해될 수도 있습니다. 블록은 한 번에 가비지 수집됩니다. 이로 인해 작은 애플리케이션 중단이 발생하여 사용자는 일반적으로 가비지 수집기가 작동하고 있다는 사실을 인식하지 못합니다.
부분 재활용 원칙
일반적으로 새로 할당된 객체의 80%~90%가 수백만 개의 명령어 내에 있거나 재할당됩니다.
세대 쓰레기 냉각
복사수거와 부분 재활용 원칙을 기반으로 합니다.
대부분 개체의 "영원한" 특성을 활용하는 효과적인 방법입니다.
힙을 일련의 작은 영역으로 나누고 0, 1, 2...n으로 번호를 매깁니다. 숫자가 작을수록 해당 영역에 저장된 객체가 더 젊습니다. 0 영역을 생성하고 채운 후 가비지를 수집하고 도달 가능한 객체를 영역 1로 이동합니다. 일련 번호가 i보다 작거나 같은 영역에 대해 각 가비지 수집이 수행됩니다. 여기서 i는 가장 높은 숫자입니다. 현재 채워진 영역의
i가 재활용되는 한 일련번호 i가 있는 모든 지역도 쓰레기 수거 대상이 됩니다. 이는 젊은 세대가 더 많은 쓰레기를 포함하는 경향이 있기 때문에 더 자주 재활용된다는 의미입니다.
가장 오래된 세대는 가장 성숙한 물건을 보존하며, 이러한 물건을 재활용하는 것은 완전한 재활용과 맞먹는 가장 비용이 많이 듭니다. 일시중지가 길어질 수 있습니다. 해결책은 열차 알고리즘을 사용하는 것입니다.
HotSpot의 4개 GC 컬렉터:
직렬 컬렉터:
특징: 재활용 중에 애플리케이션이 일시 중지됩니다.
젊은 영역: Eden과 Survivor 영역을 결합합니다. 생존 개체는 다른 Survivor 영역으로 복사됩니다. (TO로 설정) (큰 객체는 이전 영역에 직접 배치됩니다.) TO 영역이 가득 차면
이전 영역으로 직접 복사됩니다. 즉, mark-sweep-compact GC 알고리즘을 사용합니다. , 먼저 살아남은 개체를 표시한 다음 버려진 개체를 지운 다음 살아남은 개체를 영역으로 이동하여 더 큰 여유 공간을 확보합니다.
응용 범위: 대부분의 클라이언트 응용 프로그램은 이러한 종류의 재활용 알고리즘을 사용할 수 있습니다. HotSpot의 기본 재활용 알고리즘이기도 합니다. 현재 머신(2006)에서는 64MB 영역을 완전히 재활용하는 데 0.5초도 채 걸리지 않습니다.
병렬 재활용 병렬 수집기:
기능: 다중 -core CPU를 사용할 수 있습니다.
Young 영역: 여전히 애플리케이션을 일시 중지해야 합니다. 기본 메커니즘은 직렬화와 유사하지만 이로 인해 효율성이 향상될 수 있습니다. 선형화.
멀티 코어 컴퓨터에서 사용할 수 있습니다.
병렬 압축 수집기:
병렬 재활용과 비교하면 주로 기존 영역에 새로운 알고리즘이 적용되는 동시에 백서에 따르면 이러한 종류의 재활용은 결국 병렬 재활용을 대체하게 됩니다.
young Area : 병렬 재활용과 동일
old 영역 : 먼저 old를 여러 개의 연속된 영역으로 나눈 다음 각 영역을 평행하게 확인하고 살아있는 개체를 표시합니다(먼저 직접 참조할 수 있는 개체를 표시한 다음 모두). 그런 다음 밀도를 얻기 위해 이러한 영역을 확인하기 시작합니다(왼쪽 영역은 오른쪽 영역보다 확실히 밀도가 높음). 밀도가 높지 않은 영역부터 시작하여 오른쪽 영역을 평행하게 압축합니다. 애플리케이션: 멀티 코어 및 일시 중지 시간 요구 사항이 있는 환경의 경우 병렬 재활용보다 병렬 압축 및 재활용을 사용하는 것이 좋습니다. 그러나 공유율이 높은 서버(즉, 하나의 서버가 여러 애플리케이션을 실행하는 경우)의 경우 이전 버전으로 인해 영역 수집이 느리고 다중 스레드이므로 한 애플리케이션의 GC가 다른 애플리케이션에 영향을 미칩니다. 해당 솔루션: 병렬 스레드 수를 줄이도록 구성할 수 있습니다.
동시 마크 스윕 수집기:
young 영역: 병렬 재활용과 동일.
old 영역: 여러 단계로 나뉜다.
Initialmark: GC를 실행해야 할 때 먼저 애플리케이션을 일시 중지한 후 직접 참조되는 모든 객체를 표시합니다.
Concurrentmark: 그런 다음 애플리케이션을 계속 진행하면서 표시된 개체를 동시에 확인하여 남아 있는 모든 개체를 가져옵니다.
설명: 애플리케이션을 다시 일시 중지하고 동시 표시(new, Abandoned) 기간 동안 애플리케이션에서 수정한 개체를 확인하고 표시합니다. 이 단계는 오랜 시간 동안 지속되므로, 단계가 끝난 후에는 살아남은 모든 개체가 표시되고, 표시되지 않은 개체는 가비지 개체입니다.
청소: 애플리케이션을 일시 중지한 다음. 모든 가비지 객체의 공간을 해제합니다.
첫 번째: 압축이 수행되지 않습니다. 그러나 향후 가능한 메모리 요구 사항을 계산하여 계산됩니다. 특정 메모리 블록을 분할합니다.
둘째: 이전 영역이 가득 찰 때까지 GC가 실행되지 않고 공간이 일정 수준 미만이 되면 GC가 시작됩니다.
셋째: 압축이 수행되지 않으므로 조각화가 발생합니다. 🎜>
또한 CMS에서는 Concurrentmark 단계에서 작업의 일부만 수행한 다음 리소스를 애플리케이션에 반환하는 증분 작업을 사용할 수도 있습니다. 두 영에서 지역 재활용의 유휴 단계가 완료됩니다. 이 모드는 일반적으로 일시 중지 시간이 필요하고 프로세서 수가 많지 않은 경우(단일 코어 또는 듀얼 코어)
일반적으로 병렬 재활용과 비교됩니다. , CMS가 감소합니다. Old GC의 일시 중지 시간이 줄어들고(때때로 그 효과가 매우 중요함) Young GC의 시간이 약간 늘어납니다(객체가 Young 영역에서 Old 영역으로 이동하는 시간이 길어지기 때문에 압축이 없습니다. 수행하므로 적합한 영역을 먼저 찾아야 함)을 줄여 전체 시스템의 실행 효율성을 어느 정도 향상시키고 메모리 공간에 대한 수요를 크게 향상시킵니다.
위 내용은 Java의 여러 가비지 수집 원칙에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!