Thread Pool, Monitor, Fork-Join

[JoisFe]

Thread Pool, Monitor, Fork-Join에 대해 설명해 주세요.

• Thread Pool, Monitor, Fork-Join
  • Thread Pool을 사용한다고 가정하면, 어떤 기준으로 스레드의 수를 결정할 것인가요?
  • 어떤 데이터를 정렬 하려고 합니다. 어떤 방식의 전략을 사용하는 것이 가장 안전하면서도 좋은 성능을 낼 수 있을까요?

[JoisFe]

Thread Pool

• 미리 일정 갯수의 thread를 생성하여 관리하는 방법
• thread를 생성하고 소멸하는 단계에는 매우 많은 비용이 듭니다.
• thread를 미리 생성해두고 thread가 필요할 때 pool에 있는 thread를 할당하고, 사용이 완료되더라도 바로 소멸시키지 않고 pool에 저장하여 다시 필요할 때 사용하도록 하면 매우 효율적입니다.
• 또한 thread 수를 제한하기 때문에 너무 많은 thread를 생성하지 않게하여 리소스 부족을 막고, context switching 횟수를 줄여 비용을 줄일 수 있습니다.
• 물론 너무 많이 스레드를 만들어 두면 처음 스레드 풀 생성시에 너무 많은 시간이 소요되며, 필요없는 메모리를 낭비하게 됩니다.

Thread Pool 사용한다고 가정하면 어떤 기준으로 스레드의 수를 결정할 것인가요?

• 참고 자료 1
  • 스레드 풀 적정 크기 공식
• 위와 같은 공식 ? 이론? 을 참고하되 현재 서비스하고 있는 애플리케이션의 현재 상황에 적합한 수치를 APM 등을 활용한 테스트로 정하는 것이 좋지 않을까 생각합니다.

Critical Section (임계구역)

• 스레드가 동시에 접근해서는 안되는 공유 자원을 접근하는 코드 블록
• 멀티 프로세스 혹은 멀티 스레드가 공유 자원에 접근할 때 결과가 달라질 수 있는 코드 영역

Critical Section 문제 해결 조건

1. Mutual Exclusion (상호 배제)

• 임계 구역에는 하나의 프로세스만 접근 가능!

2. Bounded Waiting (한정 대기)

• 임계구역에 접근하는데 무한 대기 하면 안됨! (언젠가는 접근 가능해야함)

3. Progress (진행 or 융통성)

• 어떤 프로세스가 Critical Section 을 사용하지 않으면 Critical Section 외부 다른 어떤 프로세스도 들어갈 수 없음
• 즉 어떤 프로세스가 다른 프로세스 진행 방해하면 안됨

Monitor

• Critical Section 을 해결하기 위한 방법 중 하나 (뮤텍스, 세마 포어, 모니터)
• 멀티 스레드 or 멀티 프로세스가 공유자원에 접근할 떄 문제가 되는 Critical Section이 있을 수 있습니다.
• 이때 공유 자원을 숨기고 해당 접근에 대해 인터페이스만 제공한다면 각 프로세스 or 스레드가 공유 자원에 접근할때 이후 문제를 막을 수 있습니다.

• 모니터 : 모니터 큐에 있는 작업을 순서대로 하나씩 처리 (큐 : FIFO)
• 순서대로 하나씩 처리하므로 공유 자원을 동시에 접근하는 문제가 발생하지 않음!

Fork Join

• �fork() : 작업를 여러 개로 나누어서 새롭게 생성하는 것 입니다.
• join() : fork 결과로 나뉘었던 작업을 합치는 것 입니다.
• 작업을 나누어 처리하여 결과를 합치는 것으로 작업을 나누면 각 작업을 별도의 스레드 or 프로세스에서 병렬적으로 처리할 수 있습니다.

[JoisFe]

• JDK version 7 부터 나온 Fork Join과 유사한?

[JoisFe]

Monitor --> 자바의 synchronized
@Tokwasp 님!!
== 설명 == 부탁드립니다 ㅠㅠ

[Tokwasp]

[ 모니터 ]
세마포어를 편리하게 사용하기 위한 인터페이스를 모니터라고 부릅니다.
synchronized는 객체의 모니터를 획득 할수 있으며 모니터를 획득한 스레드만이 임계영역에 접근이 가능 합니다.
또한 소비자 생산자 문제를 해결 하는 방법도 구현 되어 있습니다.