동시성의 필요성
- 구조적 개선 = 무엇과 언제를 분리
- 응답시간, 처리량 개선
동시성에 대한 오해
- 동시성은 항상 성능을 높여준다(X)
- 동시성을 구현해도 설계는 변하지 않는다(X)
- 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다(X)
- 동시성은 다소 부하를 유발한다(O)
- 동시성은 복잡하다(O)
- 일반적으로 동시성 버그는 재현하기 어렵다(O)
- 동시성을 구현하려면 근본적인 설계 전략을 재고해야 한다(O)
동시성 방어 원칙
- SRP 지키기
- 자료의 범위 제한
- 자료의 사본 사용
- 스레드는 가능한 독립적으로 구현
다중 스레드 애플리케이션 실행 모델
- 생산자-소비자(Producer-Consumer)
생산자와 소비자가 둘 다 진행 가능함에도 서로에게서 시그널을 기다리는 상황이 발생할 수 있음
- 읽기-쓰기(Readers-Writers)
읽기와 쓰기 중 한쪽에 치중하게 되면 읽기 처리율이 떨어지거나 쓰기가 기아 상태에 빠질 수 있음
- 식사하는 철학자들(Dining Philosophers)
여러 프로세스가 공통의 자원을 얻으려 경쟁하는 경우 데드락, 라이브락, 처리율 저하, 효율성 저하가 발생할 수 있음
스레드 코드 테스트
- 문제를 노출하는 테스트 케이스를 작성할 것
- 다양한 설정, 환경 케이스로 테스트 해볼 것
- 실패 했을 경우 원인을 정확하게 파악할 것
내 생각
다중 스레드 개발을 신경써서 해 본적이 없어서 어렵게 느껴졌던 챕터이다. 안드로이드 개발할 때 Service 사용하면서 synchronized 를 사용한 적은 있는데 잘 모르고 사용한거라 패스. 오래 걸리는 UI 작업을 별도의 스레드에서 돌리곤 했지만 레이스 컨디션에 대해 신경을 썼던 적이 없다. 여러모로 더 공부가 필요한 챕터...
