TIL (Today I Learned)
2022.05.26
오늘 읽은 범위
- 동시성
📖 책에서 기억하고 싶은 내용을 써보세요.
-
동시성과 깔끔한 코드는 양립하기 어렵다.
다중 스레드는 시스템이 부하를 받기 전까지 멀쩡하게 돌아간다. -
동시성이 필요한 이유?
동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇(what)과 언제(when)를 분리한다. -
웹 컨테이너가 제공하는 결합분리(decoupling )전략은 완벽과 거리가 아주 멀다.
So, 서블릿 프로그래머는 동시성을 정확히 구현하도록 각별한 주의와 노력 요구.
But, 그럼에도 서블릿 모델이 제공하는 구조적 이점은 아주 크다. -
대량으로 분석하는 시스템, 모든 정보를 처리한 후에 최종적인 답을 냄.
→ 정보를 병렬로 처리하면 시스템 반응 시간 빨라짐.-
ex 1 ) 웹 사이트에서 정보를 가져와 요약하는 정보 수집기
매일 실행하므로 24시간 안에 끝나야 함. 웹 사이트를 계속 추가할 수록 정보 수집하는 시간도 늘어남.
→ 단일 스레드 수집기는 웹 소켓에서 입출력을 기다리는 시간이 아주 많다. 한 번에 한 사이트를 방문하는 대신 다중 스레드 알고리즘을 이용하면 수집기 성능을 높일 수 있다. -
ex 2 ) 한 번에 한 사용자를 처리하는 시스템
1user / 1sec → 사용자 수가 늘어날수록 시스템이 응답하는 속도도 늦어짐.
⇒ 많은 사용자를 동시에 처리하면 시스템 응답 시간을 높일 수 있다.
-
-
동시성 미신과 오해
-
동시성은 항상 성능을 높여준다. (X)
때로 성능을 높여준다. (O)
→ 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우에만 성능이 높아진다. -
동시성을 구현해도 설계는 변하지 않는다. (X)
무엇과 언제를 분리하면 시스템 구조가 크게 달라진다. (O)
→ 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다 -
웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. (X)
→ 실 컨테이너 동작과 문제 해결방법을 이해해야 한다. (동시수정 해결법, 데드락 등) -
동시성은 다소 부하를 유발한다.
-
동시성은 복잡하다.
-
동시성은 버그를 제현하기 어렵다.
(→ 일회성 문제로 여겨 무시하기 쉽다.) -
동시성을 구현하려면 흔히 근본적인 설계 전략을 재고해야 한다.
-
-
동시성 방어 원칙
-
단일 책임 원칙Single Responsibility Principle, SRP
: 동시성 코드는 독자적인 개발, 변경, 조율 주기가 있음. → 동시성 코드와 다른 코드는 분리. -
따름 정리corollary:
a. 자료 범위를 제한하라.
: 자료를 캡슐화(encapsulation ) & 공유 자료를 최대한 줄이기.b. 자료 사본을 사용하라
: 공유 객체를 피하는 방법 → 코드가 문제를 일으킬 가능성도 낮아짐.
(ex.객체를 복사해 읽기 전용으로 사용.)
if, 복사하는 시간과 부하가 걱정 → 진짜 문제인지 실측 필요.
but, 내부 잠금을 없애 절약한 수행 시간이 사본 생성과 가비지 컬렉션에 드는 부하를 상쇄할 가능성이 크다.
-
스레드는 가능한 독립적으로 구현하라
: 독자적인 스레드로, 가능하면 다른 프로세서에서, 돌려도 괜찮도록 자료를 독립적인 단위로 분할.
-
라이브러리를 이해하라
-
-
실행 모델을 이해하라
- 생산자-소비자 (Producer-Consumer)
: 하나 이상 생산자 스레드가 정보를 생성해 버퍼buffer나 대기열queue에 넣는다. 하나 이상 소비자 스레드가 대기열에서 정보를 가져와 사용.- 대기열 = 한정된 자원
- 읽기-쓰기 (Readers-Writers)
:읽기 스레드를 위한 주된 정보원으로 공유 자원을 사용, 쓰기 스레드가 공유 자원을 이따금 갱신.- 처리율(throughput)이 문제의 핵심
- 처리율을 강조하면 → 기아starvation 현상 / 오래된 정보가 쌓인다.
갱신을 허용하면 → 처리율에 영향을 미친다
- 생산자-소비자 (Producer-Consumer)
-
동기화하는 부분을 최대한 작게 만들어라
: synchronized를 사용하면 락을 설정한다. 같은 락으로 감싼 모든 코드 영역은 한 번에 한 스레드만 실행이 가능하다.- 락은 스레드를 지연시키고 부하를 가중시킨다.
- synchronized를 남발하는 코드는 바람직하지 않다.
- 임계영역은 반드시 보호. So, 임계영역 수 최소화.
- 주의_ 하나의 거대한 임계 영역으로 통합하면 안됨.
→ 이 영역을 사용하려고 하는 스레드도 늘어남. → 경쟁으로 이어지고 → 성능이 떨어지기 때문이다. (p. 236)
- 주의_ 하나의 거대한 임계 영역으로 통합하면 안됨.
-
스레드 코드 테스트 하기
- 문제를 노출하는 테스트 케이스 작성. (프로그램 설정, 시스템 설정, 부하 바꿔가며 자주 돌려라)
- 랜덤한 상황을 넣고 주기적으로 테스트를 진행해라. 스레드 코드는 다시 테스트 할 때는 성공하는 경우가 있을 수 있다. 그렇다고 해서 넘어가지 말고 원인을 꼼꼼히 파악하길 바란다.
- 시스템 실패를 ‘일회성’이라 치부하지 마라.
- 일회성 문제란 존재하지 않는다고 가정하는 편이 안전하다. ‘일회성’ 문제를 계속 무시한다면 잘못된 코드 위에 코드가 계속 쌓인다.
결론
다중 스레드 코드를 작성시, 주의하지 않으면 알 수 없는 오류에 직면할 수 있다.
SRP 준수: 스레드를 아는 코드와 스레드를 모르는 코드를 분리.
- 테스트 할 때 스레드 코드를 테스트 할 때에는 스레드만 테스트한다.
- 즉 스레드 코드는 최대한 집약되고 작아야 한다.
동시성 오류를 일으키는 잠정적인 원인을 철저히 이해해야 한다.
- 여러 스레드가 공유 자료를 조작하거나 자원 풀을 공유할 때 동시성 오류가 발생한다.
- 루프 반복을 끝내거나 프로그램을 깔끔하게 종료하는 등 경계 조건의 경우 더 까다로우므로 특히 주의해야 한다.
사용하는 라이브러리와 기본 알고리즘을 이해한다.
- 특정 라이브러리 기능이 기본 알고리즘과 유사한 어떤 문제를 어떻게 해결하는지 파악한다.
보호할 코드 영역을 찾아내는 방법과 특정 코드 영역을 잠그는 방법을 이해한다. 또 공유하는 정보와 공유하지 않는 정보를 정확하게 이해한다.
- 잠글 필요가 없는 코드는 잠그지 않는다.
- 잠긴 영역에서 다른 잠긴 영역을 호출하지 않는다.
- 공유하는 객체 수와 버위를 최대한 줄인다.
- 클라이언트에게 공유 상태를 관리하는 책임을 떠넘기지 않는다.
공유하는 정보: 공유하는 객체 수와 범위를 최대한 줄인다.
일회성 문제는 대개 시스템에 부하가 걸릴 때나 아니면 뜬금없이 발생한다. 그러므로 스레드 코드는 많은 플랫폼에서 많은 설정으로 반복해서 계속 테스트해야 한다.
🐱👓 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요.
- 안드로이드 블루투스 페어링 관련해서 작업하면서 java 스레드로 애먹었던 기억이 있어, 책에서 복잡한 거라고 말해줘서 고마웠다.. (나만 힘든게 아니었어-!)
- 이번에도 이해하려고 애썼지만 조금 어려웠다. 그래도 최대한 안드로이드 플젝 할 때의 기억과 js 상황(맞는진 모르겠지만 유사하다고 생각한 비동기 처리)에 대입해 보고자 하며 읽어보았다.
- 기능 구현하는 것도 어려운데.. ㅋㅋ 테스트코드 워후-! 할수있어...!
(feat.동기화 단위를 최소화하라. 그러면 조금 낫다.)
- starvation, 페어링 구현하면서 경험해본적 있었다.. 개념에 대한 용어를 알고 생각해보니 생산자-소비자 모델이었는데, 생산자에서 오류가 발생하면 스레드 종료 처리를 해주지 못해 오류가 발생하는 상황이었다. 검색도 하고 선배 개발자 분에게 조언을 얻어 해결하긴 했었는데, 이번에 책을 읽으면서 다시 곱씹어 보니 당시 상황을 복기해보니 좀 더 이해가는 부분이 있었다.
🧐 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
- ‘서블릿Servlet’ 모델
- 서블릿: 웹 혹은 EJB 컨테이너라는 우산 아래서 돌아가는데, 이들 컨테이너는 동시성을 부분적으로 관리. 웹 요청이 들어올 때마다 웹 서버는 비동기식으로 서블릿을 실행함.
- 결합분리(decoupling )전략
- EJB 컨테이너
- 데드락 : 여러 스레드가 서로가 끝나기를 기다린다. 모든 스레드가 각기 필요한 자원을 다른 스레드가 점유하는 바람에 어느 쪽도 더 이상 진행하지 못함.
- JIT (Just In Time) 컴파일러
