가비지 컬렉터에 대한 추가 정보

안녕! 지난 수업에서 우리는 먼저 Java의 내장형 가비지 컬렉터에 대해 알게 되었고 이것이 어떻게 작동하는지에 대한 대략적인 아이디어를 얻었습니다. 프로그램이 실행되는 동안 백그라운드에서 작동하여 나중에 삭제될 불필요한 개체를 수집합니다. 따라서 향후 새 개체를 만드는 데 사용할 수 있는 메모리를 확보합니다. 이 단원에서는 작동 방식에 대해 자세히 설명합니다. 예를 들어, 객체가 언제 어떻게 불필요해집니까? 그리고 가비지 컬렉터는 어떻게 알아낼까요? 이것들은 오늘 수업에서 우리가 대답할 질문들입니다 :) 이 수업은 개요에 가깝습니다. 이 자료를 암기할 필요는 없습니다. 주로 메모리와 가비지 컬렉터가 작동하는 방식에 대한 시야를 넓히기 위한 것이므로 내용을 읽고 스스로 새로운 것을 찾으십시오 :) 시작하겠습니다! 기억해야 할 첫 번째 사항은 가비지 수집기가 프로그램과 병렬로 작동한다는 것입니다.. 프로그램의 일부가 아닙니다. 그것은 별도로 작동합니다 (지난 수업에서 이것을 로봇 진공 청소기에 비교했습니다). 그러나 항상 그런 것은 아닙니다. 프로그램과 동일한 스레드에서 수행되는 가비지 수집. 일정에 따라(몇 분에 한 번) 가비지 수집기는 프로그램에 원치 않는 개체가 있는지 확인합니다. 문제는 이 검사 및 가비지 수집 중에 프로그램이 정지(실행되지 않음)한다는 것입니다. 직장에서 사무실에 앉아 있다고 상상해보십시오. 그런데 청소부 아줌마가 바닥을 닦으러 들어옵니다. 그녀는 5분 동안 컴퓨터에서 당신을 쫓아내고 당신은 그녀가 청소를 마칠 때까지 기다립니다. 이 시간 동안에는 일을 할 수 없습니다. 이것이 가비지 수집이 작동하는 방법에 관한 것입니다 :) 이 메커니즘은 나중에 변경되었으며 이제 가비지 수집기가 백그라운드에서 실행됩니다. 프로그램 자체의 작업을 방해하지 않습니다. 더 이상 참조가 없으면 개체가 죽는다는 것을 이미 알고 있습니다. 실제로,가비지 수집기는 개체 참조를 계산하지 않습니다 . 첫째, 시간이 오래 걸릴 수 있습니다. 둘째, 그다지 효과적이지 않습니다. 결국 객체는 서로를 참조할 수 있습니다! 그림은 3개의 객체가 서로를 참조하지만 아무도 참조하지 않는 예를 보여줍니다. 즉, 나머지 프로그램에는 필요하지 않습니다. 가비지 컬렉터가 단순히 참조 수를 세는 경우 이 3개 개체는 수집되지 않고 메모리가 해제되지 않습니다(참조가 있습니다!). 우리는 이것을 우주선에 비교할 수 있습니다. 비행 중에 우주 비행사는 수리할 수 있는 예비 부품 목록을 확인하기로 결정합니다. 무엇보다도 그들은 일반 자동차에서 핸들과 페달을 찾습니다. 분명히 여기에서는 필요하지 않으며 불필요하게 공간을 차지합니다(이 두 부분은 서로 관련되어 있고 일부 기능이 있지만). 하지만 우주선 안에서는 버려야 할 쓸모없는 쓰레기들이다. 이에 Java에서는 참조 카운팅이 아닌 가비지 수집을 결정했습니다.도달 가능 및 도달 불가능 . 개체에 도달할 수 있는지 어떻게 확인합니까? 그것은 모두 단순히 독창적입니다. 도달 가능한 다른 객체가 객체를 참조하는 경우 객체에 도달할 수 있습니다. 따라서 "도달 가능성 체인"을 얻습니다. 프로그램이 시작될 때 시작되고 프로그램 기간 동안 계속됩니다. 다음과 같이 보입니다. 그림의 화살표는 프로그램의 실행 가능한 코드를 나타냅니다. 코드(예: main()메서드)는 개체에 대한 참조를 만듭니다. 이러한 객체는 다른 객체를 참조할 수 있고 해당 객체는 또 다른 객체를 참조할 수 있습니다. 이것은 참조 체인을 형성합니다.. 개체에서 "루트 참조"(실행 코드에서 직접 생성된 참조)까지 체인을 따라 추적할 수 있으면 도달 가능한 것으로 간주됩니다. 이러한 개체는 그림에서 검은색으로 표시됩니다. 그러나 객체가 이 체인에서 벗어나면 객체에 도달할 수 없습니다. 즉, 현재 실행 중인 코드의 어떤 변수도 객체를 참조하지 않으며 "참조 체인"을 통해 도달할 수 없습니다. 우리 프로그램에서 두 개의 이러한 개체는 빨간색으로 표시됩니다. 이러한 "빨간색" 개체에는 서로에 대한 참조가 있습니다. 그러나 앞서 말했듯이 Java의 최신 가비지 수집기는 참조를 계산하지 않습니다. 개체에 도달할 수 있는지 또는 도달할 수 없는지 여부를 결정합니다.. 결과적으로 그림에서 두 개의 빨간색 개체를 포착합니다. 이제 전체 프로세스를 처음부터 끝까지 살펴보겠습니다. 그렇게 함으로써 Java에서 메모리가 어떻게 배열되는지도 볼 수 있습니다. :) 모든 Java 객체는 heap 이라는 메모리의 특수 영역에 저장됩니다 . 일상 언어에서 힙은 일반적으로 모든 항목이 혼합된 산더미 같은 항목입니다. 그러나 그것은 Java의 힙이 아닙니다. 그 구조는 매우 논리적이고 합리적입니다. 어느 시점에서 Java 프로그래머는 모든 개체가 단순 개체 와 "장기 개체" 의 두 가지 유형으로 나눌 수 있음을 발견했습니다.. "긴 수명 개체"는 여러 라운드의 가비지 수집에서 살아남은 개체입니다. 그들은 보통 프로그램이 끝날 때까지 산다. 결국 모든 개체가 저장되는 전체 힙은 여러 부분으로 나뉩니다. 첫 번째 부분은 아름다운 이름을 가지고 있습니다: eden(성서 "에덴 동산"에서). 이 이름은 개체가 생성된 후 끝나기 때문에 적합합니다. new 키워드를 사용할 때 새 객체가 생성되는 메모리 부분입니다. 많은 개체가 생성될 수 있습니다. 이 영역의 공간이 부족하면 초기 "빠른" 가비지 수집이 시작됩니다. 우리는 가비지 컬렉터가 매우 영리하다고 말해야 합니다. 힙에 더 많은 가비지가 있는지 또는 더 많은 라이브 개체가 있는지에 따라 알고리즘을 선택합니다. 거의 모든 개체가 가비지인 경우 수집기는 활성 개체를 표시하고 다른 메모리 영역으로 이동합니다. 그러면 현재 영역이 완전히 지워집니다. 가비지가 많지 않고 힙이 대부분 활성 개체인 경우 수집기는 가비지를 표시하고 지우고 다른 개체를 함께 묶습니다. 우리가 말했다 "생존 공간 . 생존 공간은 차례로 세대 로 나뉩니다 . 각 개체는 얼마나 많은 가비지 컬렉션에서 살아남았는지에 따라 특정 세대에 속합니다. 개체가 가비지 수집의 한 라운드에서 살아남은 경우 "1세대"에 있습니다. 5이면 "5세대"입니다. 에덴과 서바이벌 공간은 함께 젊은 세대 라는 영역을 형성한다 . Young Generation 외에도 힙에는 Old Generation 이라는 또 다른 메모리 영역이 있습니다.. 이것은 많은 가비지 컬렉션에서 살아남은 수명이 긴 개체가 끝나는 영역입니다. 그것들을 다른 모든 것과 분리하여 유지하는 이점이 있습니다. 전체 가비지 수집은 구세대가 가득 찬 경우에만 수행됩니다. 즉, 프로그램에 수명이 긴 개체가 너무 많아 메모리가 충분하지 않습니다. 이 프로세스에는 둘 이상의 메모리 영역이 포함됩니다. 일반적으로 Java 시스템에서 생성된 모든 개체가 포함됩니다. 당연히 이것은 훨씬 더 많은 시간과 자원이 필요합니다. 수명이 긴 개체를 별도로 저장하기로 한 결정입니다. 다른 영역의 공간이 부족할 때 "빠른 가비지 수집"이 수행됩니다. 이것은 하나의 영역만 포함하므로 더 빠르고 효율적입니다. 마지막으로 수명이 긴 객체의 영역까지 완전히 채워지면 전체 가비지 수집이 트리거됩니다. 따라서 수집기는 피할 수 없는 경우에만 "가장 무거운" 도구를 사용합니다. 다음은 힙 구조와 가비지 수집을 시각적으로 나타낸 것입니다.