백엔드 개발 시 멀티쓰레드 관련 처리는 어떤식으로들 적용시키나요?

Question

갑자기 문득 이런 생각이 듭니다.실무에서 아직 멀티쓰레딩 처리해본 적이 없습니다.단순히 이론적인 측면에서만 공부했고, 실습용 코드 만들어본 게 끝인데실제로 실무에서 개발할 때 동기화 처리를 어떤식으로 적용시키는지가 궁금합니다.예를 들어 스프링의 경우 해당 url 요청은 공유자원을 사용할 경우 경쟁상태가 발생될 가능성이 있다 판단하에 적용시키고,테스트해본 후에도 이상이 있으면 적용시킬 거 같은데그 공유자원이라는 게 예시가 마땅히 생각나지 않지만 조회수라던지 이런 중요한 정보는 아닐 경우에는 좀 lost update가 되어도 괜찮지 않나 싶기도 해서요실무에서 보통 어떻게 적용/테스트/활용 하시나요?

짱구올시다 · Answer

멀티스레딩 처리를 해본 적이 없다.스프링은 기본으로 멀티 스레드 모델을 택했기 때문에 모르실 뿐 알게 모르게 사용하고 계십니다. 스프링에서 request-per-threads 모델이 대표적이죠. 요청당 스레드를 사용하기 때문에 멀티 스레드 모델입니다.그럼 큰 문제가 있던 적은 없던거 같은데? => 그 이유는 보통 스프링 빈을 무상태성을 기반으로 설계하도록 권장하고 그에 따르셨기 때문일겁니다.혹은 데이터베이스 데이터를 접근하나 충돌이 날 정도로 트래픽이 과도하게 발생한 적은 없으셨을겁니다.공유 자원에 대한 처리는 많은 경우에 상태성을 가지는 RDB(관계형 데이터베이스) 특정 row를 동시에 참조하는 경우에 많이 발생하는데요. 이 경우 데이터베이스 락(낙관적 락, 비관적 락) 등을 사용합니다.말씀하신 예시처럼 애플리케이션 레벨에서 변수의 상태를 여러 스레드가 접근하는 경우엔 애플리케이션 레벨에서의 락을 고려합니다만... 이 경우 성능이 좋지 못하기 때문에 주로 사용하지 않습니다. (데이터베이스 락도 같음)병렬 처리와 같은 예시에서도 멀티 스레드를 사용하기 때문에 결국 비슷한 문제가 생길 수 있는데, 이 경우엔 연산간 충돌이 발생하지 않도록 하는 것이 원칙입니다.마지막으로 정리하면 결국 공유 데이터에 대한 충돌을 방지하는 방법은 결국 아래와 같습니다.그냥 충돌날 일을 만들지 마라락을 고려한다1번은 공유 자원에 대한 접근을 하지 않도록 하거나, 혹은 메시지 큐 같은 곳에다가 다 때려넣고 순차 처리를 하는 식으로 해서 충돌을 해소하는 방법이 존재합니다.

바나나오백원2 · Answer

synchronized

kenu,전독시 · Answer

그런 트래픽 서비스 당해보면경험있는 멤버가 있어서,바로 답이 나옵니다.

백엔드 개발 시 멀티쓰레드 관련 처리는 어떤식으로들 적용시키나요?

3개의 답변

Q&A 목록