13장 동시성

[su-pernova]

동시성이 필요한 이유와 주의해야 할 점

[su-pernova]

저는 아직 다중 스레드 프로그램을 직접 짜본 적도, 이렇다 할 만한 동시성 문제를 마주친 적도 없지만
(기껏해야 @Transactional 쓰기?) 회사 문서를 뒤져보니 부하 테스트 과정에서 상당히 자주 발견되는 것 같더라구요.
(매번 수행 결과값이 다른 경우, 로직 상 문제가 없는데 엉뚱한 결과가 만들어지는 경우 등)

추후 필요한 상황이 왔을 때 이 장에서 배운 내용들을 요긴하게 사용할 수 있을 것 같습니다.
동시성은 어려운 개념이지만 책에서 복잡한 코드 대신 가벼운 개념 위주로 다뤄 주어서 좋았습니다! 🙌

[YHLEE9753]

• 무엇과 언제를 분리하라 즉 비즈니스 로직은 POJO로 구현하고 동시성 설정은 따로 관리하자
• 동시성 관련 문제는 DB 딴으로 최대한 미뤄서 처리하는 것도 하나의 방법이다
• 응답시간과 작업처리량개선을 목표로 동시성을 활요할때는 결국 트레이드오프가 발생한다
• 조회를 우선시 할것인지 변경을 우선시 할것인지 트레이드 오프의 기준은 상황마다 다르다
• 이런 부분들은 동시성 개념을 바탕으로 DB 격리수준과 다양한 기술을 활용하면 좋을 거 같다.
• 철학자들은 서로 밥좀 먹여주면 좋을거같다.

[ynoolee]

OS 복습하는 기분 이었네요 ㅎㅎ

불변 객체를 사용하면 동시성 문제를 피할 수 있다는 말을 볼 때 면 이런 고민을 했었습니다

불변 객체라는 것은 상태를 업데이트 하기 위해 매 번 새로운 객체를 생성해야하네 ? 그럼 오히려 객체 생성 비용과, 수많은 쓰레기 객체들이 생기니 GC 비용이 더 드는 거 아닌가?

책에서는 이런식으로 '객체를 복사하는 시간과 부하에 대한 걱정' 이 든다면, '복사 비용이 실제로 문제가 되는지 실측' 할 것을 권하고 있습니다. 공유 객체를 사용함 으로서 생길 경쟁 상황을 해결하기 위해 내부 잠금을 사용하며 생기는 부하 보다는, 복사 객체 생성과 이로 인한 GC 로 드는 부하가 더 나을 수도 있다는 내용을 말하고 있었습니다.
개발 에서는 무조건 적인 해답은 없고 정말 상황에 따라 다르기 때문에 , 다양한 방법들을 항상 알고 있는 것이 중요한 것 같다는 �생각이 다시 한 번 들었습니다.