chj990707
commented
1 year ago - 동시성은 언제와 무엇의 결합을 분리한다
- 동시성 방어 원칙
- 단일 책임 원칙: 동시성 코드는 다른 코드와 분리하라
- 공유하는 자료를 최소한으로 하라, 자료의 사본을 제공하라
- 스레드는 가능한 독립적으로 구현하라
- 다중 스레드의 모델
- 생산자-소비자 모델
- 생산자: 큐/스택에 데이터를 전달
- 소비자: 전달된 데이터를 처리
- 생산자가 데이터 전송 메시지를, 소비자가 데이터 필요 메시지를 보냄
- 생산자와 소비자가 서로의 메시지를 기다리는 경우가 발생할 수 있음
- 읽기-쓰기 모델
- 읽기: 공유 자원을 읽는 스레드
- 쓰기: 공유 자원에 쓰는 스레드
- 쓰기 스레드가 공유 자원을 오랫동안 점유해 속도가 저하될 수 있음(반대도 가능)
- Dining Philosophers
- 복수의 공유 자원을 독점해야 작업을 진행할 수 있을때 모든 스레드가 부분적으로만 독점해서 데드락이 발생하는 문제
- 스레드 테스트하기
- 이해할 수 없는 문제는 잠정적으로 스레드 문제로 간주하라
- 다중 스레드와 관련 없는 부분부터 테스트하라
- 다양한 환경(속도 등)에서 다중 스레드를 테스트하라
- 상황에 맞게 다중 스레드를 조율할 수 있게 테스트하라
- 프로세서 수보다 많은 스레드를 테스트하라
- 다른 플랫폼에서 돌려보라
- 강제로 실패를 일으켜라
생각
다중 스레드 코드는 거의 사용한 적이 없지만, 이 장에서 다루는 데드락 문제 등은 이론적으로나마 접한 적이 있다. 다중 스레드 환경에 대해 다양한 테스트 원칙을 제시한 것으로부터 저자가 테스트 코드를 상당히 중시한다는 인상을 다시 느꼈으며, 각각의 테스트 원칙에 대한 문단에서 스레드 환경에서 발생할 수 있는 문제에 대한 깊은 생각이 느껴진다.
요약
동시성은 무엇과 언제라는 결합을 없애는 전략이다
동시성 방어 원칙
SRP 준수: 동시성으로만 처리할 수 있는 책임만 분리해서 스레드로 만들어라
자료 범위를 제한: 공유 자원에 접근할 때는 동기적으로 접근하도록 하여 여러 스레드가 동시에 하나의 자원을 접근하는 것을 방지해라
자료를 복제해 사본을 만들어 전달: 읽기 전용 객체를 만들어 공유 객체를 피하는 방법
자료구조를 사용해야 한다면 thread-safe한 자료구조를 사용해라(java.util.concurrent)
다중 스레드를 사용하는 대표적인 모델
Producer-Consumer
Readers-Writers
Dining Philosophers
스레드 코드 테스트
스레드를 고려하기 전에 순차적으로 잘 돌아가는 코드를 먼저 만들어라
시스템의 실패는 일회성이라고 넘어가서는 안된다
말이 안되는 실패는 스레드 문제일 수 있다
스레드는 독립적으로 실행 가능할 정도로 구현해라
다른 플랫폼에서 스레드 테스트 코드를 돌려봐라
코드에 보조코드를 넣어 스레드 흐름을 강제로 흔들어서 실패를 발생시켜봐라
생각
스레드 테스트를 하면서 FIRST원칙을 어떻게 지킬 수 있을까를 고민한 적이 있다. 당시에는 '스레드로 발생할 수 있는 모든 경우의 수를 체크할 수 없다' 라고 잠정 결론을 짓고 순차적인 코드로만 테스트를 했었다. 이 챕터에서 제시한 스레드 환경에서의 테스트는 '개발자가 모든 경우의 수를 예측할 수 없기에 오류를 최대한 많이 찾아낼 수 있는 환경으로 접근하라'는 방식으로 이해하였다. 스레드의 테스트는 언젠가 실패할 수 있다는 것을 감안하고 작성할 수 밖에 없구나라는 생각을 하였다.