2. 2.1 동작하는 가장 단순한 코드
❏ 1일차 : 상호 배제와 메모리 모델
❏ 2일차 : 내제된 잠금 장치를 넘어서
❏ 3일차 : 거인의 어깨 위에서
3. 2.2 1일차 : 상호배제와 메모리 모델
❏ 상호배제(Mutual exclusion)
❏ 경쟁조건(Race condition)
❏ 데드락(deadlock)
❏ 메모리 모델
4. 2.2.1 스레드 만들기
Hello from new thread
Hello from main thread
Hello from main thread
Hello from new thread
5. 2.2.2 첫번째 잠금장치
● 문제 : 두 쓰레드가 동시에
increment()를 실행하는 Race
condition 발생
● 해법 : 접근을 동기화하기
위해서 내재된 잠금(intrinsic
lock)을 이용
내재된 잠금장치 이용
6. 2.2.3 메모리의 미스터리
● 문제 : 어떤 스레드가 동작한
결과가 다른 쓰레드에는
보이지 않는 경우 존재
○ 컴파일러는 코드가
실행되는 순서를
바꿈으로써 정적 최적화를
수행
○ JVM은 코드가 실행되는
순서를 바꿈으로써 동적
최적화
○ 코드를 실행하는
하드웨어는 코드의 순서를
바꾸는 것
7. 2.2.4 메모리 가시성
자바 메모리 모델 : 한 스레드가 메모리에 가한 변화가 다른 메모리에 보이는 경우를
정의
단, 읽는 스레드와 쓰는 스레드가 동기화되지 않으면 그러한 가시성이 보장되지 않음
8. 2.2.5 여러 개의 잠금장치
미리정해진 공통순서를 적용
잠금장치 요청시
공통순서를 따름
10. 2.2.7 1일 차 마무리
❏ 공유되는 변수에 대한 접근을 반드시 동기화한다.
❏ 쓰는 스레드와 읽는 쓰레드가 모두 동기화 되어야 한다.
❏ 여러개의 잠금장치를 미리 정해진 공통의 순서에 따라 요청한다.
❏ 잠금장치를 가진 상태에서 외부 메서드를 호출하지 않는다.
❏ 잠금장치는 최대한 짧게 보유한다.
11. 2.2.7 1일 차 마무리
❏ 자바 메모리 모델
❏ 참조 : http://changsuk.me/?p=2050
❏ 동기화와 가시성
❏ 자바의 표준 문서에선 JMM 명세를 통해 ‘먼저 발생한 일(happens-before)’이 무엇인지
보장함으로써 가시성의 단서를 제공
❏ 가시성을 위협하는 요소들
❏ 프로세서 캐시
❏ 동작의 재배열
❏ Volatile 키워드
13. 2.2.7 1일 차 마무리
❏ 중복확인 잠금(double checked locking) 안티 패턴
14. 2.3 2일 차 : 내재된 잠금장치를 넘어서
내재된 잠금장치의 한계
❏ 내재된 잠금장치를 얻으려다가 블로킹 상태에 빠진 쓰레드를 원상복귀시킬 방법이 없다.
❏ 내재된 잠금장치를 얻으려고 노력하는 시간을 강제로 중단 시키는 타임아웃 기능이 없다.
❏ 내재된 잠금장치를 얻는 방법이 하나만 존재한다.
16. 2.3.2 타임아웃
● 문제 : 타임아웃이 데드락
상태에서 빠져나올수 있는
방법을 제공할뿐
● 데드락이라는 상황 자체를
발생 시키지 않는 것이 중요
17. 2.3.3 협동 잠그기
연결리스트에 노드를 하나 삽입하려는 경우
협동 잠그기는 리스트의 일정한 부분만 잠그고,
그 외에 다른 노드에 대한 접근은 허용
18. 2.3.4 조건 변수
ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();
lock.lock () ;
Try {
while (! <<조건이 참이다.>>)
condition await();
≪공유되는 지원 사용≫
} finally {
lock.unlock();
}
19. 2.3.5 원자 변수
원자 변수는 잠금장치나
블로킹에 기대지 않고
동기화를 구현하는 논블로킹,
락프리 알고리즘의 기초를 제공한다.
20. 2.3.6 2일차 마무리
❏ 잠금장치를 얻고자 기다리는 과정을 가로챌 수 있 다.
❏ 잠금장치를 기다리는 동안 타임아웃이 발생할 수 있 다.
❏ 잠금장치를 얻고 반납하는 동작이 임의의 순서로 일어날 수 있다.
❏ 임의의 조건이 참이되는 것을 기다리기 위해 조건변수를 사용할 수 있다.
❏ 원자변수를 이용해서 잠금장치를 사용하는 것을 피할 수 있다.
24. 2.4.2 카피온라이트
1일 차 updateProgress()를 수정해서 방어적인 카피 방식을
자바 표준 라이브러리 CopyOnWriteArrayList를 사용해서 더 깔끔하게 처리
updateProgress()가 호출될 때마다 복제를 수행하는 것이 아니라 (훨씬 드물게 생길)
listeners의 값이 변경될 때에 한해서 복제를 하기 때문에 성능 면에서 더 효율적
30. 2.4.4 3일차 마무리
java.util.concurrent 패키지에서 제공하는 도구 이용하면
동시성 코드 를 쉽게 만들 수 있고, 프로그램을 더 안전하고 효과적으로 만들 수 있음
❏ 스레드를 직접 만드는 대신 스레드 풀을 이용한다.
❏ CopyOnWriteArrayList를 이용해 리스너 관리를 더 쉽고 효과적으로 만든다.
❏ 생산자와 소비자가 ArrayBlockingQueue를 이용해 더 효과적으로 의사소통을 한다.
❏ ConcurrentHashMap을 이용해 맵에 대한 동시적인 접근을 지원한다.
31. 2.4.4 3일차 마무리
❏ ForkJoinPool
❏ 큰 업무를 작은 업무 단위로 쪼개고, 그것을
각기 다른 CPU에서 병렬로 실행한후 결과를
취합하는 방식
❏ 참조 :
http://homes.cs.washington.edu/~djg/teachi
ngMaterials/grossmanSPAC_forkJoinFrame
work.html
32. 2.4.4 3일차 마무리
❏ CountDownLatch와 CyclicBarrier : 쓰레드간 처리를 동기화
두 스레드 사이에 로직을
동기화하는 데 사용
메인 스레드에서 작업을
처리하는 실행하는
Worker스레드를 만들어
실행하고,
개별 Worker스레드가
카운트다운래치의 값을
하나씩 제거하여 0이
되면 메인 스레드가
시그널을 받아서 흐름을
진행
33. 2.4.4 3일차 마무리
❏ 암달의 법칙(Amdahl's law)
❏ 프로세서를 아무리 추가하더라도 성능 향상은
순차적인 부분에 의해 제한된다.
❏ 구스타프슨의 법칙(Gustafson's Law)
❏ 대용량 데이터 처리는 효과적으로 병렬화할 수
있다는 법칙
34. 2.5 마치며
어떤 사람들은 이것이 올바르게 사용하는 것 이 너무나 어렵게 느껴지기 때문에, 아예
사용하는 것을 회피하고 멀티스레드 코드를 작성하는 것 자체를 원치 않는다.
어떤 사람들은 그런 호들갑을 이해하지 못한다. 몇 개의 간단한 규칙만 지켜지면
충분하고, 그렇게 하는 것이야 말로 다른 어떤 형태의 프로그래밍과 다를 바 없다고
여긴다.
35. 2.5 관리
❏ 스레딩과 관련된 문제는 안정적으로 테스트할 수 없기 때문에, 멀티 스레드를
사용하는 코드를 대할 때 신중에 신중을 기울이는 방법 밖에는 없다.
❏ 멀티스레딩 프로그래밍을 어렵게 만드는 것은 코드를 작성하는 것이 어려운 것이 아니라
테스트하는 것이 어렵기 때문이다. 어떤 함정에 빠질 수 있기 때문이 아니라 함정에 빠졌다는
사실 자체를 알 수 없기 때문에 어려운 것
36. 2.5 다른 언어들
코드의 순서가 뒤바뀌는 현상은 자바에만 국한되는 내용은 아니다.
차이점이 있다면 언어는 대개 그런 뒤바뀜이 언제 어떻게 일어나는지를 설명하는
명확한 메모리 모델을 가지고 있지 않다는 점이다.
C와 C++의 경우에는 최근에 C11과 C++ 11 표준에 메모리 모델이 추가됨으로써 이런
차이를 메웠다.
37. 2.5 마지막 생각
이런 여러 가지 문제점에도 불구하고,
멀티스레딩 프로그래밍은
오랫동안 우리 곁에 머물 것이다.
