DAY 26

🔖 오늘 읽은 범위 : 13. 동시성(226~235p)

---

🤓 책에서 기억하고 싶은 내용

객체는 처리의 추상화다. 스레드는 일정의 추상화다.

동시성이 필요한 이유

• 동시성은 coupling(결합) 을 없애는 전략
• what 과 when을 분리하는 전략
• 서블릿 웹 혹은 EJB 컨테이너라는 우산안의 컨테이너는 동시성을 부분적으로 관리
  • 웹 요청시마다 비동기식으로 서블릿을 실행
  • 특정 시스템은 throughput 개선을 위해 동시성 구현이 불가피

미신과 오해

아래 명제만 참이다

• 동시성은 다소 부하를 유발한다.
• 동시성은 간단한 문제도 복잡하게 한다.
• 동시성 버그는 재현이 어렵다 → 일회성 문제로 간주된다
• 동시성 구현을 위해서는 근본적인 설계 전략을 재고해야 한다

난관

• 두 스레드가 같은 변수를 동시에 참조할 경우

public class X {
    private int lastIdUsed;
    public int getNextId() {
        return ++lastIdUsed;
    }
}

• lastIdUsed 를 42로 설정하고 두 스레드가 X 인스턴스를 공유 할 경우
• (43, 43) 두 스레드 모두 43을 가지는 일부 경우가 생긴다

동시성 방어 원칙

단일 책임 원칙 SRP

• 주어진 매서드/클래스/컴포넌트를 변경할 이유가 하나여야 한다
• 동시성은 복잡성 하나만으로도 분리할 이유가 충분
• 동시성과 관련없는 코드에 동시성을 구현하는 사례가 많다
• 동시성 코드는 다른 코드와 분리해야한다
  • 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있다
  • 동시성 코드는 독자적인 난관이 있다.
  • 잘못 구현한 동시성 코드는 별의별 방식으로 실패한다.

따름 정리corollary: 자료 범위를 제한하라

• 공유 객체를 사용하는 코드 내 임계 영역critical section 을 synchronized 키워드로 보호
• 자료를 캡슐화 하여 공유 자료를 최대한 줄여라
  • 보호할 임계영역을 빼먹으면 공유 자료 수정하는 모든 코드를 망가뜨린다
  • 모든 임계 영역을 올바로 보호했는지 확인하느라 똑같은 노력과 수고 반복
  • 버그를 더 찾기 어려워진다

따름정리: 자료 사본을 사용하라

• 처음 부터 공유하지 않는 방법이 제일 좋다
• 어떤 경우에는 객체를 복사해 읽기 전용으로 사용할 수 있다
• 복사하는 비용과 시간이 가비지 컬렉션에 드는 부하보다 이득일 가능성 크다

따름 정리: 스레드는 가능한 독립적으로 구현

• 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할
• Eg) HttpServlet의 파생 클래스는 모든 정보를 doGet과 doPost 매개변수로 받는다
  • 독자적인 시스템에서 동작하는 것 처럼 요청을 처리

라이브러리를 이해하라

• 스레드 환경에 안전한 Collection 을 사용
• 서로 무관한 작업 수행시에는 executor 프레임 워크 사용
• 가능하다면 스레드가 차단 되지 않는 방법을 사용
• 일부 클래스 라이브러리는 스레드에 안전하지 못함

스레드 환경에 안전한 컬렉션

• 언어가 제공하는 클래스를 검토하라
  • 자바의 경우 java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks
• ConcurrentHashMap 은 HashMap보다 안전하며 성능도 좋음

실행 모델을 이해하라

• Bound Resource: 다중 스레드 환경에서 사용하는 자원, 크기나 숫자가 제한적 eg) DB연결, 길이일정한 읽기/쓰기 버퍼
• Mutual Exclusion: 한 번에 한 스레드만 공유 자료나 공유 자원을 사용할 수 있는 경우
• Starvation: 여러 스레드가 오래동안 자원을 기다림, 짧은 스레드만 우선순위를 주면 긴 스레드는 Starvation에 빠짐
• Deadlock: 여러 스레드가 서로 끝나기를 기다림
• Livelock: 락 거는 단계에서 각 스레드가 서로를 방해, 계속 진행하려 해도 resonance 로 오래동안 진행하지 못함

생산자-소비자

• 대기열은 한정된 자원
• 생산자 스레드는 대기열이 비어야 정보를 채우고
• 소비자 스레드는 대기열에 정보가 있어야 가져옴
• 잘못 시그널을 보낼 경우 둘 다 진행 가능함에도 서로 기다림

읽기-쓰기

• 읽기가 주로 공유 자원을 쓰다가 쓰기가 가끔 공유 자원을 갱신하는경우 처리율이 관건
• 읽기 와 쓰기 스레드의 요구를 적절히 만족시켜야한다
  1. 처리율 강조: 읽기 스레드가 없을 때까지 쓰기 스레드가 버퍼를 기다림 → 쓰기가 Starvation 에 빠짐
  2. 갱신 허용: 쓰기 스레드에게 우선권을 주면 처리율이 떨어짐

식사하는 철학자들Dining Philosophers

• 둥근 식탁에 철학자(스레드)와 각 왼쪽에 포크(자원) 이 놓였을 때
• 철학자는 배가 고프면 반드시 양손으로 포크 을 들고 스파게티를 먹음
• 왼쪽 혹은 오른쪽 철학자가 포크 사용중이면 기다려야함
• 스파게티 다 먹었으면 배고플때까지 생각에 잠김

🤔 떠오르는 생각

• 동시성은 내용에서 언급한 것처럼 문제가 발생했을 때에만 깨닫게 되며 버그 재현이 어렵기 때문에 쉬쉬하지만 가장 중요한 영역이기도 하다. 저자가 언급한 방어원칙을 미리 따라서 발생을 미연에 방지 할 수 있도록 해야겠다.

🔎 질문

📝 소감 3줄 요약

• 동시성방어원칙1. 자료 범위를 제한하라
• 동시성방어원칙2. 자료 사본을 사용하라
• 동시성방어원칙3. 스레드는 가능한 독립적으로 구현하라