배경 :
저는 항상 Java 가상 머신에 대한 정보를 공유하고 싶었습니다. 오랫동안 작업 해 왔습니다. 너무 이론적이어서 특별한 것을 너무 많이 쓸 수 없습니다. 몇몇 친구들이이 가상 머신을 아주 잘 공유하고 시스템으로 구성되어있는 것을 볼 수 있습니다. , 친구들에게 도움이 되었으면 좋겠어요. 파라오의 공식 계정 [Software Pharaoh]에 관심을 가져 주시고 길을 잃지 않도록주의하세요.
가비지 수집 알고리즘은 여러 각도에서 나눌 수 있습니다.
기본 재활용 전략에 따라
참조 계산 :
오래된 재활용 알고리즘. 원칙적으로이 객체에는 참조가 있습니다. 즉, 개수가 증가하고 참조가 삭제되어 개수가 감소합니다. 가비지 수집 중에는 개수가 0 인 개체 만 수집됩니다. 이 알고리즘에서 가장 치명적인 것은 순환 참조를 처리 할 수 없다는 것입니다.
마크 스윕 :
이 알고리즘은 두 단계로 실행됩니다. 첫 번째 단계는 참조 루트 노드에서 시작하여 모든 참조 된 개체를 표시하고 두 번째 단계는 전체 힙을 순회하고 표시되지 않은 개체를 지 웁니다. 이 알고리즘은 전체 응용 프로그램을 일시 중단해야하는 동시에 메모리 조각화를 생성합니다.
사자:
이 알고리즘은 메모리 공간을 두 개의 동일한 영역으로 나누고 한 번에 하나만 사용합니다. 가비지 수집 중에 현재 사용중인 영역을 탐색하고 사용중인 개체를 다른 영역으로 복사합니다. 이 알고리즘은 매번 사용중인 객체 만 처리하므로 복사 비용이 상대적으로 적고 동시에 복사 후 해당 메모리를 정렬 할 수 있으며 "조각화"문제가 없습니다. 물론이 알고리즘의 단점도 분명합니다. 즉, 두 배의 메모리 공간이 필요하다는 것입니다.
Mark-Compact :
이 알고리즘은 "mark-clear"와 "copy"라는 두 가지 알고리즘의 장점을 결합합니다. 또한 두 단계로 나뉩니다. 첫 번째 단계는 루트 노드에서 시작하여 모든 참조 된 개체를 표시합니다. 두 번째 단계는 전체 힙을 탐색하고 표시되지 않은 개체를 지우고 라이브 개체를 힙 중 하나로 "압축"한 다음 순서대로 배출합니다. 이 알고리즘은 "마크 앤 클리어"조각화 문제를 방지하고 "복사"알고리즘의 공간 문제도 방지합니다.
치료 구분에 따라
증분 수집 : 실시간 가비지 수집 알고리즘, 즉 응용 프로그램이 진행되는 동안 가비지 수집이 수행됩니다. JDK5.0의 수집기가이 알고리즘을 사용하지 않은 이유를 모르겠습니다.
세대 별 수집 (Generational Collecting) : 개체 수명주기 분석에서 파생 된 가비지 수집 알고리즘을 기반으로합니다. 개체는 젊은 세대, 구세대, 영구 세대로 나뉘며 서로 다른 알고리즘 (위의 방법 중 하나)을 사용하여 서로 다른 수명주기의 개체를 재활용합니다. 현재 가비지 수집기 (J2SE1.2부터)는 모두이 알고리즘을 사용합니다.
시스템 스레드 별
직렬 수집 : 직렬 수집은 단일 스레드를 사용하여 모든 가비지 수집 작업을 처리합니다. 다중 스레드 상호 작용이 필요없고 구현하기 쉽고 효율성이 상대적으로 높기 때문입니다. 그러나 그 한계도 분명합니다. 즉, 다중 프로세서의 장점을 사용할 수 없기 때문에이 컬렉션은 단일 프로세서 시스템에 적합합니다. 물론이 수집기는 데이터 볼륨이 적은 (약 100M) 멀티 프로세서 시스템에서도 사용할 수 있습니다.
병렬 수집 : 병렬 수집은 여러 스레드를 사용하여 가비지 수집을 처리하므로 빠르고 효율적입니다. 이론적으로 CPU가 많을수록 병렬 수집기의 장점을 더 잘 실현할 수 있습니다.
동시 수집 : 직렬 수집 및 병렬 수집과 비교하여 처음 두 사람은 가비지 수집 중에 전체 운영 환경을 중단해야하며 가비지 수집 프로그램 만 실행되므로 가비지 수집 중에 시스템이 명백하게 일시 중지됩니다. , 그리고 힙이 클수록 일시 중지 시간이 길어집니다.
더 많은 지식을 얻으려면 공식 계정 "Software King" 에 주목하십시오. 길을 잃지 않도록주의하십시오. Software King과 그의 IT 친구는 기술적 통찰력과 삶의 이야기를 공유하십시오.
