일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 실전사례
- 데이터유통
- 데이터플랫폼
- 알고스팟
- 테스트주도개발
- 동시성
- clean code
- 회고
- 단위테스트
- spray
- 개발7년차매니저1일차
- coursera
- 코딩인터뷰
- wait region split
- datalake
- 개발자
- hackercup2017
- functional thinking
- kafka
- 함수형 사고
- Raw-Request-URI
- 데이터레이크
- 해커컵
- 클린코드
- 박종천
- 데이터야놀자
- 개발자로살아남기
- 켄트백
- 2016년회고
- 2017회고
- Today
- Total
Software Engineering Note
13장. 동시성 본문
동시성이 필요한 이유
동시성은 결합을 없애는 전략이다. => "무엇"과 "언제"를 분리한다.
구조적 관점: 무엇과 언제를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다.
처리량 개선: 응답을 기다리는 웹 정보 수집기, 많은 사용자를 처리해야 하는 시스템 등에서 동시성이 요구됨
동시성에 대한 미신과 오해
동시성은 항상 성능을 높여준다 => 동시성은 "때로" 성능을 높여준다.
동시성을 구현해도 설계는 변하지 않는다 => 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달라진다.
웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다.
=> 컨테이너가 어떻게 동작하는지, 어떻게 동시 수정, 데드락 등과 같은 문제를 피할 수 있는지 알아야 한다.
동시성에 대한 타당한 생각
동시성은 다소 부하를 유발한다.
동시성은 복잡하다.
일반적으로 동시성 버그는 재현하기 어렵다.
동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.
동시성 방어 원칙
단일 책임 원칙(SRP)
동시성 코드는 다른 코드와 분리하라.
자료범위를 제한하라
자료를 캡슐화 하고 공유 자료를 최대한 줄여라.
자료 사본을 사용하라
스레드는 가능한 독립적으로 구현하라. 자신만의 세상에 존재하는 것처럼..
라이브러리를 이해하라
언어가 제공하는 클래스를 검토하라. 다음을 꼭 검토해볼 것
java.util.concurrent, java.util.concurrent.atomic, java.util.concurrent.locks
실행 모델을 이해하라
생산자-소비자, 읽기-쓰기, 식사하는 철학자들
동기화하는 메서드 사이에 존재하는 의존성을 이해하라
공유 객체 하나에는 메서드 하나만 사용하라.
동기화 하는 부분을 작게 만들어라
코드를 짤때 임계영역(critical section) 수를 최대한 줄일것.
하나의 임계영역에 코드를 몰아넣으라는 의미가 아니다.
올바른 종료 코드는 구현하기 어렵다.
가장 흔히 발생하는 문제가 데드락이다.
종료 코드를 개발 초기부터 고민하고 구현하라. 생각보다 어렵고 오래 걸린다. 이미 나온 알고리즘을 검토할것
스레드 코드 테스트 하기
충분한 테스트로 위험을 낮춘다.
문제를 노출하는 테스트 케이스를 작성하라.
프로그램 설정과 시스템 설정, 부하를 바꿔가며 자주 돌려라.
테스트가 실패하면 원인을 추적하라. 다시 돌려서 통과하더라도 넘어가면 안된다.
말이 안되는 실패는 잠정적인 스레드 문제로 취급하라.
=> 시스템 실패를 일회성이라고 무시하지마라.
다중 스레드를 고려하지 않은 순차 코드부터 제대로 돌게 만들자
=> 스레드 환경 밖에서 코드가 제대로 동작하는지 반드시 확인할것
=> 스레드 환경 밖에서 생기는 버그와 스레드 환경에서 생기는 버그를 동시에 디버깅하지 마라. 일단 스레드 환경 밖에서 코드를 올바로 돌릴것
다중 스레드를 쓰는 코드를 다양한 설정으로 실행하기 쉽게 구현하라
=> 한 스레드로 실행하거나, 여러 스레드로 실행하거나, 실행 중 스레드 수를 바꿔본다.
=> 스레드 코드를 실제 환경이나 테스트 환경에서 돌려본다.
=> 테스트 코드를 빨리, 천천히, 다양한 속도로 돌려본다.
=> 다양한 설정에서 실행할 목적으로 다른 환경에 쉽게 끼워 넣을 수 있게 구현한다.
다중 스레드를 쓰는 코드 부분을 상황에 맞게 조율할 수 있게 작성하라
=> 스레드 갯수를 조정하기 쉽게 한다던가..
프로세서 수보다 많은 스레드를 돌려보라
다른 플랫폼에서 돌려보라
코드에 보조코드를 넣어 돌려라. 강제로 실패를 일으키게 해보라
=> wait(), sleep(), yield(), priority() 등과 같은 메서드를 추가해 코드를 다양한 순서로 실행한다.
결론
- SRP를 준수한다.
- POJO를 사용해 스레드를 아는 코드와 모르는 코드로 분리한다.
- 스레드 코드를 테스트 할때는 전적으로 스레드만 테스트한다. 스레드 코드는 최대한 집약되고 작아야 한다.
- 동시성 오류를 일으키는 잠정적인 원인을 철저히 이해한다.
- 사용하는 라이브러리와 기본 알고리즘을 이해한다.
- 스레드 코드는 많은 플랫폼에서 많은 설정으로 반복해서 계속 테스트해야 한다.
'스터디 > Clean Code' 카테고리의 다른 글
17장. 냄새와 휴리스틱 (0) | 2016.12.12 |
---|---|
14장. 점진적인 개선 (0) | 2015.12.14 |
12장. 창발성 (0) | 2015.09.06 |
11장. 시스템 (0) | 2015.09.06 |
10장. 클래스 (0) | 2015.08.09 |