[Java 동시성 싸움]------Java 메모리 모델 Volatile 분석

휘발성의 특성은 이전 블로그 [Fuck Java Concurrency]에서 이미 설명했습니다. - 휘발성 구현 원리에 대한 심층 분석:

1. 휘발성 가시성; 휘발성 읽기의 경우 이 변수에 대한 최종 쓰기를 항상 볼 수 있습니다.

2. 휘발성은 단일 읽기/쓰기에 대한 원자성입니다(32비트 Long, Double). 그러나 i++와 같은 연산을 제외하고 휘발성의 메모리 의미는 휘발성을 두 방향으로 도입합니다.

휘발성 및 이전 발생

3. 이 블로그 [Deadly Java Concurrency] - Java 메모리 모델 Happend-Before에서 LZ는 이전 발생이 데이터 저장 여부를 결정하는 데 사용된다고 설명합니다. 경쟁과 스레드 안전성의 기본은 멀티 스레드 환경에서 가시성을 보장하는 것입니다. 휘발성 변수를 읽고 써서 설정된 사전 발생 관계를 분석하는 고전적인 예를 들어보겠습니다.

   public class VolatileTest {
   
       int i = 0;    volatile boolean flag = false;    //Thread A
       public void write(){
           i = 2;              //1
           flag = true;        //2
       }    //Thread B
       public void read(){        if(flag){                                   //3
               System.out.println("---i = " + i);      //4
           }
       }
   }

선행 원칙에 따라 위 프로그램에 대해 다음 관계가 얻어집니다.

선행 프로그램 순서 원칙에 따르면 1번 발생- 2 이전에 3이 발생합니다.

휘발성 원칙에 따르면 2가 발생하기 전에 발생합니다.

• 이전 발생: 1 발생 -4 이전

• 작업 1과 작업 4는 이전 발생 관계를 가지므로 1은 4에 표시되어야 합니다. 일부 학생들은 '1번 작업과 2번 작업의 순서가 변경될 수 있습니다. 그게 가능합니까?'라고 질문할 수 있습니다. LZ의 블로그를 읽었다면 휘발성이 가시성을 보장하는 것 외에도 재정렬도 금지한다는 점을 이해하게 될 것입니다. 따라서 휘발성 변수를 쓰기 전에 스레드 A에 표시되는 모든 공유 변수는 스레드 B가 동일한 휘발성 변수를 읽은 직후 스레드 B에 표시됩니다.

메모리 의미론과 휘발성 구현

• JMM에서는 스레드 간 통신이 공유 메모리를 사용하여 구현됩니다. 휘발성의 메모리 의미는 다음과 같습니다.

휘발성 변수를 쓸 때 JMM은 스레드에 해당하는 로컬 메모리의 공유 변수 값을 주 메모리로 즉시 새로 고칩니다.

휘발성 변수를 읽을 때 JMM은 스레드에 해당하는 로컬 메모리를 유효하지 않은 것으로 설정하고 공유 변수를 주 메모리

에서 직접 읽습니다. 따라서 휘발성의 쓰기 메모리 의미가 직접 새로 고쳐집니다. 주 메모리. 읽기의 메모리 의미는 주 메모리에서 직접 읽는 것입니다.

그럼 휘발성 메모리 의미론은 어떻게 구현되나요? 일반 변수의 경우 재정렬되지만 휘발성 변수의 경우 재정렬되지 않습니다. 이는 메모리 의미에 영향을 미치므로 휘발성 메모리 의미를 달성하기 위해 JMM은 재정렬을 제한합니다. 재정렬 규칙은 다음과 같습니다.

은 다음과 같이 번역됩니다.

첫 번째 작업이 휘발성 읽기인 경우 두 번째 작업이 무엇이든 관계없이 읽을 수 없습니다. 재정렬되었습니다. 이 작업은 휘발성 읽기 이후의 작업이 컴파일러에 의해 휘발성 읽기 이전으로 재정렬되지 않도록 보장합니다.

