자바–단일 모드 및 더 블 잠 금 검사

자바–단일 모드 및 더 블 잠 금 검사
개발 한 우 리 는 단일 모델 에 대해 낯 설 지 않 을 것 이다.왜냐하면 프로젝트 에 사용 되 는 곳 이 상당히 많 기 때문이다.일반적으로 우 리 는 단일 모드 에 두 가지 표기 법 이 있다 는 것 을 알 고 있 습 니 다.로드 지연(게으름뱅이 식 이 라 고도 함)은 뜻 을 잘 알 고 있 습 니 다.사용 할 때 만 만 만 들 수 있 습 니 다.로드 지연(굶 주 림 이 라 고도 함)이 아니 라 올 라 오 자마자 만 들 지 않 아 도 됩 니 다.\##\##일례 모드 의 두 가지 표기 법
반응 시간 속도 에서 취사선택,비 지연 로드
1.1.비 지연 로드(굶 주 린 식)

public class SingletonNormal {

    private SingletonNormal(){}

    private static final SingletonNormal instance = new SingletonNormal();

    public static SingletonNormal getInc(){
        return instance;
    }
}

시스템 자원 이용 에서 취사선택 하고 지연 로 딩 합 니 다.다 중 스 레 드 개발 에 주의 하 십시오.getInc 는 동기 화 자 물 쇠 를 추가 해 야 합 니 다.
1.2.로 딩 지연(게으름뱅이 식)

public class SingletonLazy {
    private SingletonLazy() { }
    private static SingletonLazy instance;

    public synchronized static SingletonLazy getInc() {
        if (null == instance) {
            instance = new SingletonLazy();
        }
        return instance;
    }
}

다 중 스 레 드 모드 에서 의 로드 지연 방안 을 보 았 습 니 다.우 리 는 동기 화 잠 금 synchronized 가 하나의 무게 잠 금 이라는 것 을 알 고 있 습 니 다.같은 시간 에 하나의 스 레 드 만 이 코드 블록 을 실행 하도록 보장 합 니 다.만약 에 getInc 방법 에서 시간 을 소모 하 는 작업 이 있 으 면 여러 스 레 드 가 자주 getInc 방법 으로 잠 금 경쟁 을 하면 코드 의 집행 효율 을 크게 떨 어 뜨 릴 것 입 니 다.\##\###2.지연 로 딩 개선-더 블 잠 금 검 측 은 1.2 의 문제 에 대해 동기 화 된 잠 금 코드 블록 을 최소 화하 고 synchronized 잠 금 코드 라 이브 러 리 를 호출 하 는 횟수 가 적 으 며 두 가지 측면 에서 다 중 스 레 드 개발 에서 getInc 의 효율 을 높 여야 합 니 다.코드 는 다음 과 같 습 니 다:

public class SingletonDoubleCheck {

    private SingletonDoubleCheck() { }

    private static volatile SingletonDoubleCheck instance;//  1

    public static SingletonDoubleCheck getInc() {
        if (null == instance) {//  2
            synchronized (SingletonDoubleCheck.class) {
                if (null == instance) {//  3
                    instance = new SingletonDoubleCheck();//  4
                }
            }
        }
        return instance;
    }
}

개선 이 완 료 된 것 같 습 니 다.이 코드 는 JDK 1.5 이하 에 문제 가 있 을 수 있 습 니 다.현재 스 레 드 A 와 스 레 드 B 두 스 레 드 가 있다 고 가정 합 니 다.1.스 레 드 A 가 getInc 방법 에 들 어가 코드 2 곳 에 가서 null 로 판단 하고 동기 화 블록 에 들 어 갑 니 다.2.스 레 드 A 는 코드 3 곳 에 가서 null 로 판독 합 니 다.3.스 레 드 A 는 코드 4 곳 에 가서 new 작업 을 수행 합 니 다.Singleton Double Check 이 아직 예화 되 지 않 았 을 때 intance 를 비 null 로 합 니 다.4.스 레 드 B 는 getInc 방법 에 들 어가 코드 2 곳 으로 가서 비 null 을 판독 하고 돌아 갑 니 다.이때 스 레 드 B 코드 에서 inatance 인 스 턴 스 는 불완전한 대상 을 참조 합 니 다.그 이 유 는 대상 의 new 작업 이 원자 적 인 조작 이 아니 라 3 단계 로 나 뉘 기 때문이다.
1.인 스 턴 스에 메모리 할당
2.Singleton Double Check 의 구조 함 수 를 호출 하여 구성원 변 수 를 초기 화 합 니 다.
3,Singleton Double Check 대상 을 분 배 된 메모리 공간 으로 가리 키 기(이 단계 의 인 스 턴 스 를 실행 하면 null 이 아 닙 니 다)
JVM 의 명령 재 정렬(happen-before)때문에 명령 재 정렬 이라는 점 에 대한 지식 이 복잡 하고 인터넷 에 도 많은 자료 가 있 으 므 로 스스로 검색 할 수 있 습 니 다.
따라서 상기 스 레 드 B 는 초기 화 되 지 않 은 인 스 턴 스 를 받 았 습 니 다.사용 할 때 오류 가 발생 할 수 있 습 니 다.
상기 1.2 코드 세 션 중 코드 1 곳 의 volatile 키워드
에서 발췌 하 다.
volatile 차단 명령 의 정렬 을 다시 하 는 의 미 는 JDK 1.5 에서 완전히 복 구 됩 니 다.이전의 JDK 에서 변 수 를 volatile 로 성명 하 더 라 도 정렬 을 다시 하 는 데 발생 하 는 문 제 를 완전히 피 할 수 없습니다(주로 volatile 변수 전후의 코드 에 정렬 문제 가 존재 합 니 다).이 는 JDK 1.5 이전 자바 에서 DCL(더 블 잠 금 검사)을 안전하게 사용 해 단일 모드 를 구현 할 수 없 었 던 이유 이기 도 하 다.