자바 회수 정책

더 읽 기
 1.자바 의 회수 정책 은:
       이미"죽 었 다"는 대상 을 회수 하 는 것 은 더 이상 어떠한 경로 로 도 사용 할 수 없 는 대상 이다. 
 
2.대상 이 이미 죽 었 다 고 판단 하 는 방법:
      우리 가 현재 자주 사용 하 는 방법 은 계수 알고리즘 과 루트 검색 알고리즘 을 참조 하 는 것 이다.
      ① 계수 계산법 의 원리 와 단점 을 참조 합 니 다.
       원리:우 리 는 대상 에 게 인용 계수 기 를 추가 합 니 다.한 곳 에서 이 대상 을 인용 할 때마다 우리 의 계수 기 는 1 을 추가 합 니 다.인용 이 실 효 될 때 우리 의 계수 기 는 1 을 줄 입 니 다.언제든지 카운터 가 0 인 대상 은 더 이상 사용 할 수 없 으 며,우 리 는 이 대상 이 이미 죽 었 다 고 판정 합 니 다.장점 은 간단 하고 판정 효율 이 높다.
        단점:대상 간 의 상호 순환 인용 문 제 를 해결 하기 어렵다.예 를 들 어 대상 A 와 대상 B 는 모두 test 필드 가 있 고 A.test=B.test 를 받 습 니 다.B.test = A.test;그 밖 에 이 두 대상 은 더 이상 인용 이 없다.실제로 이 두 대상 은 이미 회수 해 야 할 대상 이지 만 서로 인용 하여 그들의 카운터 가 0 이 되 지 않 는 상황 에서 계수 알고리즘 을 인용 하면 이런 문 제 를 잘 해결 할 수 없다.
        ② 접근 성 분석 알고리즘:알고리즘 의 기본 적 인 사 고 는 일련의 GCroots 대상 을 통 해 뿌리 노드 로 서 이 노드 에서 아래로 검색 하고 검색 하 는 경 로 는 인용 체인 이 되 는 것 입 니 다.한 대상 이 GCR 에 도착 하 는 것 입 니 다.도서 에 인용 체인 이 없 을 때 이 대상 은 사용 할 수 없다 고 생각 합 니 다.
       ③ 접근 성 분석 알고리즘 이 도달 할 수 없 는 대상 으로 판정 되 더 라 도 죽지 않 으 면 안 되 는 것 이 아니다.이 때 는 집행유예 단계 이 므 로 적어도 두 번 의 표기 과정 을 거 쳐 야 한다.접근 성 분석 이 GCROTS 와 연 결 된 인용 체인 이 없다 고 판단 할 때 는 첫 번 째 표 시 를 하고 선별 하 며 선별 하 는 조건 은 이 대상 이 finalize()방법 을 수행 할 필요 가 있 는 지 여부 이다.대상 이 finalize()방법 이나 finalize()방법 을 덮어 쓰 지 않 았 을 때 가상 컴퓨터 는 이 두 가지 상황 을 모두'실행 할 필요 가 없다'고 판정 합 니 다.만약 에 이 finalize()방법 이 finalize()방법 을 실행 할 필요 가 있다 고 판정 되면 이 대상 은 측의 가장 큰 F-Queue 대기 열 에 있 고 나중에 가상 컴퓨터 가 자동 으로 만 든 낮은 우선 순위 의 Finalizer 현성 에서 실 행 될 것 입 니 다.
        ④ finalize()방법 은 대상 이 사망 운명 에서 벗 어 날 수 있 는 마지막 기회 이다.만약 에 대상 이 finalize()방법 에서 인용 체인 의 모든 대상 과 다시 관 계 를 맺 으 면 자구 에 성공 한다.그렇지 않 으 면 이 대상 은 기본적으로 회수 된다.
 
finalize()의 테스트 방법 은 다음 과 같다.

