[Week] 7주차 진도

[ChoMk]

• 발표자를 제외한 인원은 느낀점, 질문사항을 코멘트로 남겨주세요.
• 발표자는 발표자료를 준비하시고 공유해주세요.

이번 주 발표자

• @ChoMk

진도

• chapter 13: 동시성

발표자료

• 발표자료 링크는 여기에!

[minSW]

[Chapter 13] 동시성

📖 기억에 남는 부분 & 느낀점

객체는 처리의 추상화다. 스레드는 일정의 추상화다. - 제임스 O.코플리엔

• 여러 스레드를 동시에 돌리는 이유와 어려움
• 어려움에 대처해 깨끗한 코드를 작성하는 방법과, 동시성을 테스트하는 방법과 문제점.

동시성이 필요한 이유

• 동시성은 결합(coupling)을 없애는 전략
  • 무엇(what) 과 언제(when) 을 분리하는 전략
  • => 애플리케이션 구조와 효율 ↑
• 동시성 채택 이유?
  • 구조적 개선, 응답시간 및 throughput 개선, 대량의 정보에 대한 병렬처리, ...
  • 그러나 결합분리(decoupling) 전략은 완벽과 거리가 멂
• 동시성에 대한 미신과 오해 -> 옳은 생각
  • 동시성은 다소 부하를 유발
  • 동시성은 복잡
  • 일반적으로 동시성 버그 재현 HARD
  • 동시성을 구현하려면 근복적인 설계 전략 재고 필요

동시성 방어 원칙

• 동시성 코드가 일으키는 문제로부터 시스템을 방어하는 원칙과 기술
• 단일책임원칙 (SRP, Single Responsibility Principle)
  • 왜안나오나했다
  • ✔️동시성 코드는 다른 코드와 분리
• 따름 정리 (corollary)
  • 자료 범위를 제한하라
  • ✔️자료 캡슐화 & 공유 자료 최소화
  • 자료 사본을 사용하라
  • read only? immutable type?
  • 수행시간 절약 vs 사본생성+GC부하
  • 스레드는 가능한 독립적으로 구현하라
  • ✔️자료를 독립적인 단위로 분할
  • (독자적인 스레드 + 가능하면 다른 프로세서에서 돌려도 괜찮도록)

그 외

• 라이브러리를 이해하라

  • ✔️언어가 제공하는 클래스를 검토 (ex. java.util.concurrent)

• 실행 모델을 이해하라

  • ✔️ 다중 스레드 프로그래밍의 실행 모델 및 해법 이해
  • Producer-Consumer
  • Readers-Writers
  • Dining Philosophers

• 동기화하는 메서드 사이에 존재하는 의존성을 이해하라

  • 개별메서드를 보호 (java의 경우 synchronized)
  • p.424 메서드 사이에 존재하는 의존성을 조심하라
  • ✔️ 공유 객체 하나에는 메서드 하나만 사용
  • 여러 메서드가 필요한 상황에는 다음의 방법 고려
  • 클라이언트에서 잠금
    • p.427 "진짜 사람이 할 짓이 아니다."
  • 서버에서 잠금
  • 연결(Adapted) 서버
    • 서버를 변경할 수 없는 경우?

• 동기화하는 부분을 작게 만들어라

• 올바른 종료 코드는 구현하기 어렵다

  • ✔️ 종료 코드를 개발 초기부터 구현하라 (이미 나온 알고리즘 검토 O)

스레드 코드 테스트하기

• ✔️ 문제를 노출하는 테스트 케이스 작성할 것 (설정과 부하를 바꿔가며..)

  1. "말이 안되는 실패는 잠정적인 스레드 문제로 취급하라"
     • 시스템 실패를 '일회성'으로 치부하지 X
  2. "다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자"
     • POJO에 넣는 코드는 많을 수록 더 좋다? (=> 멀티스레드에 영향을 받지않는 부분이 많을 수록 좋다?!)
     • 스레드 환경 밖에서 코드를 올바로 돌릴 것. 동시에 디버깅 X
  3. "다중 스레드를 쓰는 코드 부분을 다양한 환경에 쉽게 끼워 넣을 수 있게 스레드 코드를 구현하라"
     • 다양한 설정에서 실행할 목적으로 코드 구현
  4. "다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라"
  5. "프로세서 수보다 많은 스레드를 돌려보라"
  6. "다른 플랫폼에서 돌려보라"
  7. "코드에 보조 코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라"

