1

나는이 개념을 정확하게 이해하고 싶습니다. 설명/확인은 많은 도움이 될 것이고 나는 다른 많은 프로그래머들도 확신 할 것이다. 그래서 여기에 이러한 개념의 나의 이해, 내 조사의 결과입니다 : 여러 스레드 사이에 변수를 공유하고자 할 때volatile, syncronized 및 AtomicReference와 같은 개념을 올바르게 이해 했습니까?

  1. 휘발성이 사용됩니다. a) (스레드간에 공유되는) 변수를 volatile로 선언하고 그렇지 않음을 선언하는 차이점은 무엇입니까? b) 다른 스레드에서 액세스 할 때 항상 volatile로 선언해야합니까? c) 휘발성 변수를 동기화하는 것이 맞습니까?

  2. AtomicReference는 객체를 래핑하고 그 위에 원자 단위 연산을 제공하는 클래스입니다 (compareAndSet, lazySet 및 weakCompareAndSet). 이것은 모두, 동기화가 없으며 아무것도 아닙니다. a) AtomicReference를 volatile로 선언하는 것이 합리적입니까? b)하지만 AtomicReference.get이 동기화되지 않았거나 설정되지 않았습니까?

  3. 동기화 란 여러 스레드간에 공유되는 변수에 순차적으로 액세스하는 것을 의미합니다. 인스턴스별로 또는 클래스별로 수행 할 수 있습니다. 동기화는 메소드 헤더 나 코드 블록에 추가 될 수 있습니다. 여기에 어떤 신비 나는 :)

감사합니다, Aurelian에

+0

가능한 복제본 : http://stackoverflow.com/questions/9749746/what-is-the-difference-of-atomic-volatile-synchronize?rq=1 – dantuch

답변

2

가)에 (스레드간에 공유) 변수 휘발성이 아닌 선언 bwteen 차이점은 무엇입니까 희망하지?

휘발성이 아닌 경우 다른 스레드가 해당 스레드에 대한 쓰기를 볼 수 없습니다.

b) 다른 스레드에서 액세스 할 때 항상 volatile로 선언해야합니까?

동기화 된 블록에서 항상 액세스하지 않는 한.

c) 휘발성 변수를 동기화하는 것이 맞습니까?

휘발성 변수가 동기화 된 블록 외부에서 액세스되는 경우에만 그렇습니다.

a) AtomicReference를 volatile로 선언하는 것이 합리적입니까?

런타임시 인스턴스를 변경하려는 경우 분명히 그렇습니다. 그러나 일반적으로 final AtomicReference을 사용하는 것이 좋습니다.

B) 그러나 동기화? AtomicReference.get가 동기화되지 않기 때문에 나 세트?

동기식 AtomicReference 액세스는 Lock-free 멀티 스레딩의 목적을 완전히 상실합니다. 동기화 또는 AtomicReference를 선택하십시오.

+0

AtomicReference에서 가져 오기 및 설정이 동기화되지 않았으므로, 여러 스레드에서 액세스 할 수 있다면 상황을 망칠 수 없습니까? AtomicReference의 유일한 임무는 원자 적으로 실행되는 그 이상의 3 가지 메소드 (compareAndSet, lazySet 및 weakCompareAndSet)뿐입니다. 내가 잘못? – aureliangtx

+0

Unsafe 클래스는이 3 가지 메서드에서만 사용되며 아무 곳에도 동기화 된 블록이 표시되지 않기 때문에이 말을하고 있습니다. – aureliangtx

+0

예, 해당 작업은 호출 스레드의 관점 에서뿐만 아니라 다른 스레드. 그것들은 lock-free multithreading의 기본 요소를 구성합니다. 이러한 작업의 세밀한 정도가 특정 사용 사례에 충분하지 않으면 AtomicReference가 적합하지 않으므로 전혀 사용하지 않아야합니다. –

2

개의 스레드간에 변수를 공유하려면 휘발성이 사용됩니다. a) 차이점은 무엇입니까 ( 스레드간에 공유 됨) 변수가 휘발성이 아니라고 선언합니까? b) 우리는 항상 다른 스레드에서 액세스하고 있음을 항상 으로 선언해야합니까? c) 휘발성 변수를 동기화하기 위해 감각을 만드나요?

volatile을 이해하려면 최신 컴퓨터 시스템 하드웨어의 아키텍처에 대해 생각하는 것이 좋습니다.

성능을 향상시키기 위해 각 프로세서 또는 코어에는 자체 로컬 캐시가 있습니다. 이 캐시에있는 데이터는 특정 프로세서에 국한되며 다른 프로세서에서는 볼 수 없습니다. 또한 JVM 자체를 포함하여 거의 모든 수준의 데이터 캐시가있을 수 있습니다.

보장은 없습니다 :

당신이 프로세서들 사이 나눌 수 있습니다 실행의 단위 즉, 이런 식으로 스레드의 생각, 자바 메모리 모델의 매우 중요한 사실을 이해하기 쉽게 한 스레드에서 만들어진 공유 변수의 변경 사항은 동일한 변수에 액세스하는 다른 스레드에서 볼 수있게됩니다 (동기화하지 않음).

공유 변수를 업데이트 한 데이터가 여전히 다른 코어에서 사용할 수없는 로컬 프로세서 캐시에 있으므로 다른 프로세서에서 실행되는 다른 스레드에서는 사용할 수 없다고 상상해보십시오.

volatile 키워드는 공유 변수의 변경 사항이 메모리에 즉시 기록되어 다른 스레드에서 변경 내용을 볼 수 있도록 보장하는 방법을 제공합니다. Volatile은 단순한 상황에서 유용하며 데이터에 향상된 생명력을 제공하지만 원 자성을 보장하지 않으므로 공유 변수의 경쟁 조건이 여전히 발생하지 않을 것입니다. 다른 하나의 논리 상태에서 개체를 변이하는 것은 여러 단계를 필요로하는 경우

는 다음 개체의 상태에 대한 액세스를 동기화하는 것은 (업데이트 중 하나가 완전히 또는 전혀 발생) 경우 상태 전이가 포함 자성을 보존 할 필요가 변수는 volatile으로 선언되었습니다.

+0

휘발성 자체가 원 자성 보장을 제공하지는 않지만 참조를 설정하면 원 자성이 보장되므로 모든 것을 최신 상태로 유지해야하고 일관성있는 단일 참조 만 있으면 변동이 적절합니다 (AtomicReference.get() 및 .set()). 휘발성 필드 참조에서 작동). 따라서 특정 공유 변수에 대해 걱정이된다면 휘발성은 괜찮지 만 두 변수 이상을 동기화 상태로 유지해야하거나 '휘발성'객체에서 값을 업데이트하는 경우 동기화 또는 다른 잠금이 필요합니다 . –

관련 문제