public class FinalizeEscapeGC {

    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive(){
        System.out.println("yes,i am alive");
    }
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }
    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC();

        //        
        SAVE_HOOK = null;
        System.gc();
        //  finalize（）       ，    1      
        Thread.sleep(1000);
        if (SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
        }else {
            System.out.println("no,i am dead");
        }


        //                ，    
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(1000);
        if (SAVE_HOOK != null){
            SAVE_HOOK.isAlive();
        }else {
            System.out.println("no,i am dead");
        }
    }
    /**
     *         ，     ，         finalize（）            ，           ，  finalize（）
     *         ，       
     */
}

 실행 결 과 는:

finalize method executed
yes,i am alive
no,i am dead

Process finished with exit code 0

 
        finalize()라 는 방법 은 이미 매우 슬 프 지만 이 방법 은 좋 은 방법 이 아니다.우 리 는 가능 한 한 그것 을 사용 하지 않도록 해 야 한다.왜냐하면 그의 운행 대가 가 높 고 불확실 성 이 커서 각 대상 의 호출 순 서 를 보장 할 수 없다.어떤 교재 에서 그 를'외부 자원 폐쇄'와 같은 일 로 묘사 하 는데 이것 은 완전히 이 방법 에 대한 자기 위안 이다.finalize()가 할 수 있 는 모든 일 은 try-finally 또는 다른 방식 으로 더 잘 하고 신속하게 할 수 있 기 때문에 우 리 는 자바 에 이런 방법 이 있다 는 것 을 잊 을 수 있다.
 
3.회수 방법 구역
     많은 사람들 이 방법 구역(또는 Hotpot 가상 기기 의 영구 세대)이 쓰레기 수집 이 없다 고 생각 하고 자바 가상 기기 규범 에서 가상 기기 가 방법 구역 에서 쓰레기 수집 을 요구 하지 않 아 도 되 고 방법 구역 에서 쓰레기 수집 을 하 는 성 가 는 보통 보다 매우 낮다 고 말 했다.
       영구 세대 의 쓰레기 수집 은 주로 두 부분 을 회수 합 니 다.폐기 상수 와 무용 류 입 니 다.
        ① 폐기 상수 회수:
         자바 더미 의 대상 을 회수 하 는 것 과 매우 유사 합 니 다.상수 탱크 의 글자 수 거 를 예 로 들 면 문자열'ABC'가 상수 탱크 에 들 어 갔 지만 현재 시스템 에 String 대상 이 하나 도 없습니다.이때 쓰레기 수 거 가 발생 하고 필요 하 다 면 이 문자열 상수 탱크,상수 탱크 의 다른 종류(인터페이스),방법,필드 의 기호 참조 도 이와 유사 합 니 다.
         ② 회수 무용 류
         ：이 종 류 는 모든 인 스 턴 스 에서 회수 되 었 습 니 다.즉,자바 더미 에 이러한 인 스 턴 스 가 존재 하지 않 습 니 다.
         ：이 클래스 를 불 러 온 ClassLoader 는 회수 되 었 습 니 다.
         ：이 클래스 에 대응 하 는 java.lang.Class 대상 은 어디에서 도 인용 되 지 않 았 으 며,어디에서 도 반 사 를 통 해 이 클래스 에 접근 할 수 없습니다.
        상기 세 가지 조건 을 만족 시 킨 후에 반드시 회수 되 는 것 이 아니 라 가상 컴퓨터 가 일부 매개 변 수 를 통 해 제어 되 어야 한다.
 
