Unit 6.1 — 생산자-소비자 문제
F-LAB JAVA · 4주차 · Phase 6 · 스레드 간 협력
🚀 Phase 6 시작 — 스레드 협력 진입
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- 생산자-소비자 문제 (Producer-Consumer) 의 정의는?
- 생산자와 소비자의 역할 은?
- 버퍼 (큐) 가 꽉 차거나 비었을 때 의 처리는?
- 실제 사례 (MQ, 로깅, 작업 큐) 는?
- 일반 락만으로 처리하는 방법 의 한계는?
- 바쁜 대기 (Busy Waiting) 의 문제는?
- 이 문제가 멀티스레드의 핵심 문제 인 이유는?
- BlockingQueue 가 해결책인 이유는?
- wait/notify 가 필요한 이유는?
🎯 핵심 한 문장
생산자-소비자 문제 (Producer-Consumer Problem) 는 데이터를 생성하는 생산자 스레드와 소비하는 소비자 스레드가 공유 버퍼 (큐) 를 통해 협력하는 고전적인 동시성 문제다.
생산자 는 데이터를 버퍼에 넣고 (produce), 소비자 는 버퍼에서 꺼내 처리한다 (consume) — 둘은 서로의 속도를 모른 채 버퍼를 매개로 느슨하게 연결된다.
핵심 제약은 버퍼가 꽉 차면 생산자가 대기 (넣을 공간 없음), 버퍼가 비면 소비자가 대기 (꺼낼 것 없음) 해야 한다는 점이며, 이 대기·통지를 어떻게 구현하느냐가 문제의 본질이다.
실제 사례로 메시지 큐 (Kafka, RabbitMQ), 비동기 로깅, 작업 큐 (스레드 풀의 task queue) 등이 있다.
일반 락 (synchronized) 만으로는 "버퍼 빌 때까지 반복 확인" 하는 바쁜 대기 (busy waiting) 가 되어 CPU 를 낭비하므로, 효율적 대기·통지를 위해 wait/notify (다음 Unit) 또는 BlockingQueue 가 필요하다.
비유 — 빵집 진열대
생산자-소비자 = 빵집:
생산자 (제빵사):
- 빵을 만들어 진열대에 놓음
- 진열대 가득 차면 → 대기 (놓을 곳 없음)
소비자 (손님):
- 진열대에서 빵을 가져감
- 진열대 비면 → 대기 (가져갈 빵 없음)
버퍼 (진열대):
- 빵을 임시 보관
- 생산/소비 속도 차이 흡수
협력:
- 제빵사와 손님은 서로 속도 모름
- 진열대로 느슨하게 연결
- 진열대 차면 제빵사 쉼
- 진열대 비면 손님 기다림
나쁜 방법 (바쁜 대기):
- 손님이 "빵 있나?" 1초에 1000번 확인
- 에너지 낭비
좋은 방법 (wait/notify):
- 손님은 자고 (wait)
- 빵 나오면 제빵사가 깨움 (notify)→ 생산자-소비자 = 버퍼 매개 협력, 차면/비면 대기, 효율적 통지 필요.
🧭 9개 섹션 로드맵
1. 생산자-소비자 문제의 정의
2. 생산자와 소비자의 역할
3. 버퍼가 꽉 차거나 빌 때
4. 실제 사례
5. 일반 락만으로 처리
6. 바쁜 대기의 문제
7. 멀티스레드 핵심 문제인 이유
8. BlockingQueue 해결책
9. 면접 + 자기 점검1️⃣ 생산자-소비자 문제의 정의
1.1 문제 정의
생산자-소비자 문제:
데이터를 생성하는 생산자와
소비하는 소비자가
공유 버퍼를 통해 협력하는 문제.
구성:
- 생산자 (Producer)
- 소비자 (Consumer)
- 버퍼 (Buffer/Queue)1.2 기본 구조
생산자-소비자 구조:
생산자 ──put──→ [버퍼] ──take──→ 소비자
(큐)
- 생산자: 데이터 생성 → 버퍼
- 소비자: 버퍼 → 데이터 처리
- 버퍼: 중간 저장소1.3 느슨한 결합
느슨한 결합 (Decoupling):
생산자와 소비자가 직접 X.
버퍼를 매개로 연결.
효과:
- 속도 차이 흡수
- 독립적 동작
- 확장성 (생산자/소비자 수 조절)1.4 코드 (개념)
// 생산자-소비자 (개념)
public class ProducerConsumer {
private final Queue<Task> buffer = new LinkedList<>();
private final int capacity = 10;
// 생산자
public void produce(Task task) {
// 버퍼에 추가
buffer.offer(task);
}
// 소비자
public Task consume() {
// 버퍼에서 꺼냄
return buffer.poll();
}
// 동기화 필요 (다음 섹션)
}1.5 ILIC 의 맥락
@Service
public class ShipmentProcessingPipeline {
// 생산자: 주문 → 처리 큐
// 소비자: 처리 큐 → 실제 처리
private final Queue<Shipment> processingQueue = new LinkedList<>();
// 생산자 (주문 접수)
public void submitForProcessing(Shipment shipment) {
processingQueue.offer(shipment); // 큐에 추가
// 동기화 필요
}
// 소비자 (백그라운드 처리)
public Shipment takeForProcessing() {
return processingQueue.poll(); // 큐에서 꺼냄
}
// 생산 (주문) 과 소비 (처리) 가 느슨하게 연결
// 큐로 속도 차이 흡수
}1.6 자기 점검 답변
생산자-소비자 문제의 정의는?
답:
1. 정의:
- 생산자 + 소비자 + 버퍼
- 협력 문제
-
구조:
- 생산자 → 버퍼 → 소비자
-
느슨한 결합:
- 버퍼 매개
- 속도 차이 흡수
-
효과:
- 독립 동작
- 확장성
2️⃣ 생산자와 소비자의 역할
2.1 생산자
생산자 (Producer):
데이터를 생성하여 버퍼에 넣음.
동작:
1. 데이터 생성
2. 버퍼에 추가 (put/offer)
3. (버퍼 가득 차면 대기)
예:
- 주문 접수
- 로그 생성
- 이벤트 발생2.2 소비자
소비자 (Consumer):
버퍼에서 데이터를 꺼내 처리.
동작:
1. 버퍼에서 꺼냄 (take/poll)
2. 데이터 처리
3. (버퍼 비면 대기)
예:
- 주문 처리
- 로그 기록
- 이벤트 핸들링2.3 여러 생산자/소비자
N 생산자 - M 소비자:
- 여러 생산자가 동시 생성
- 여러 소비자가 동시 처리
- 버퍼는 공유
장점:
- 병렬 처리
- 부하 분산
- 확장성
도전:
- 버퍼 동기화 (경쟁)2.4 시각화
N-M 생산자-소비자:
생산자1 ─┐
생산자2 ─┼─put──→ [버퍼] ──take─┬─→ 소비자1
생산자3 ─┘ ├─→ 소비자2
└─→ 소비자3
버퍼 동기화 필요 (여러 접근)2.5 속도 불균형
속도 불균형:
생산 > 소비:
- 버퍼 점점 참
- 생산자 대기 증가
- 소비자 증설 필요
생산 < 소비:
- 버퍼 점점 빔
- 소비자 대기 증가
- 생산자 증설 또는 소비자 감소
버퍼:
- 일시적 불균형 흡수2.6 ILIC 의 맥락
@Service
public class ShipmentProducerConsumer {
private final BlockingQueue<Shipment> queue = new LinkedBlockingQueue<>(100);
// 생산자 (여러 API 핸들러)
public void produce(Shipment shipment) throws InterruptedException {
queue.put(shipment); // 큐 가득 차면 대기
log.info("생산: {}", shipment.getId());
}
// 소비자 (여러 워커 스레드)
public void startConsumers(int count) {
for (int i = 0; i < count; i++) {
Thread consumer = new Thread(() -> {
while (!Thread.currentThread().isInterrupted()) {
try {
Shipment shipment = queue.take(); // 비면 대기
process(shipment);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}, "consumer-" + i);
consumer.start();
}
}
private void process(Shipment s) { }
}2.7 자기 점검 답변
생산자와 소비자의 역할은?
답:
1. 생산자:
- 데이터 생성
- 버퍼에 추가
- 차면 대기
-
소비자:
- 버퍼에서 꺼냄
- 처리
- 비면 대기
-
N-M:
- 여러 생산자/소비자
- 병렬, 확장
-
속도 불균형:
- 버퍼가 흡수
3️⃣ 버퍼가 꽉 차거나 빌 때
3.1 두 가지 경계 조건
버퍼 경계 조건:
1. 버퍼 가득 참 (Full):
- 생산자가 넣을 수 없음
- → 생산자 대기
2. 버퍼 빔 (Empty):
- 소비자가 꺼낼 수 없음
- → 소비자 대기3.2 버퍼 가득 참
버퍼 가득 참:
생산자:
- 버퍼 크기 한계 (예: 100)
- 가득 차면 더 못 넣음
처리:
- 생산자 대기 (소비자가 비울 때까지)
- 또는 버린다 (drop)
- 또는 블록3.3 버퍼 빔
버퍼 빔:
소비자:
- 꺼낼 데이터 없음
처리:
- 소비자 대기 (생산자가 채울 때까지)
- 또는 null 반환
- 또는 블록3.4 대기와 통지
대기와 통지:
생산자가 채움:
→ 소비자에게 통지 ("데이터 있어!")
→ 대기 중 소비자 깨움
소비자가 비움:
→ 생산자에게 통지 ("공간 있어!")
→ 대기 중 생산자 깨움
핵심:
- 조건 충족 시 통지
- 효율적 협력3.5 시각화
버퍼 경계:
가득 참:
생산자: [대기 (공간 없음)]
소비자: 꺼냄 → 공간 생김 → 생산자 깨움
빔:
소비자: [대기 (데이터 없음)]
생산자: 넣음 → 데이터 생김 → 소비자 깨움3.6 ILIC 의 맥락
@Service
public class BufferBoundaryExample {
// 유한 버퍼 (크기 100)
private final BlockingQueue<Shipment> queue = new ArrayBlockingQueue<>(100);
// 생산자 — 가득 차면 대기
public void produce(Shipment shipment) throws InterruptedException {
queue.put(shipment); // 가득 차면 자동 대기
// 소비자가 비우면 자동 진행
}
// 소비자 — 비면 대기
public Shipment consume() throws InterruptedException {
return queue.take(); // 비면 자동 대기
// 생산자가 채우면 자동 진행
}
// 비대기 버전 (offer/poll)
public boolean tryProduce(Shipment shipment) {
return queue.offer(shipment); // 가득 차면 false (대기 X)
}
public Shipment tryConsume() {
return queue.poll(); // 비면 null (대기 X)
}
}3.7 자기 점검 답변
버퍼가 꽉 차거나 빌 때의 처리는?
답:
1. 가득 참:
- 생산자 대기
- (또는 drop/블록)
-
빔:
- 소비자 대기
- (또는 null)
-
통지:
- 채우면 소비자 깨움
- 비우면 생산자 깨움
-
효율:
- 조건 시 통지
4️⃣ 실제 사례
4.1 메시지 큐
메시지 큐 (Message Queue):
Kafka, RabbitMQ, SQS 등.
생산자:
- 메시지 발행 (publish)
소비자:
- 메시지 구독/소비 (subscribe/consume)
큐:
- 메시지 저장
- 비동기 통신4.2 비동기 로깅
비동기 로깅:
Logback AsyncAppender 등.
생산자 (앱 스레드):
- 로그 이벤트 생성
- 큐에 추가 (빠름)
소비자 (로깅 스레드):
- 큐에서 꺼냄
- 파일/DB 기록 (느림)
효과:
- 앱 스레드 블록 X
- 로깅 비동기4.3 작업 큐 (스레드 풀)
작업 큐 (Thread Pool):
ExecutorService 의 내부.
생산자 (submit):
- 작업 제출
- 작업 큐에 추가
소비자 (워커 스레드):
- 큐에서 작업 꺼냄
- 실행
→ 스레드 풀의 핵심 (Phase 7)4.4 기타 사례
기타 사례:
- 이벤트 루프 (이벤트 큐)
- 배치 처리 (입력 큐)
- 스트림 처리
- 다운로드 매니저 (작업 큐)
- 프린터 스풀러4.5 공통 패턴
공통 패턴:
생산 속도 ≠ 소비 속도:
- 버퍼로 흡수
비동기:
- 생산자 블록 X
- 소비자 독립
확장:
- 소비자 증설 (병렬)4.6 ILIC 의 맥락
@Service
public class ShipmentRealWorldExamples {
// 1. 비동기 알림 (메시지 큐 패턴)
private final BlockingQueue<Notification> notificationQueue =
new LinkedBlockingQueue<>();
public void sendNotificationAsync(Notification notification) throws InterruptedException {
notificationQueue.put(notification); // 생산 (빠름)
// 별도 스레드가 소비 (실제 발송, 느림)
}
// 2. 비동기 로깅 (감사 로그)
private final BlockingQueue<AuditLog> auditQueue = new LinkedBlockingQueue<>();
public void logAudit(AuditLog log) {
auditQueue.offer(log); // 비동기 (앱 블록 X)
}
// 3. 작업 큐 (배송 처리)
private final ExecutorService processingPool =
Executors.newFixedThreadPool(4); // 내부 작업 큐
public void processShipment(Shipment shipment) {
processingPool.submit(() -> doProcess(shipment)); // 생산
// 워커 스레드가 소비 (Phase 7)
}
private void doProcess(Shipment s) { }
record Notification(String to, String message) {}
record AuditLog(String action, long timestamp) {}
}4.7 자기 점검 답변
실제 사례는?
답:
1. 메시지 큐:
- Kafka, RabbitMQ
- publish/consume
-
비동기 로깅:
- AsyncAppender
- 앱 블록 X
-
작업 큐:
- 스레드 풀
- submit/워커
-
공통:
- 속도 차이 흡수
- 비동기, 확장
5️⃣ 일반 락만으로 처리
5.1 synchronized 만으로
// 일반 락만으로 (한계 있음)
public class SimpleBuffer {
private final Queue<Task> buffer = new LinkedList<>();
private final int capacity = 10;
private final Object lock = new Object();
public void produce(Task task) {
synchronized (lock) {
while (buffer.size() >= capacity) {
// 가득 참 → 어떻게 대기?
// 그냥 반복? (바쁜 대기)
}
buffer.offer(task);
}
}
public Task consume() {
synchronized (lock) {
while (buffer.isEmpty()) {
// 빔 → 어떻게 대기?
}
return buffer.poll();
}
}
}5.2 문제 1 — 바쁜 대기
// ❌ 바쁜 대기 (busy waiting)
public Task consume() {
while (true) {
synchronized (lock) {
if (!buffer.isEmpty()) {
return buffer.poll();
}
}
// 비어있으면 반복 확인 (CPU 낭비)
}
}
// 계속 확인 → CPU 100%5.3 문제 2 — 데드락
// ❌ 락 안에서 무한 루프 (데드락)
public Task consumeBroken() {
synchronized (lock) {
while (buffer.isEmpty()) {
// 락 잡은 채 대기
// → 생산자가 락 못 얻음
// → 영원히 빔 (데드락)
}
return buffer.poll();
}
}
// 락 잡고 대기 → 생산자 진입 불가5.4 sleep 으로 완화 (여전히 한계)
// sleep 으로 바쁜 대기 완화 (불완전)
public Task consumeWithSleep() throws InterruptedException {
while (true) {
synchronized (lock) {
if (!buffer.isEmpty()) {
return buffer.poll();
}
}
Thread.sleep(10); // 잠시 대기 (CPU 절약)
// 하지만:
// - 지연 (10ms)
// - 여전히 폴링
// - 효율 X
}
}5.5 근본 해결 필요
일반 락의 한계:
- 바쁜 대기 (CPU 낭비)
- 또는 sleep (지연, 폴링)
- 락 안 대기 (데드락)
근본 해결:
- wait/notify (다음 Unit)
- 락 반납 + 대기
- 통지로 깨움
- BlockingQueue
- 이미 구현됨5.6 ILIC 의 맥락
@Service
public class LockOnlyLimitation {
private final Queue<Shipment> buffer = new LinkedList<>();
private final int capacity = 100;
private final Object lock = new Object();
// ❌ 바쁜 대기 (CPU 낭비)
public Shipment consumeBusy() {
while (true) {
synchronized (lock) {
if (!buffer.isEmpty()) {
return buffer.poll();
}
}
// 비어있으면 계속 반복 (CPU 100%)
}
}
// △ sleep (완화, 여전히 폴링)
public Shipment consumeSleep() throws InterruptedException {
while (true) {
synchronized (lock) {
if (!buffer.isEmpty()) {
return buffer.poll();
}
}
Thread.sleep(10); // 지연 + 폴링
}
}
// ✓ 근본 해결은 wait/notify 또는 BlockingQueue (다음)
}5.7 자기 점검 답변
일반 락만으로 처리의 한계는?
답:
1. synchronized 만:
- 대기 방법 문제
-
바쁜 대기:
- 반복 확인
- CPU 낭비
-
데드락:
- 락 안 대기
- 생산자 진입 불가
-
sleep:
- 완화 (지연, 폴링)
- 근본 해결 X → wait/notify
6️⃣ 바쁜 대기의 문제
6.1 바쁜 대기
바쁜 대기 (Busy Waiting / Spin Waiting):
조건을 만족할 때까지
계속 반복 확인하며 CPU 점유.
while (!condition) { } // 계속 확인6.2 CPU 낭비
CPU 낭비:
바쁜 대기:
- CPU 100% 사용
- 의미 없는 반복
- 다른 작업 방해
- 전력 낭비
예:
while (buffer.isEmpty()) { }
→ 비어있는 동안 CPU 풀가동6.3 시각화
바쁜 대기 vs 효율적 대기:
바쁜 대기:
소비자: [확인][확인][확인]...[확인][꺼냄]
CPU 100% (의미 없음)
효율적 대기 (wait):
소비자: [wait (CPU 0%)]......[깨어남][꺼냄]
CPU 0% (대기)
생산자 notify 로 깨움6.4 언제 바쁜 대기가 OK
바쁜 대기가 OK인 경우:
- 매우 짧은 대기 (마이크로초)
- 컨텍스트 스위칭이 더 비쌀 때
- spin lock (짧은 임계 영역)
대부분:
- 바쁜 대기 피해야
- wait/notify, BlockingQueue6.5 효율적 대기
효율적 대기:
wait/notify:
- 조건 안 되면 wait (CPU 0%)
- 조건 되면 notify (깨움)
BlockingQueue:
- take() 가 자동 대기
- put() 이 자동 통지
LockSupport:
- park/unpark
→ CPU 낭비 X6.6 ILIC 의 맥락
@Service
public class BusyWaitingProblem {
private final Queue<Shipment> buffer = new ConcurrentLinkedQueue<>();
// ❌ 바쁜 대기 (CPU 낭비)
public Shipment consumeBusy() {
Shipment shipment;
while ((shipment = buffer.poll()) == null) {
// 계속 확인 (CPU 100%)
}
return shipment;
}
// ✓ 효율적 — BlockingQueue
private final BlockingQueue<Shipment> blockingBuffer =
new LinkedBlockingQueue<>();
public Shipment consumeEfficient() throws InterruptedException {
return blockingBuffer.take(); // 비면 효율적 대기 (CPU 0%)
// 내부적으로 wait/notify (또는 park/unpark)
}
}6.7 자기 점검 답변
바쁜 대기의 문제는?
답:
1. 바쁜 대기:
- 반복 확인
- CPU 점유
-
문제:
- CPU 100% 낭비
- 다른 작업 방해
- 전력
-
OK 경우:
- 매우 짧은 대기
- spin lock
-
효율적:
- wait/notify
- BlockingQueue (CPU 0%)
7️⃣ 멀티스레드 핵심 문제인 이유
7.1 핵심 문제
생산자-소비자가 핵심인 이유:
멀티스레드 협력의 모든 요소 포함:
- 공유 자원 (버퍼)
- 동기화 (경쟁)
- 조건 대기 (차/빔)
- 통지 (협력)
- 효율 (바쁜 대기 회피)7.2 포함된 개념들
포함된 동시성 개념:
1. 상호 배제
- 버퍼 동기화
2. 조건 동기화
- 차면/비면 대기
3. 협력
- 생산자-소비자 통지
4. 효율
- 바쁜 대기 회피7.3 다른 문제와 연결
다른 동시성 문제와 연결:
- 스레드 풀 (작업 큐)
- 이벤트 루프 (이벤트 큐)
- 파이프라인 (단계별 큐)
- 백프레셔 (버퍼 제어)
→ 생산자-소비자가 기반7.4 실무의 보편성
실무 보편성:
거의 모든 비동기 시스템:
- 메시지 큐
- 작업 큐
- 로깅
- 스트림
→ 생산자-소비자 패턴
→ 이해 필수7.5 학습 가치
학습 가치:
생산자-소비자 이해 =
- wait/notify 이해
- BlockingQueue 이해
- 스레드 풀 이해
- 비동기 시스템 이해
→ 동시성의 핵심7.6 ILIC 의 맥락
@Service
public class ProducerConsumerCore {
// ILIC 의 여러 곳에 생산자-소비자
// 1. 배송 처리 파이프라인
private final BlockingQueue<Shipment> processingQueue =
new LinkedBlockingQueue<>();
// 2. 알림 발송
private final BlockingQueue<Notification> notificationQueue =
new LinkedBlockingQueue<>();
// 3. 감사 로그
private final BlockingQueue<AuditEvent> auditQueue =
new LinkedBlockingQueue<>();
// 4. 외부 API 호출 (재시도 큐)
private final BlockingQueue<ApiCall> retryQueue =
new LinkedBlockingQueue<>();
// 모두 생산자-소비자 패턴
// 이 패턴 이해 = ILIC 비동기 시스템 이해
record Notification(String message) {}
record AuditEvent(String action) {}
record ApiCall(String endpoint) {}
}7.7 자기 점검 답변
멀티스레드 핵심 문제인 이유는?
답:
1. 모든 요소 포함:
- 공유 자원
- 동기화
- 조건 대기
- 통지, 효율
-
개념:
- 상호 배제
- 조건 동기화
- 협력
-
연결:
- 스레드 풀, 이벤트 루프
- 파이프라인
-
보편성:
- 거의 모든 비동기 시스템
8️⃣ BlockingQueue 해결책
8.1 BlockingQueue
BlockingQueue:
생산자-소비자를 위한 동시성 큐.
java.util.concurrent
특징:
- put: 가득 차면 대기
- take: 비면 대기
- 내부 동기화 (자동)8.2 주요 메서드
BlockingQueue<Task> queue = new LinkedBlockingQueue<>();
// 블로킹 (대기)
queue.put(task); // 가득 차면 대기
Task task = queue.take(); // 비면 대기
// 논블로킹
queue.offer(task); // 가득 차면 false
Task t = queue.poll(); // 비면 null
// 타임아웃
queue.offer(task, 1, SECONDS); // 1초 시도
queue.poll(1, SECONDS); // 1초 대기8.3 구현체
BlockingQueue 구현체:
ArrayBlockingQueue:
- 고정 크기 배열
- 유한 버퍼
LinkedBlockingQueue:
- 링크드 노드
- 선택적 크기
PriorityBlockingQueue:
- 우선순위
SynchronousQueue:
- 크기 0 (직접 전달)
DelayQueue:
- 지연 후 꺼냄8.4 생산자-소비자 구현
// BlockingQueue 로 생산자-소비자 (간단)
public class ProducerConsumerWithBQ {
private final BlockingQueue<Task> queue = new LinkedBlockingQueue<>(100);
// 생산자
public void producer() throws InterruptedException {
while (true) {
Task task = createTask();
queue.put(task); // 가득 차면 자동 대기
}
}
// 소비자
public void consumer() throws InterruptedException {
while (true) {
Task task = queue.take(); // 비면 자동 대기
process(task);
}
}
// wait/notify 직접 안 써도 됨 (내부 구현)
private Task createTask() { return null; }
private void process(Task t) { }
}8.5 왜 권장
BlockingQueue 권장 이유:
- 검증된 구현 (버그 없음)
- wait/notify 직접 X
- 효율적 (바쁜 대기 X)
- 다양한 구현체
- 타임아웃, 논블로킹
→ 직접 wait/notify 보다 권장8.6 ILIC 의 맥락
@Service
public class ShipmentBlockingQueue {
// 유한 버퍼 (백프레셔)
private final BlockingQueue<Shipment> queue = new ArrayBlockingQueue<>(1000);
// 생산자 (API 핸들러)
public void submit(Shipment shipment) throws InterruptedException {
queue.put(shipment); // 1000 가득 차면 대기 (백프레셔)
}
// 논블로킹 버전 (거부)
public boolean trySubmit(Shipment shipment) {
boolean accepted = queue.offer(shipment);
if (!accepted) {
log.warn("큐 가득 참, 거부: {}", shipment.getId());
}
return accepted;
}
// 소비자 (워커 풀)
@PostConstruct
public void startWorkers() {
for (int i = 0; i < 4; i++) {
Thread worker = new Thread(() -> {
while (!Thread.currentThread().isInterrupted()) {
try {
Shipment shipment = queue.take(); // 효율적 대기
process(shipment);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break;
}
}
}, "worker-" + i);
worker.start();
}
}
private void process(Shipment s) { }
}8.7 자기 점검 답변
BlockingQueue가 해결책인 이유는?
답:
1. BlockingQueue:
- 생산자-소비자 큐
- put/take (자동 대기)
-
메서드:
- put/take (블로킹)
- offer/poll (논블로킹)
-
구현체:
- Array/Linked/Priority
- Synchronous
-
권장:
- 검증된 구현
- wait/notify 직접 X
9️⃣ 면접 + 자기 점검
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 생산자-소비자? | 버퍼 매개 협력 |
| 생산자 역할? | 데이터 생성 → 버퍼 |
| 소비자 역할? | 버퍼 → 처리 |
| 버퍼 가득? | 생산자 대기 |
| 버퍼 빔? | 소비자 대기 |
| 실제 사례? | MQ, 로깅, 작업 큐 |
| 일반 락 한계? | 바쁜 대기, 데드락 |
| 바쁜 대기? | CPU 낭비 |
| 핵심 문제 이유? | 모든 협력 요소 |
| 해결책? | wait/notify, BlockingQueue |
9.2 자기 점검 체크리스트
정의
- 생산자-소비자
- 버퍼
- 느슨한 결합
역할
- 생산자
- 소비자
- N-M
경계
- 가득 참
- 빔
- 통지
사례
- MQ
- 로깅
- 작업 큐
일반 락
- 한계
- 바쁜 대기
핵심 문제
- 이유
- 연결
해결
- BlockingQueue
- wait/notify
9.3 추가 심화 질문
Q1: 백프레셔 (Backpressure)?
답:
- 소비자가 못 따라갈 때
- 생산자 속도 조절
- 유한 버퍼 (put 대기)
- 시스템 보호
Q2: SynchronousQueue?
답:
- 크기 0 버퍼
- 생산자-소비자 직접 전달
- put 이 take 기다림
- 핸드오프 (handoff)
Q3: 무한 큐의 위험?
답:
- LinkedBlockingQueue (크기 무제한)
- 소비 < 생산 시 메모리 폭발
- OOM 위험
- 유한 큐 권장
Q4: 우선순위 큐?
답:
- PriorityBlockingQueue
- 우선순위 순서로 take
- 긴급 작업 먼저
- Comparator
Q5: Disruptor?
답:
- 고성능 생산자-소비자
- 링 버퍼 (lock-free)
- LMAX
- 매우 빠름
🎯 핵심 요약 — 3줄 정리
1. 생산자-소비자
- 생산자 → 버퍼 → 소비자 (협력)
- 가득 참: 생산자 대기, 빔: 소비자 대기
2. 일반 락 한계
- 바쁜 대기 (CPU 낭비)
- 또는 데드락 (락 안 대기)
3. 해결
- wait/notify (다음 Unit)
- BlockingQueue (권장, 검증됨)
- 사례: MQ, 로깅, 작업 큐
📚 다음으로...
Unit 6.2 — wait()과 notify()
이번 Unit에서 생산자-소비자 문제를 봤다면, 다음은 wait/notify (효율적 대기/통지).
- wait() 의 동작 (락 반납 + 대기)
- notify / notifyAll
- while vs if (spurious wakeup)
- wait vs sleep
Phase 6 진행 상황
🚀 Phase 6 — 스레드 간 협력
✅ Unit 6.1 생산자-소비자 문제 ← 여기
⏭ Unit 6.2 wait()과 notify()
⏭ Unit 6.3 인터럽트 메커니즘
⏭ Unit 6.4 yield()4주차 누적 진행
✅ Phase 1~5 (21 Unit, 1차 정점 완료)
🚀 Phase 6 — 스레드 협력 (1/4 진행)
총: 22/35 UnitF-LAB JAVA · 4주차 · Phase 6 · Unit 6.1 · 끝
🚀 Phase 6 시작 — 스레드 협력 진입
Software Developer