G1 Garbage Collector 시작하기
개요
JAVA 7 업데이트 9 이상 JDK가 필요함
자바 기술과 JVM
자바 가상 머신
JVM (Java Virtual Machine)은 추상 컴퓨팅 시스템입니다. JVM은 실행되도록 작성된 프로그램에 대한 기계처럼 보이는 프로그램입니다.
이런 식으로 Java 프로그램은 동일한 인터페이스 및 라이브러리 세트에 작성됩니다.
특정 운영 체제에 대한 각 JVM 구현은 Java 프로그래밍 명령을 로컬 운영 체제에서 실행되는 명령 및 명령으로 변환합니다.
이런 방식으로 Java 프로그램은 플랫폼 독립성을 달성합니다.
Sun Microsystems, Inc.에서 수행 된 Java 가상 머신의 첫 번째 프로토 타입 구현은 최신 PDA (Personal Digital Assistant)와
유사한 휴대용 장치가 호스팅하는 소프트웨어에서 Java 가상 머신 명령어 세트를 에뮬레이트했습니다.
Oracle의 현재 구현은 모바일, 데스크탑 및 서버 장치에서 Java 가상 머신을 에뮬레이트하지만
Java 가상 머신은 특정 구현 기술, 호스트 하드웨어 또는 호스트 운영 체제를 가정하지 않습니다.
기본적으로 해석되지는 않지만 명령 세트를 실리콘 CPU의 명령어 세트로 컴파일하여 구현할 수도 있습니다.
마이크로 코드 또는 실리콘으로 직접 구현할 수도 있습니다.
Java 가상 머신은 Java 프로그래밍 언어, 클래스 파일 형식의 특정 이진 형식 만 알지 못합니다.
클래스 파일에는 Java 보조 시스템 명령어 (또는 바이트 코드)와 기호 테이블 및 기타 보조 정보가 포함됩니다.
보안을 위해 Java 가상 머신은 클래스 파일의 코드에 강력한 구문 및 구조적 제약 조건을 적용합니다.
그러나 유효한 클래스 파일로 표현할 수있는 기능이있는 언어는 Java 가상 머신에서 호스팅 할 수 있습니다.
일반적으로 사용 가능한 기계 독립적 인 플랫폼에 매료되어 다른 언어 구현자는 해당 언어의 전달 수단으로 Java 가상 머신을 사용할 수 있습니다.
JVM 아키텍처 살펴보기
핫스팟 아키텍처
HotSpot JVM에는 강력한 기능 및 기반 기반을 지원하고 고성능 및 대규모 확장 성을 실현할 수있는 기능을 지원하는 아키텍처가 있습니다.
예를 들어, HotSpot JVM JIT 컴파일러는 동적 최적화를 생성합니다.
즉, Java 응용 프로그램이 실행되는 동안 최적화 결정을 내리고 기본 시스템 아키텍처를 대상으로하는 고성능 네이티브 컴퓨터 명령어를 생성합니다.
또한 HotSpot JVM은 런타임 환경과 멀티 스레드 가비지 콜렉터의 발전된 진화와 지속적인 엔지니어링을 통해
사용 가능한 가장 큰 컴퓨터 시스템에서도 높은 확장 성을 제공합니다.
JVM의 주요 구성 요소에는 클래스 로더, 런타임 데이터 영역 및 실행 엔진이 포함됩니다.
주요 핫스팟 구성 요소
성능 조정시 초점을 맞추는 JVM의 세 가지 구성 요소가 있습니다.
힙 개체 데이터가 저장되는 곳입니다. 이 영역은 시작시 선택된 가비지 수집기에서 관리합니다.
대부분의 튜닝 옵션은 힙 크기를 조정하고 상황에 가장 적합한 가비지 수집기를 선택하는 것과 관련이 있습니다.
JIT 컴파일러는 또한 성능에 큰 영향을 주지만 최신 버전의 JVM으로 조정할 필요는 거의 없습니다.
성능 기초
일반적으로 Java 응용 프로그램을 조정할 때 응답성 또는 처리량이라는 두 가지 주요 목표 중 하나에 중점을 둡니다.
튜토리얼이 진행됨에 따라 이러한 개념을 다시 참조 할 것입니다.
응답성 (Responsiveness)
응답 성은 애플리케이션 또는 시스템이 요청 된 데이터에 얼마나 빨리 응답 하는지를 나타냅니다. 예를 들면 다음과 같습니다.
- 데스크탑 UI가 이벤트에 응답하는 속도
- 웹 사이트가 페이지를 얼마나 빨리 반환하는지
- 데이터베이스 쿼리가 얼마나 빨리 반환되는지
응답성에 중점을 둔 응용 프로그램의 경우 일시 중지 시간이 크지 않습니다. 짧은 시간 안에 응답하는 데 중점을 둡니다.
처리량 (Throughput)
처리량은 특정 기간 동안 응용 프로그램의 작업량을 최대화하는 데 중점을 둡니다. 처리량 측정 방법의 예는 다음과 같습니다.
- 주어진 시간에 완료된 거래 수입니다.
- 배치 프로그램이 1 시간 안에 완료 할 수있는 작업 수입니다.
- 한 시간 안에 완료 할 수있는 데이터베이스 쿼리 수입니다.
처리량에 중점을 둔 응용 프로그램에는 높은 일시 중지 시간이 허용됩니다.
처리량이 많은 애플리케이션은 오랜 기간 동안 벤치 마크에 초점을 맞추기 때문에 빠른 응답 시간을 고려하지 않습니다.
G1 가비지 콜렉터
G1 (Grbage-First) 수집기는 메모리가 큰 다중 프로세서 시스템을 대상으로하는 서버 스타일의 가비지 수집기입니다.
높은 처리량을 달성하면서 높은 확률로 가비지 콜렉션 (GC) 일시 정지 시간 목표를 충족시킵니다.
G1 가비지 수집기는 Oracle JDK 7 업데이트 4 이상 릴리스에서 완벽하게 지원됩니다.
G1 콜렉터는 다음과 같은 애플리케이션을 위해 설계되었습니다.
- CMS 수집기와 같은 응용 프로그램 스레드와 동시에 작동 할 수 있습니다.
- 긴 GC로 인한 일시 중지 시간이없는 컴팩트 한 여유 공간.
- 더 예측 가능한 GC 일시 중지 기간이 필요합니다.
- 많은 처리량 성능을 희생하고 싶지 않습니다.
- 훨씬 더 큰 Java 힙이 필요하지 않습니다.
G1은 CMS (Concurrent Mark-Sweep Collector)의 장기 교체 계획입니다.
G1과 CMS를 비교하면 G1을 더 나은 솔루션으로 만드는 차이점이 있습니다.
한 가지 차이점은 G1이 압축 수집기라는 것입니다. G
1은 할당을 위해 세분화 된 자유 목록을 사용하는 것을 완전히 피할 수 있도록 충분히 압축하고 대신 지역에 의존합니다.
이는 수집기의 일부를 상당히 단순화하고 잠재적 인 조각화 문제를 대부분 제거합니다.
또한 G1은 CMS 수집기보다 예측 가능한 가비지 수집 일시 중지를 제공하며 사용자가 원하는 일시 중지 대상을 지정할 수 있습니다.
G1 운영 개요
오래된 가비지 수집기 (직렬, 병렬, CMS)는 힙을 고정 메모리 크기의 young(젊은) generation, old(오래된) generation, and permanent(영구적인) generation의 세 섹션으로 구성합니다.
모든 메모리 객체는이 세 섹션 중 하나로 끝납니다.
G1 수집기는 다른 접근 방식을 취합니다.
힙은 각각 연속 된 범위의 가상 메모리 범위 인 동일한 크기의 힙 영역 세트로 분할됩니다.
특정 지역 집합에는 이전 수집가와 동일한 역할 (에덴, 생존자, 이전)이 할당되지만 고정 된 크기는 없습니다.
이것은 메모리 사용에있어 더 큰 유연성을 제공합니다.
가비지 수집을 수행 할 때 G1은 CMS 수집기와 유사한 방식으로 작동합니다.
G1은 동시 전역 마킹 단계를 수행하여 힙 전체에서 개체의 라이브 니스를 결정합니다.
마크 단계가 완료되면 G1은 어느 영역이 대부분 비어 있는지 알고 있습니다.
이 영역에서 먼저 수집하여 일반적으로 많은 여유 공간을 생성합니다.
이러한 가비지 수집 방법을 가비지 우선이라고합니다.
이름에서 알 수 있듯이 G1은 회수 가능한 개체, 즉 쓰레기로 가득 찬 힙 영역에 수집 및 압축 활동을 집중시킵니다.
G1은 일시 정지 예측 모델을 사용하여 사용자 정의 일시 정지 시간 목표를 충족시키고 지정된 일시 정지 시간 목표를 기반으로 수집 할 영역 수를 선택합니다.
교정을 위해 익은 것으로 G1에 의해 식별 된 영역은 배출을 사용하여 가비지 수집됩니다.
G1은 힙의 하나 이상의 영역에서 힙의 단일 영역으로 객체를 복사하고 프로세스에서 메모리를 압축하고 해제합니다.
이러한 대피는 다중 프로세서에서 병렬로 수행되어 일시 중지 시간을 줄이고 처리량을 증가시킵니다.
따라서 G1은 각 가비지 콜렉션에서 지속적으로 작동하여 단편화를 줄이고 사용자 정의 된 일시 정지 시간 내에서 작업합니다.
이것은 이전의 두 가지 방법으로는 불가능합니다.
CMS (Concurrent Mark Sweep) 가비지 수집기는 압축을 수행하지 않습니다.
Parallel Old 가비지 수집은 전체 힙 압축 만 수행하므로 상당한 일시 중지 시간이 발생합니다.
G1은 실시간 수집기가 아니라는 점에 유의해야합니다.
높은 확률로 설정된 일시 정지 시간 목표를 충족하지만 절대 확실성은 아닙니다.
이전 컬렉션의 데이터를 기반으로 G1은 사용자가 지정한 대상 시간 내에 수집 할 수있는 지역 수를 추정합니다.
따라서 수집기는 영역을 수집하는 비용에 대해 합리적으로 정확한 모델을 가지고 있으며이 모델을 사용하여
일시 정지 시간 목표 내에 머무르는 동안 수집 할 영역과 수를 결정합니다.
참고 : G1에는 동시 (애플리케이션 스레드와 함께 실행 (예 : 정제, 표시, 정리)) 및 병렬 (멀티 스레드, 예를 들어 세계 정지) 단계가 있습니다.
전체 가비지 콜렉션은 여전히 단일 스레드이지만, 올바르게 조정되면 애플리케이션이 전체 GC를 피해야합니다.
G1 Footprint
ParallelOldGC 또는 CMS 수집기에서 G1으로 마이그레이션하면 JVM 프로세스 크기가 더 커질 수 있습니다.
이것은 Remembered Set 및 Collection Sets 과 같은 “accounting” 데이터 구조와 관련이 있습니다.
Remembered Set : Remembered Set(RSets)는 객체 참조를 주어진 영역으로 추적합니다.
힙에는 영역 당 하나의 RSet이 있습니다. RSet을 사용하면 영역의 병렬 및 독립 수집이 가능합니다.
RSets의 전체 풋 프린트 영향은 5 % 미만입니다.
Collection Sets : Collection Sets(CSets) CSet의 모든 라이브 데이터는 GC 중에 비워집니다 (복사 / 이동).
지역 집합은 Eden, 생존자 및 / 또는 오래된 세대 일 수 있습니다. CSets는 JVM 크기에 1 % 미만의 영향을 미칩니다.
G1의 권장 사용 사례
G1의 첫 번째 초점은 제한된 GC 대기 시간으로 큰 힙이 필요한 응용 프로그램을 실행하는 사용자에게 솔루션을 제공하는 것입니다.
이는 약 6GB 이상의 힙 크기와 0.5 초 미만의 안정적이고 예측 가능한 일시 중지 시간을 의미합니다.
CMS 또는 ParallelOldGC 가비지 수집기를 사용하여 현재 실행중인 응용 프로그램은 응용 프로그램에 다음 특성이 하나 이상있는 경우 G1로 전환하는 것이 좋습니다.
- 전체 GC 기간이 너무 길거나 너무 잦습니다.
- 오브젝트 할당 비율 또는 승격 비율은 크게 다릅니다.
- 원치 않는 긴 가비지 콜렉션 또는 압축 일시 정지 (0.5-1 초 이상)
참고 : CMS 또는 ParallelOldGC를 사용하고 있고 응용 프로그램에 가비지 수집 일시 중지가 오래 걸리지 않으면 현재 수집기를 유지하는 것이 좋습니다.
최신 JDK를 사용하기 위해 G1 콜렉터로 변경하지 않아도됩니다.
CMS GC 검토
CMS (Concurrent Mark Sweep) 수집기 (동시 낮은 일시 중지 수집기라고도 함)는 tenured 생성을 수집합니다.
가비지 수집 작업의 대부분을 응용 프로그램 스레드와 동시에 수행하여 가비지 수집으로 인한 일시 중지를 최소화하려고 합니다.
일반적으로 동시 일시 정지 콜렉터는 라이브 오브젝트를 복사하거나 압축하지 않습니다.
라이브 오브젝트를 이동하지 않고 가비지 콜렉션이 수행됩니다. 조각화가 문제가되면 더 큰 힙을 할당하십시오.
참고 : 젊은 세대의 CMS 수집기는 병렬 수집기와 동일한 알고리즘을 사용합니다.
CMS 수집 단계
CMS 수집기는 이전 세대 힙에서 다음 단계를 수행합니다.
Initial Mark (Stop the World Event)
구세대의 객체는 어린 세대로부터 도달 할 수있는 객체를 포함하여 도달 가능한 것으로 “marked” 됩니다.
일시 중지 시간은 일반적으로 소량의 수집 일시 중지 시간에 비해 지속 시간이 짧습니다.
Concurrent Marking
Java 애플리케이션 스레드가 실행되는 동안 도달 가능한 오브젝트에 대한 tenured generation 오브젝트 그래프를 동시에 탐색하십시오.
표시된 개체에서 스캔을 시작하고 뿌리에서 도달 가능한 모든 개체를 전 이적으로 표시합니다.
뮤 테이터는 동시 단계 2, 3 및 5 중에 실행되며 이러한 단계 중에 CMS 생성에 할당 된 모든 개체 (승격 된 개체 포함)는 즉시 라이브로 표시됩니다.
Remark (Stop the World Event)
동시 콜렉터가 해당 오브젝트 추적을 완료 한 후 Java 애플리케이션 스레드가 오브젝트로 업데이트하여
동시 마크 단계에서 누락 된 오브젝트를 찾습니다.
Concurrent Sweep
마킹 단계에서 도달 할 수없는 것으로 식별 된 객체를 수집합니다.
사용 불능 개체를 수집하면 나중에 할당 할 수 있도록 개체 공간이 사용 가능 목록에 추가됩니다.
이 시점에서 죽은 개체의 병합이 발생할 수 있습니다. 라이브 오브젝트는 이동되지 않습니다.
Resetting
데이터 구조를 삭제하여 다음 동시 수집을 준비하십시오.
가비지 콜렉션 단계 검토
다음으로 CMS 수집기 작업을 단계별로 검토하겠습니다.
- CMS 수집기의 힙 구조
힙은 3 개의 공간으로 분할됩니다.
젊은 세대는 에덴과 2 개의 생존자 공간으로 나뉩니다.
구세대는 하나의 인접한 공간입니다. 개체 수집이 완료되었습니다.
전체 GC가 없으면 압축이 수행되지 않습니다.
- CMS에서 Young GC 작동 방식
젊은 세대는 밝은 초록색이며, 이전 세대는 파란색입니다.
응용 프로그램이 얼마 동안 실행 된 경우 CMS의 모습입니다.
구세대 주변에 물체가 흩어져 있습니다.
CMS를 사용하면 이전 세대 개체가 할당 해제됩니다.
그들은 움직이지 않습니다.
전체 GC가 없으면 공간이 압축되지 않습니다.
- 젊은 세대 컬렉션
라이브 객체는 Eden 공간과 생존자 공간에서 다른 생존자 공간으로 복사됩니다.
노화 임계 값에 도달 한 모든 오래된 개체는 이전 세대로 승격됩니다.
- 젊은 GC 후
어린 GC 후, 에덴 공간이 비워지고 생존자 공간 중 하나가 비워집니다.
새로 승격 된 오브젝트는 다이어그램에서 진한 파란색으로 표시됩니다. 녹색 물체는 아직 구세대로 승격되지 않은 젊은 세대 물체에서 살아 남았습니다.
- CMS로 구세대 컬렉션
세계 이벤트가 시작되는 두 가지 중지 : 초기 표시 및 설명. 이전 세대가 특정 점유율에 도달하면 CMS가 시작됩니다.
(1) 초기 표시는 작동 가능한 도달 가능한 개체가 표시되는 짧은 일시 중지 단계입니다.
(2) 동시 마킹은 응용 프로그램이 계속 실행되는 동안 라이브 객체를 찾습니다. 마지막으로,
(3) 비고 단계에서, 이전 단계에서
(2) 동시 마킹 중에 누락 된 객체가 발견됩니다.
- 구세대 컬렉션-동시 스윕
이전 단계에서 표시되지 않은 개체가 할당 해제됩니다. 압축은 없습니다.
참고 : 표시되지 않은 개체 == 죽은 개체
- 구세대 컬렉션-청소 후
(4) Sweeping 단계 후에 많은 메모리가 확보되었음을 알 수 있습니다. 또한 압축이 수행되지 않았 음을 알 수 있습니다.
마지막으로 CMS 수집기는 (5) 재설정 단계를 거쳐 다음에 GC 임계 값에 도달 할 때까지 기다립니다.
G1 가비지 콜렉터 단계별
G1 콜렉터는 힙 할당에 다른 접근법을 사용합니다. 다음 그림은 G1 시스템을 단계별로 검토합니다.
- G1 힙 구조
힙은 많은 고정 크기 영역으로 분할 된 하나의 메모리 영역입니다.
리젼 크기는 시작시 JVM에 의해 선택됩니다. JVM은 일반적으로 1-32Mb의 크기가 다양한 약 2000 개의 지역을 대상으로 합니다.
- G1 힙 할당
실제로이 지역들은 Eden, Survivor 및 구세대 공간의 논리적 표현으로 매핑됩니다.
그림의 색상은 어떤 지역이 어떤 역할과 관련되어 있는지 보여줍니다.
라이브 객체는 한 지역에서 다른 지역으로 대피됩니다 (즉, 복사 또는 이동).
영역은 다른 모든 응용 프로그램 스레드를 중지하거나 중지하지 않고 병렬로 수집되도록 설계되었습니다.
도시 된 바와 같이 에덴, 생존자 및 구세대 영역에 영역을 할당 할 수있다.
또한 Humongous 지역으로 알려진 네 번째 유형의 물체가 있습니다.
이 영역은 표준 영역 크기의 50 % 이상인 객체를 수용하도록 설계되었습니다.
연속 된 영역 세트로 저장됩니다. 마지막으로 영역의 마지막 유형은 힙의 사용되지 않은 영역입니다.
참고 : 이 글을 쓰는 시점에, 거대한 객체 수집은 최적화되지 않았습니다. 따라서 이 크기의 객체를 만들지 않아야합니다.
- G1의 젊은 세대
힙은 약 2000 개의 영역으로 분할됩니다. 최소 크기는 1Mb이고 최대 크기는 32Mb입니다.
파란색 영역에는 이전 세대 개체가 있고 녹색 영역에는 젊은 세대 개체가 있습니다.
이전 가비지 수집기와 같이 영역이 연속 되어있을 필요는 없습니다.
- G1의 젊은 GC
라이브 객체는 하나 이상의 생존자 지역으로 대피 (즉, 복사 또는 이동)됩니다.
에이징 임계 값이 충족되면 일부 오브젝트가 이전 세대 영역으로 승격됩니다.
이것은 세계 정지 (STW) 일시 정지입니다.
다음 젊은 GC에 대한 에덴 크기와 생존자 크기가 계산됩니다.
회계 정보는 크기를 계산하는 데 도움이되도록 유지됩니다.
일시 정지 시간 목표와 같은 것들이 고려됩니다.
이 방법을 사용하면 영역 크기를 매우 쉽게 조정할 수 있으므로 필요에 따라 영역을 더 크게 또는 작게 만들 수 있습니다.
- G1과 함께하는 젊은 GC의 끝
살아있는 물체는 생존자 지역이나 구세대 지역으로 대피했습니다.
최근에 승격 된 객체는 진한 파란색으로 표시됩니다. 녹색의 생존자 지역.
요약하면 G1의 젊은 세대에 대해 다음과 같이 말할 수 있습니다.
- 힙은 단일 메모리 공간을 영역으로 분할 한 것입니다.
- 젊은 세대 메모리는 일련의 비 연속 영역으로 구성됩니다. 필요한 경우 크기를 쉽게 조정할 수 있습니다.
- 젊은 세대 가비지 콜렉션 또는 젊은 GC는 세계 이벤트를 중지시킵니다. 작업을 위해 모든 응용 프로그램 스레드가 중지되었습니다.
- 젊은 GC는 여러 스레드를 사용하여 병렬로 수행됩니다.
- 라이브 객체는 새로운 생존자 또는 이전 세대 지역으로 복사됩니다.
G1으로 구세대 컬렉션
CMS 수집기와 마찬가지로 G1 수집기는 이전 세대 개체의 일시 중지 수집기가되도록 설계되었습니다.
다음 표는 이전 세대의 G1 수집 단계를 설명합니다.
G1 수집 단계-동시 마킹주기 단계
Initial Mark (Stop the World Event)
이것은 세계 이벤트 중지입니다.
G1을 사용하면 정상적인 젊은 GC에서 piggybacked(철도와 트럭을 결합한 수송 수단) 됩니다.
구세대의 객체에 대한 참조를 가질 수있는 생존자 영역 (루트 영역)을 표시합니다.
Root Region Scanning
구세대에 대한 참조를 위해 생존자 지역을 스캔하십시오.
응용 프로그램이 계속 실행되는 동안 발생합니다.
어린 GC가 발생하기 전에 단계를 완료해야합니다.
Concurrent Marking
전체 힙에서 라이브 오브젝트를 찾으십시오.
응용 프로그램이 실행되는 동안 발생합니다.
이 단계는 젊은 세대 가비지 콜렉션에 의해 중단 될 수 있습니다.
Remark (Stop the World Event)
힙에서 라이브 오브젝트 표시를 완료합니다.
CMS 콜렉터에서 사용 된 것보다 훨씬 빠른 SATB (Snap-at-the-Beginning)라는 알고리즘을 사용합니다.
Cleanup (Stop the World Event and Concurrent)
- 라이브 오브젝트 및 완전 빈 영역에 대한 회계를 수행합니다. (세계를 멈춰라)
- 기억 된 세트를 제거합니다. (세계를 멈춰라)
- 빈 영역을 재설정하고 빈 목록으로 되돌립니다. (Concurrent)
Copying (Stop the World Event)
이것들은 살아있는 물체를 새로운 미사용 지역으로 대피 시키거나 복사하기 위해 세계가 멈추는 정지입니다.
이는 [GC pause (young)]로 기록 된 젊은 세대 지역에서 수행 할 수 있습니다 .
또는 [GC Pause (mixed)]로 기록 된 젊은이와 노인 세대 지역.