[Java 동시성 싸움]------Java 메모리 모델 Volatile 분석-java지도 시간-php.cn

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

黄舟

풀어 주다： 2017-02-24 10:07:47

원래의

1415명이 탐색했습니다.

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

휘발성 가시성; 휘발성 읽기의 경우 이 변수에 대한 최종 쓰기를 항상 볼 수 있습니다.
휘발성은 단일 읽기/쓰기에 대한 원자성입니다(32비트 Long, Double). 그러나 i++와 같은 연산을 제외하고 휘발성의 메모리 의미는 휘발성을 두 방향으로 도입합니다.
이 블로그 [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은 재정렬을 제한합니다. 재정렬 규칙은 다음과 같습니다.

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

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

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

첫 번째 작업이 휘발성 쓰기이고 두 번째 작업이 휘발성 읽기인 경우 재정렬되었습니다.
휘발성의 기본 구현은 메모리 배리어를 삽입하는 것이지만 삽입된 메모리 배리어의 총 수를 최소화하는 최적의 배열을 컴파일러가 찾는 것은 거의 불가능하므로 JMM에서는 다음을 채택합니다. 보수적인 전략. 다음과 같습니다.
각 휘발성 쓰기 작업 전에 StoreStore 장벽을 삽입

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

각 휘발성 읽기 작업 후 LoadLoad 장벽 삽입
각 휘발성 읽기 작업 후 LoadStore 장벽 삽입
StoreStore Barrier는 휘발성 쓰기 전에 그 앞의 모든 일반 쓰기 작업이 주 메모리로 플러시되었는지 확인할 수 있습니다.
LoadLoad 장벽은 프로세서가 위의 휘발성 읽기와 아래의 일반 읽기 순서를 변경하는 것을 방지하는 데 사용됩니다.

위의 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写
    }
}

로그인 후 복사

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

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