두 번째 작업이 휘발성 쓰기인 경우 첫 번째 작업이 무엇이든 상관없습니다. , 둘 다 다시 주문할 수 없습니다. 이 작업은 컴파일러에 의해 휘발성 쓰기 이전 작업이 휘발성 쓰기 이후로 재정렬되지 않도록 보장합니다.

1. 첫 번째 작업이 휘발성 쓰기이고 두 번째 작업이 휘발성 읽기인 경우 재정렬되었습니다.

2. 휘발성의 기본 구현은 메모리 배리어를 삽입하는 것이지만 삽입된 메모리 배리어의 총 수를 최소화하는 최적의 배열을 컴파일러가 찾는 것은 거의 불가능하므로 JMM에서는 다음을 채택합니다. 보수적인 전략. 다음과 같습니다.

3. 각 휘발성 쓰기 작업 전에 StoreStore 장벽을 삽입

각 휘발성 쓰기 작업 후에 StoreLoad 장벽 삽입

• 각 휘발성 읽기 작업 후 LoadLoad 장벽 삽입

• 각 휘발성 읽기 작업 후 LoadStore 장벽 삽입

• StoreStore Barrier는 휘발성 쓰기 전에 그 앞의 모든 일반 쓰기 작업이 주 메모리로 플러시되었는지 확인할 수 있습니다.

StoreLoad 장벽의 목적은 휘발성 쓰기가 후속 휘발성 읽기/쓰기 작업으로 인해 재정렬되는 것을 방지하는 것입니다.

• LoadLoad 장벽은 프로세서가 위의 휘발성 읽기와 아래의 일반 읽기 순서를 변경하는 것을 방지하는 데 사용됩니다.

LoadStore 장벽은 프로세서가 위의 휘발성 읽기와 아래의 일반 쓰기 순서를 변경하는 것을 방지하는 데 사용됩니다.

위의 VolatileTest 예제를 분석해 보겠습니다.

public class VolatileTest {
    int i = 0;    
    volatile boolean flag = false;    
    public void write(){
        i = 2;
        flag = true;
    }    public void read(){        
    if(flag){
            System.out.println("---i = " + i); 
        }
    }
}

휘발성 명령의 메모리 장벽 범례를 예제를 통해 약간 보여줍니다.

Volatile의 메모리 장벽 삽입 전략은 실제로 매우 보수적입니다. 실제로 휘발성 쓰기-읽기 메모리 의미가 변경되지 않는 한 컴파일러는 특정 상황에 따라 최적화하고 불필요한 장벽을 생략할 수 있습니다. 다음과 같습니다(Fang Tengfei의 "The Art of Java Concurrent 프로그래밍"에서 발췌):

public class VolatileBarrierExample {
    int a = 0;    
    volatile int v1 = 1;    
    volatile int v2 = 2;    
    void readAndWrite(){        
    int i = v1;     //volatile读
        int j = v2;     //volatile读
        a = i + j;      //普通读
        v1 = i + 1;     //volatile写
        v2 = j * 2;     //volatile写
    }
}

최적화하지 않은 샘플 이미지는 다음과 같습니다.

분석해 보겠습니다. 위 이미지의 내용은 메모리 장벽 명령이 중복되어 있습니다

1

: 이는 유지되어야 합니다

2: 아래의 모든 일반 쓰기는 위의 휘발성 읽기로 재정렬될 수 없습니다. 그러나 두 번째 휘발성 읽기가 있기 때문에 일반 읽기는 두 번째 휘발성 읽기를 전혀 우회할 수 없습니다. 따라서 생략 가능합니다.

3: 아래는 일반적인 읽기가 없으므로 생략 가능합니다.

4: 예약됨

5: 예약됨

6: 뒤에 휘발성 쓰기, 따라서

7 생략 가능: 유지

8: 유지

이므로 2, 3, 6은 생략 가능, 그 개략도는 다음과 같습니다.

위는 [Dead Java Concurrency]의 내용입니다.------Java 메모리 분석 Model Volatile, more 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!