Test5. 섹션6. 메모리가시성

[YuDeokRin]

Java 메모리 가시성 관련 객관식 문제 (10문제)
문제
1번. 다음 중 메모리 가시성(memory visibility) 문제에 대한 설명으로 올바른 것은?

① 단일 스레드 환경에서 발생하는 메모리 접근 문제이다
② 한 스레드가 변경한 값이 다른 스레드에서 언제 보이는지에 대한 문제이다
③ 메인 메모리의 용량이 부족할 때 발생하는 문제이다
④ 스레드가 너무 많이 생성되어 발생하는 성능 문제이다

2번. CPU 캐시 메모리에 대한 설명으로 틀린 것은?

① CPU 코어 가까이에 위치하여 빠른 속도를 제공한다
② 메인 메모리보다 상대적으로 가격이 저렴하다
③ 현대의 CPU는 대부분 코어 단위로 캐시 메모리를 보유한다
④ CPU 처리 성능을 개선하기 위해 사용된다

3번. volatile 키워드에 대한 설명으로 올바른 것은?

① 변수를 final로 만들어 변경을 방지한다
② 캐시 메모리를 사용하지 않고 메인 메모리에 직접 접근한다
③ 동기화 블록을 자동으로 생성해준다
④ 변수의 타입을 변경하는 키워드이다

4번. 다음 코드에서 work 스레드가 무한 루프를 탈출하지 못하는 이유는?

boolean runFlag = true;  // volatile 없음
// work 스레드: while(runFlag) { }
// main 스레드: runFlag = false;

① runFlag가 final로 선언되어 있어서
② work 스레드의 캐시 메모리에 있는 runFlag가 여전히 true여서
③ 자바 문법 오류가 있어서
④ main 스레드가 종료되어서

5번. 캐시 메모리의 값이 메인 메모리에 반영되는 시점은?

① 항상 즉시 반영된다
② 정확히 1초 후에 반영된다
③ CPU 설계와 실행 환경에 따라 다르며, 경우에 따라 평생 반영되지 않을 수도 있다
④ 프로그래머가 직접 flush() 메서드를 호출할 때만 반영된다

6번. volatile을 사용했을 때의 단점은?

① 메모리 사용량이 크게 증가한다
② 캐시 메모리를 사용하지 않아 성능이 상대적으로 느려진다
③ 컴파일 에러가 발생할 수 있다
④ 스레드 안전성을 보장하지 못한다

7번. happens-before 관계에 대한 설명으로 틀린 것은?

① 자바 메모리 모델에서 스레드 간의 작업 순서를 정의하는 개념이다
② A 작업이 B 작업보다 happens-before 관계에 있다면, A의 메모리 변경사항은 B에서 볼 수 있다
③ volatile 변수는 happens-before 관계를 형성하지 않는다
④ 스레드 간의 메모리 가시성을 보장하는 규칙이다

8번. 다음 중 happens-before 관계가 발생하지 않는 경우는?

① volatile 변수에 대한 쓰기 작업
② Thread.start() 호출
③ Thread.join() 호출
④ 일반 변수(non-volatile)의 읽기/쓰기

9번. 메모리 가시성 문제를 해결할 수 있는 방법이 아닌 것은?

① volatile 키워드 사용
② synchronized 블록 사용
③ ReentrantLock 사용
④ Thread.sleep() 사용

10번. 다음 코드에서 volatile을 사용한 경우와 사용하지 않은 경우의 성능 차이는 약 몇 배인가?

volatile boolean flag = true;
volatile long count;
while(flag) { count++; }

① 약 2배
② 약 5배
③ 약 10배
④ 차이가 거의 없다

[YuDeokRin]

답안 및 해설
1번 정답: ②
해설: 메모리 가시성(memory visibility)은 멀티스레드 환경에서 한 스레드가 변경한 값이 다른 스레드에서 언제 보이는지에 대한 문제입니다. 이름 그대로 메모리에 변경한 값이 보이는가, 보이지 않는가의 문제입니다.
2번 정답: ②
해설: 캐시 메모리는 메인 메모리보다 상대적으로 가격이 비쌉니다. 그래서 큰 용량을 구성하기는 어렵습니다. 대신 CPU와 가까이 있어 매우 빠른 속도를 제공합니다.
3번 정답: ②
해설: volatile 키워드를 사용하면 캐시 메모리를 사용하지 않고, 값을 읽거나 쓸 때 항상 메인 메모리에 직접 접근합니다. 이를 통해 여러 스레드 간의 메모리 가시성 문제를 해결할 수 있습니다.
4번 정답: ②
해설: volatile 키워드가 없으면 work 스레드는 자신의 CPU 코어의 캐시 메모리에 있는 runFlag 값(true)을 계속 읽습니다. main 스레드가 runFlag를 false로 변경해도 이는 main 스레드의 캐시 메모리에만 반영되고, work 스레드의 캐시 메모리에는 즉시 반영되지 않아 무한 루프를 탈출하지 못합니다.
5번 정답: ③
해설: 캐시 메모리의 값이 메인 메모리에 반영되는 시점은 CPU 설계 방식과 실행 환경에 따라 다릅니다. 즉시 반영될 수도 있고, 몇 밀리초 후, 몇 초 후에 될 수도 있고, 극단적으로는 평생 반영되지 않을 수도 있습니다. 주로 컨텍스트 스위칭이 될 때 갱신되지만 이것도 보장되지는 않습니다.
6번 정답: ②
해설: volatile을 사용하면 캐시 메모리를 사용할 때보다 성능이 느려집니다. 자료에 제시된 예제에서 약 5배의 성능 차이가 발생했습니다(volatile 없음: 약 11억, volatile 있음: 약 2.2억). 따라서 꼭 필요한 곳에만 사용하는 것이 좋습니다.
7번 정답: ③
해설: volatile 변수는 happens-before 관계를 형성합니다. "한 스레드에서 volatile 변수에 대한 쓰기 작업은 해당 변수를 읽는 모든 스레드에 보이도록 한다"는 것이 volatile 변수 규칙입니다. 즉, volatile 변수에 대한 쓰기 작업은 그 변수를 읽는 작업보다 happens-before 관계를 형성합니다.
8번 정답: ④
해설: 일반 변수(non-volatile)의 단순 읽기/쓰기는 happens-before 관계를 자동으로 형성하지 않습니다. 그래서 메모리 가시성 문제가 발생할 수 있습니다. volatile, synchronized, Thread.start(), Thread.join() 등은 모두 happens-before 관계를 형성합니다.
9번 정답: ④
해설: Thread.sleep()은 메모리 가시성 문제를 해결하는 공식적인 방법이 아닙니다. sleep() 호출 시 컨텍스트 스위칭이 발생하면서 캐시 메모리가 갱신될 수 있지만, 이것이 확실하게 보장되는 것은 아닙니다. 메모리 가시성 문제를 해결하려면 volatile, synchronized, ReentrantLock 등의 동기화 기법을 사용해야 합니다.
10번 정답: ②
해설: 자료에 제시된 예제 실행 결과에 따르면, volatile이 없을 때는 약 11억(1176711196), volatile이 있을 때는 약 2.2억(222297705)으로 물리적으로 약 5배의 성능 차이를 확인할 수 있습니다. 이는 volatile 사용 시 캐시 메모리를 사용하지 않고 메인 메모리에 직접 접근하기 때문입니다