• 보조코드 추가하는 방법 2가지

  • 직접 구현하기
  • 코드에 직접 wait(), sleep(), yield(), priority() 등의 함수 추가
  • 😶 인상깊었던 부분
    • "코드가 실패한다면 보조코드를 추가했기 때문이 아니다. 원래 잘못된 코드인데 증거가 드러났을 뿐이다"
  • 자동화
  • AOF, CGLIB, ASM 등과 같은 도구 사용
  • 예제 jiggle() 기법을 통한 오류 찾기

결론

• 다중 스레드 코드는 각별히 깨끗하게 코드를 짜야함
  • SRP를 준수
  • POJO를 사용해 스레드를 아는 코드와 모르는 코드를 분리
• => 스레드 코드는 최대한 집약되고 작아야함
  • 동시성 오류를 일으키는 잠정적 원인을 철저히 이해
  • 사용하는 라이브러리와 기본 알고리즘 이해
  • 보호할 코드영역을 찾아내는 법 & 특정 코드 영역을 잠그는 법 이해
• 스레드 코드는 많은 플랫폼에서 많은 설정으로 반복해서 테스트해야
  • 테스트 용이성은 TDD 3대 규칙
  • 깔금한 접근방식을 취한다면, 코드가 올바로 돌아갈 가능성이 극적으로 높아진다
  • 근데 현실적으로.... 🥺

[jin5335]

ch13. 동시성

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

느낀점

• 응답 시간 및 작업 처리량(throughput) -> 동시성 구현이 필요해지는 시점이 온다.
• 쉬운 코드도, 다중 스레드로 구현하려면 복잡해진다.
• 동시성 구현을 위해선, 최소한의(즉, 꼭 필요한) 자원만을 공유해라. -> 공유 자원 보호하는 것이 제일 어렵.(보호하는 부분이 많을수록 성능이 낮아짐)

  용어

  • 한정된 자원(Bound Resource) - 다중 스레드 환경에서 사용하는 자원(나눠써야하는 것들, 데이터 베이스 연결, 읽기/쓰기 버퍼 등등)
  • 상호 배제(Mutual Exclusion) - 한 번에 한 스레드만 공유 자료나 공유 자원을 사용할 수 있는 경우를 말함.
  • 기아(Starvation) - 스레드가 굉장히 오랫동안 자원을 기다리는 것
  • 데드락(Deadlock) - 여러 스레드가 서로가 끝나기를 기다리는 상태.
  • 라이브락(Livelock) - 락을 거는 단계에서, 서로를 방해하는 것 ...? -> 첨들어봄

    실행 모델

  • 생산자 소비자
  • 읽기 쓰기
  • 식사하는 철학자들
• 동시성을 가진 모델에서 동기화하는 부분은 최소화하자.(동기화하려면, 기다려야하니까..?)
• 다중 스레드 코드 테스트 -> 컴파일러에 의해서 우리가 생각하는 코드 단위보다 더 작게 쪼개져서 실행 -> 예상치 못한 결과를 일으킴
  • 다중 스레드 코드 테스트와 코어 로직 테스트(순차 코드 테스트) 는 분리해서 진행하자.
  • 싱글 스레드를 사용하는 순차 코드 부터 잘 돌게할 것.
• 일회성 오류는 없다! -> 잘 나타나지 않는 오류를 일회성으로 취급하고 쉽게 넘어가지 말것.
• 다양한 플랫폼에서 테스트 - 플랫폼마다 스케줄링 방식이 달라서, 다른 결과를 가져올 수 있음. 그러니 코드가 사용될 모든 플랫폼에서 테스트를 진행해볼것!

결론

• SRP, POJO를 사용해 스레드를 아는 코드와 스레드를 모르는 코드로 철저히 분리할 것.
• 동시성 오류가 나는 원인에 대해서 알고 있을 것 - 여러 스레드가 공유 자원에 동시에 갱신 / 자원 풀을 공유 등등
• 사용하는 라이브러리 및 기본 알고리즘에 대해 알고 있을 것 (스레드가 어떻게 이용되는지 정도..?)
• 보호해야하는 코드는 보호하된, 그 영역을 최소화 할 것!!! -> 최대한 깔끔히 짜라....ㅎㅎ