[java] “휘발성”키워드는 무엇입니까?

휘발성 필드의 읽기는 의미를 얻습니다 . 이는 휘발성 변수에서 읽은 메모리가 다음 메모리를 읽기 전에 발생한다는 것을 보장합니다. 컴파일러가 재정렬을 수행하지 못하도록 차단하고 하드웨어에 필요한 경우 (약한 순서의 CPU), 특수 명령을 사용하여 휘발성 읽기 이후에 발생하지만 예측 적으로 일찍 시작되거나 CPU가 읽을 수있는 모든 읽기를 하드웨어가 플러시하도록합니다. 부하 획득 문제와 폐기 시점 사이에 투기 적 부하가 발생하지 않도록하여 초기에 조기에 발행되는 것을 방지합니다.

휘발성 필드의 쓰기에는 릴리스 시맨틱이 있습니다. 이는 모든 이전 메모리 쓰기가 다른 프로세서에 표시 될 때까지 휘발성 변수에 대한 모든 메모리 쓰기가 지연되도록 보장합니다.

다음 예제를 고려하십시오.

something.foo = new Thing();

경우 foo클래스의 멤버 변수이고, 다른 CPU에 의해 언급 된 개체 인스턴스에 액세스 할 수 있습니다 something, 그들은 값이 표시 될 수 있습니다 foo변화를 하기 전에 의 메모리 쓰기 Thing생성자는 전 세계적으로 볼 수 있습니다! 이것이 “약하게 정렬 된 메모리”라는 의미입니다. 컴파일러가에 저장하기 전에 생성자에 모든 저장이있는 경우에도 발생할 수 있습니다 foo. 경우 foo입니다 volatile후하는 가게 foo릴리스 의미를 가질 것이며, 하드웨어 보증은 쓰기 전에 쓰기의 모든 것을에 foo쓰기가 허용하기 전에 다른 프로세서에 볼 수 있습니다 foo발생할 수 있습니다.

쓰기 foo순서가 너무 나빠질 수 있는 방법은 무엇입니까? 캐시 라인 보유 foo가 캐시에 있고 생성자의 저장소가 캐시를 놓친 경우 캐시 누락에 대한 쓰기보다 훨씬 빨리 저장소를 완료 할 수 있습니다.

인텔의 (끔찍한) Itanium 아키텍처는 메모리를 약하게 주문했습니다. 원래 XBox 360에 사용 된 프로세서의 메모리가 약합니다. 널리 사용되는 ARMv7-A를 포함한 많은 ARM 프로세서는 메모리를 약하게 주문했습니다.

잠금과 같은 것들이 본질적으로 동시에 의미를 획득하고 릴리스하는 것과 동일한 전체 메모리 장벽을 수행하기 때문에 개발자들은 종종 이러한 데이터 경쟁을 보지 못합니다. 잠금을 획득하기 전에 잠금 내부의로드를 추론 적으로 실행할 수 없으며 잠금을 획득 할 때까지 지연됩니다. 잠금 해제에서 저장을 지연시킬 수 없으며 잠금 해제 명령은 잠금 내부에서 수행 된 모든 쓰기가 전체적으로 표시 될 때까지 지연됩니다.

보다 완전한 예는 “이중 체크 잠금”패턴입니다. 이 패턴의 목적은 객체를 지연 초기화하기 위해 항상 잠금을 획득하지 않아도되는 것입니다.

Wikipedia에서 n

public class MySingleton {
    private static object myLock = new object();
    private static volatile MySingleton mySingleton = null;

    private MySingleton() {
    }

    public static MySingleton GetInstance() {
        if (mySingleton == null) { // 1st check
            lock (myLock) {
                if (mySingleton == null) { // 2nd (double) check
                    mySingleton = new MySingleton();
                    // Write-release semantics are implicitly handled by marking
                    // mySingleton with 'volatile', which inserts the necessary memory
                    // barriers between the constructor call and the write to mySingleton.
                    // The barriers created by the lock are not sufficient because
                    // the object is made visible before the lock is released.
                }
            }
        }
        // The barriers created by the lock are not sufficient because not all threads
        // will acquire the lock. A fence for read-acquire semantics is needed between
        // the test of mySingleton (above) and the use of its contents. This fence
        // is automatically inserted because mySingleton is marked as 'volatile'.
        return mySingleton;
    }
}

이 예에서 MySingleton생성자에있는 상점은에 저장하기 전에 다른 프로세서에 표시되지 않을 수 있습니다 mySingleton. 이런 일이 발생하면 mySingleton을 들여다 보는 다른 스레드는 잠금을 얻지 못하며 반드시 생성자에 대한 쓰기를 수행하지는 않습니다.

volatile캐싱을 방지하지 않습니다. 이 기능은 다른 프로세서가 “참조”하는 순서를 보장합니다. 상점 릴리스는 보류중인 모든 쓰기가 완료되고 관련 회선이 캐시 된 경우 다른 프로세서가 캐시 회선을 버리고 / 기록하도록 지시하는 버스주기가 발행 될 때까지 저장소를 지연시킵니다. 로드 획득은 추측 된 읽기를 플러시하여 과거의 오래된 값이되지 않도록합니다.

---

답변