4.쓰레기 수집 알고리즘
       1.태그-지우 기
        이것 은 가장 기본 적 인 알고리즘 으로 태그 와 제거 두 단계 로 나 뉜 다.먼저 태그 에 회수 해 야 할 모든 대상 을 표시 하고 태그 가 완 료 된 후에 표 시 된 대상 을 제거 하 는 것 에 동의 한다.
        이 방법 은 주로 두 가지 부족 한 점 이 있다.하 나 는 제거 효율 이 너무 낮 고 이 두 과정의 효율 이 높 지 않다 는 것 이다.또 하 나 는 공간 문제 입 니 다.표 시 를 제거 한 후에 대량의 메모리 파편 이 발생 할 수 있 습 니 다.나중에 프로그램 이 실행 되 는 과정 에서 비교적 큰 대상 을 분배 해 야 할 때 충분 한 연속 메모 리 를 찾 지 못 해서 다른 쓰레기 수집 동작 을 미리 출발 해 야 합 니 다.
 
        2.복제 알고리즘
          효율 문 제 를 해결 하기 위해 서,사용 가능 한 메모 리 를 용량 에 따라 크기 가 같은 두 조각 으로 나 누고,매번 그 중의 한 조각 만 사용한다.메모리 가 다 떨 어 지면 살아 있 는 대상 을 다른 블록 으로 복사 한 다음 에 이미 사용 한 메모리 공간 을 한 번 에 지 웁 니 다.이렇게 하면 매번 전체 반 구역 에 대해 메모리 회 수 를 하고 메모리 분 배 를 할 때 메모리 조각 등 복잡 한 상황 을 고려 하지 않 아 도 된다.지붕 지침 을 이동 하여 순서대로 메모 리 를 분배 하면 간단 하고 효율 적 인 운행 을 실현 할 수 있다.
         메모 리 를 원래 의 절반 으로 줄 이 는 것 은 낭비 가 너무 높 기 때문이다.신세대 대상 의 98%가 아침저녁 으로 죽 기 때문에 1 대 1 의 비율 로 중국 반 메모리 공간 을 사용 하지 않 고 메모 리 를 하나의 Eden 공간,두 개의 Survivor 공간 으로 나 누 어 매번 Eden 공간 과 그 중의 Survivor 공간 을 사용 할 필요 가 없다.회수 할 때 Eden 과 Survivor 에서 살아 남 은 대상 을 다른 Survivor 공간 으로 한꺼번에 복사 한 다음 에 야 Eden 공간 과 방금 사 용 했 던 Survivor 공간 을 지 웠 다.HotSpot 가상 기기 의 기본 적 인 Eden 과 Survivor 의 비율 은 8 대 1 이다.즉,매번 10%만 낭비 되 지만 98%는 일반적인 상황 에서 특수 한 상황 일 때 Survivor 공간 이 부족 할 때 다른 저장 되 지 않 은(옛날 을 가리 키 는 말)에 의존 하여 담 보 를 분배 해 야 한다.이런 많이 나 온 대상 들 은 직접 분배 담보 체 제 를 통 해 옛날 로 들 어 갈 것 이다.
           3.태그-정리 알고리즘
            복제 수집 알고리즘 은 대상 의 생존 율 이 높 을 때 비교적 많은 복제 작업 을 해 야 하기 때문에 효율 이 낮 아진 다.50%의 공간 을 낭비 하지 않 으 려 면 사용 한 메모리 의 대상 이 100%생존 하 는 극단 적 인 상황 에 대응 하기 위해 별도의 공간 을 분배 하고 보증 해 야 하기 때문에 옛날 에 이런 알고리즘 을 직접 사용 할 수 없다.
            태그-정리 알고리즘 도 두 단계 로 나 뉜 다.첫 번 째 단 계 는 태그-제거 알고리즘 의 첫 번 째 단계 와 같 지만 후속 단 계 는 회수 가능 한 대상 을 직접 청소 하 는 것 이 아니 라 모든 생존 대상 을 한 끝 으로 이동 시 킨 다음 에 경계 이외 의 내 존 을 직접 제거 하 는 것 이다.
           4.세대 별 수집 알고리즘
           현재 상업 가상 컴퓨터 의 쓰레기 수집 은 모두'세대 별 수집'알고리즘 을 사용 하고 있 습 니 다.이 알고리즘 은 대상 의 생존 주기 에 따라 메모리 를 몇 개의 블록 으로 나 누 는 것 입 니 다.보통 자바 더 미 를 신세대 와 옛날 로 나 눈 다음 에 각 세대 의 특징 에 따라 가장 적당 한 수집 알고리즘 을 사용 합 니 다.신 생 대 는 복제 알고리즘 을 사 용 했 는데 옛날 에는 생존 율 이 높 고 추가 공간 이 없어 서 표기-정리 또는 표기-제거 알고리즘 을 사용 했다.