Unit 4.4 — 모니터 락(Monitor Lock)의 동작
F-LAB JAVA · 4주차 · Phase 4 · 동기화: synchronized와 메모리 가시성
★ 마스터 Unit — 면접 단골 (★★★)
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- 모니터 락 (Monitor Lock / Intrinsic Lock) 의 정의는?
- 모든 자바 객체가 모니터 락 을 가지는 의미는?
- synchronized 진입 시 락 획득 과정 (성공/실패) 은?
- BLOCKED 상태로 대기 하는 메커니즘은?
- 메서드/블록 종료 시 락 자동 반환 은?
- 락 경쟁 시나리오 (100 스레드, 1개 성공) 는?
- 락 획득 순서 (공정성, Fairness) 가 보장되는가?
- synchronized 의 단점 3가지 는?
- 모니터의 객체 헤더 (Mark Word) 는?
🎯 핵심 한 문장
모니터 락 (Monitor Lock, = intrinsic lock / 고유 락) 은 모든 자바 객체가 내부적으로 하나씩 가지는 락으로, synchronized 가 이 락을 사용하여 상호 배제를 구현한다.
스레드가 synchronized 에 진입하려면 그 객체의 모니터 락 획득을 시도하며, 성공하면 RUNNABLE 로 진입, 실패하면 (다른 스레드가 보유 중) BLOCKED 상태로 대기 한다.
synchronized 메서드/블록이 종료되면 (정상 또는 예외) 락이 자동으로 반환 되고, 대기 중이던 BLOCKED 스레드 중 하나가 락을 획득한다.
100개 스레드가 같은 synchronized 블록 진입을 시도하면 1개만 성공하고 99개는 BLOCKED 되며, 락 획득 순서는 자바 표준에 정의되어 있지 않다 (공정성 X) — 먼저 대기한 스레드가 먼저 받는다는 보장이 없다.
synchronized 의 단점은 (1) 무한 대기 (타임아웃 불가), (2) 인터럽트 불가 (대기 중 깰 수 없음), (3) 공정성 보장 X 이며, 이를 극복하는 도구가 Phase 5 의 ReentrantLock 이다.
비유 — 회의실 1개 열쇠와 대기자들
모니터 락 = 회의실 열쇠 (객체마다 1개):
진입 시도:
- 열쇠 있으면 → 들어감 (RUNNABLE)
- 열쇠 없으면 → 문 앞 대기 (BLOCKED)
종료 시:
- 열쇠 반납
- 대기자 중 1명이 가져감
100명 대기 (락 경쟁):
- 열쇠 1개
- 1명만 들어감
- 99명 문 앞 대기 (BLOCKED)
공정성 X (먼저 온 순서 보장 X):
- 열쇠 반납 시
- 누가 가져갈지 OS 가 결정
- 먼저 기다린 사람이 못 받을 수도
- "새치기" 가능 (barging)
단점:
- 무한 대기 (포기 불가)
- 누가 두드려도 (인터럽트) 안 나옴
- 줄 순서 (공정성) 없음→ 모니터 락 = 객체별 열쇠, 100명 중 1명, 공정성 없음.
🧭 9개 섹션 로드맵
1. 모니터 락의 정의
2. 모든 객체가 모니터 락
3. 락 획득 과정 (성공/실패)
4. BLOCKED 대기 메커니즘
5. 락 자동 반환
6. 락 경쟁 시나리오 (100 스레드)
7. 공정성 (Fairness)
8. synchronized의 단점 3가지
9. 면접 + 자기 점검 + 마스터 50문항1️⃣ 모니터 락의 정의
1.1 모니터 락이란
모니터 락 (Monitor Lock):
= Intrinsic Lock (고유 락)
= Object Lock
모든 자바 객체가 내부적으로 가지는 락.
synchronized 가 이 락을 사용.
특징:
- 객체당 1개
- 상호 배제
- 재진입 가능1.2 모니터의 개념
모니터 (Monitor):
동기화 메커니즘.
- 락 (Lock) — 상호 배제
- 대기 집합 (Wait Set) — wait/notify
자바:
- 모든 객체가 모니터
- synchronized = 락 사용
- wait/notify = 대기 집합 (Phase 6)1.3 intrinsic 의 의미
"intrinsic" (고유):
- 객체에 내재된 락
- 별도 객체 생성 불필요
- 모든 객체에 기본 내장
대조:
- ReentrantLock (명시적 락)
- 별도 객체 생성 (new ReentrantLock)1.4 모니터 락 사용
Object obj = new Object();
// obj 의 모니터 락 사용
synchronized (obj) {
// obj 의 락 보유
}
// 모든 객체 가능
synchronized (this) { } // this 의 락
synchronized (myList) { } // myList 의 락
synchronized (String.class) { } // Class 객체 락1.5 모니터 락의 구성
모니터 락 구성:
1. 소유 스레드 (Owner)
- 현재 락 보유 스레드
2. 재진입 카운트 (Recursion Count)
- 같은 스레드 재획득 횟수
3. 진입 대기 집합 (Entry Set)
- 락 대기 스레드 (BLOCKED)
4. 대기 집합 (Wait Set)
- wait() 한 스레드 (WAITING)1.6 ILIC 의 맥락
public class MonitorLockBasics {
private int count = 0;
private final Object lock = new Object(); // lock 의 모니터
public void increment() {
synchronized (lock) { // lock 의 모니터 락 사용
count++;
}
}
// this 의 모니터
public synchronized void incrementThis() {
count++; // this 의 락
}
// 모든 객체가 모니터 락 보유
// - lock (Object)
// - this (ShipmentService)
// - String, List, 등 모두
}1.7 자기 점검 답변
모니터 락의 정의는?
답:
1. 정의:
- 모든 객체의 내장 락
- intrinsic lock
- synchronized 가 사용
-
모니터:
- 락 + 대기 집합
- 동기화 메커니즘
-
intrinsic:
- 내재된 락
- 별도 생성 X
-
구성:
- 소유 스레드
- 재진입 카운트
- 진입/대기 집합
2️⃣ 모든 객체가 모니터 락
2.1 모든 객체
모든 자바 객체가 모니터 락:
- Object 부터 상속
- 객체 헤더에 락 정보
- 별도 설정 불필요
따라서:
- 어떤 객체든 synchronized 가능
- new Object(), this, List, 등2.2 객체 헤더 (Object Header)
객체 헤더 구조:
┌──────────────────────┐
│ Mark Word │ ← 락 정보, 해시, GC age
├──────────────────────┤
│ Klass Pointer │ ← 클래스 메타데이터
├──────────────────────┤
│ (배열이면 길이) │
└──────────────────────┘
┌──────────────────────┐
│ 인스턴스 데이터 │ ← 필드
└──────────────────────┘2.3 Mark Word
Mark Word (락 정보):
객체 헤더의 일부.
락 상태에 따라 내용 변함:
- Unlocked: 해시코드, GC age
- Biased: 편향 스레드 ID
- Lightweight: 락 레코드 포인터
- Heavyweight: 모니터 포인터
- GC: 마킹
→ 락 상태를 Mark Word 로 표현2.4 락 상태 전이
락 상태 전이 (Java 6+ 최적화):
No Lock
↓ (단일 스레드 접근)
Biased Lock (편향 락)
↓ (다른 스레드 경합)
Lightweight Lock (경량 락, CAS)
↓ (경합 심화)
Heavyweight Lock (중량 락, 모니터)
- 경합 적으면 가벼움 (빠름)
- 경합 심하면 무거움 (OS 모니터)2.5 락의 비용
락 상태별 비용:
Biased Lock:
- 거의 무비용
- 단일 스레드 반복
Lightweight Lock:
- CAS 연산
- 경합 적을 때
Heavyweight Lock:
- OS 모니터
- 컨텍스트 스위칭
- 비쌈
→ JVM 이 자동 최적화2.6 ILIC 의 맥락
public class ObjectMonitorExample {
// 모든 객체가 모니터 락
private final Object lock1 = new Object();
private final List<Shipment> list = new ArrayList<>();
private final Map<Long, Shipment> map = new HashMap<>();
public void useVariousLocks() {
synchronized (lock1) { // Object 의 모니터
// ...
}
synchronized (list) { // ArrayList 의 모니터
list.add(shipment);
}
synchronized (map) { // HashMap 의 모니터
map.put(1L, shipment);
}
// 모두 각자의 모니터 락
// 독립적
}
}2.7 자기 점검 답변
모든 객체가 모니터 락을 가지는 의미는?
답:
1. 모든 객체:
- Object 부터 상속
- 객체 헤더에 락 정보
-
객체 헤더:
- Mark Word (락 정보)
- Klass Pointer
-
Mark Word:
- 락 상태 표현
- 상태별 내용 변함
-
락 상태 전이:
- Biased → Lightweight → Heavyweight
- JVM 자동 최적화
3️⃣ 락 획득 과정 (성공/실패)
3.1 락 획득 시도
synchronized 진입 시:
1. 락 획득 시도 (monitorenter)
2. 성공:
- 락 보유
- RUNNABLE (진입)
3. 실패 (다른 스레드 보유):
- BLOCKED (대기)3.2 성공 시나리오
락 획득 성공:
스레드 A:
synchronized (lock) 진입
↓ monitorenter
락 비어있음 → 획득
↓
RUNNABLE (임계 영역 실행)
↓ monitorexit
락 반납3.3 실패 시나리오
락 획득 실패:
스레드 B (A 가 락 보유 중):
synchronized (lock) 진입
↓ monitorenter
락 있음 (A 보유) → 획득 실패
↓
BLOCKED (진입 대기 집합)
↓ (A 가 반납)
락 획득 → RUNNABLE3.4 monitorenter/monitorexit
바이트코드:
synchronized (lock) {
// ...
}
→
monitorenter // 락 획득
// 임계 영역
monitorexit // 락 반납 (정상)
monitorexit // 락 반납 (예외 시)3.5 시각화
락 획득 (A 성공, B 실패):
lock 모니터:
Owner: A (보유)
Entry Set: [B] (대기)
스레드 A: [monitorenter 성공][임계 영역][monitorexit]
스레드 B: [monitorenter 실패 → BLOCKED────][획득][실행]
↑ A 반납 후3.6 ILIC 의 맥락
@Service
public class LockAcquisition {
private int counter = 0;
private final Object lock = new Object();
public void process() {
// monitorenter (락 획득 시도)
synchronized (lock) {
// 성공: RUNNABLE (여기 실행)
// 실패: BLOCKED (다른 스레드 대기)
counter++;
doWork();
}
// monitorexit (락 반납)
}
private void doWork() {
// 임계 영역
// 이 동안 다른 스레드 BLOCKED
}
}3.7 자기 점검 답변
락 획득 과정 (성공/실패)은?
답:
1. 시도:
- monitorenter
- 락 획득 시도
-
성공:
- 락 보유
- RUNNABLE
-
실패:
- 다른 스레드 보유
- BLOCKED
-
바이트코드:
- monitorenter (획득)
- monitorexit (반납)
4️⃣ BLOCKED 대기 메커니즘
4.1 BLOCKED 상태
BLOCKED 상태:
모니터 락을 획득하지 못해
진입 대기 집합 (Entry Set) 에서 대기.
특징:
- CPU 사용 X (대기)
- 락 반납 시 깨어남
- 인터럽트로 못 깨움4.2 진입 대기 집합
Entry Set (진입 대기 집합):
락을 기다리는 스레드들.
- BLOCKED 상태
- 락 반납 시 경쟁
vs Wait Set (대기 집합):
- wait() 한 스레드
- WAITING 상태
- notify 로 깨어남 (Phase 6)4.3 시각화
모니터 구조:
모니터 (lock)
┌─────────────────────┐
│ Owner: 스레드 A │ ← 현재 보유
├─────────────────────┤
│ Entry Set: │ ← 락 대기 (BLOCKED)
│ [B, C, D] │
├─────────────────────┤
│ Wait Set: │ ← wait() (WAITING)
│ [E, F] │
└─────────────────────┘
A 반납 시 → Entry Set 에서 하나 선택4.4 BLOCKED 의 깨어남
BLOCKED → RUNNABLE:
락 보유 스레드가 반납 (monitorexit)
↓
Entry Set 에서 하나 선택
↓
선택된 스레드 락 획득
↓
RUNNABLE
- 선택은 OS/JVM (공정성 X)
- 인터럽트로 안 깨어남4.5 BLOCKED vs WAITING
BLOCKED vs WAITING:
BLOCKED:
- 락 대기 (Entry Set)
- synchronized 진입 실패
- 락 반납 시 깨어남
WAITING:
- wait() (Wait Set)
- 명시적 대기
- notify 시 깨어남
핵심:
- BLOCKED: 락 경쟁
- WAITING: 조건 대기4.6 ILIC 의 맥락
@Service
public class BlockedMechanism {
private final Object lock = new Object();
public void longOperation() {
synchronized (lock) {
// 오래 점유
try { Thread.sleep(5000); } catch (Exception e) {}
// 이 동안 다른 스레드 BLOCKED
}
}
// 모니터링 — BLOCKED 확인
public void monitorBlocked(List<Thread> threads) {
long blockedCount = threads.stream()
.filter(t -> t.getState() == Thread.State.BLOCKED)
.count();
if (blockedCount > 0) {
log.warn("{} threads blocked on lock", blockedCount);
// jstack 으로 어떤 락인지 확인
}
}
}4.7 자기 점검 답변
BLOCKED 대기 메커니즘은?
답:
1. BLOCKED:
- 락 못 얻어 대기
- Entry Set
- CPU X
-
Entry Set:
- 락 대기 (BLOCKED)
- vs Wait Set (WAITING)
-
깨어남:
- 락 반납 시
- 하나 선택 (공정성 X)
- 인터럽트 X
-
vs WAITING:
- 락 경쟁 vs 조건 대기
5️⃣ 락 자동 반환
5.1 자동 반환
락 자동 반환:
synchronized 블록/메서드 종료 시
락 자동 반환.
종료:
- 정상 종료 (return)
- 예외 발생 (throw)
- 둘 다 반환 보장5.2 정상 종료
synchronized (lock) {
count++;
// 블록 끝
}
// monitorexit (자동 반환)5.3 예외 시 반환
synchronized (lock) {
count++;
throw new RuntimeException(); // 예외!
// 그래도 monitorexit (반환 보장)
}
// 예외 전파되지만 락은 반환
// 바이트코드:
// monitorenter
// try {
// // 임계 영역
// } finally {
// monitorexit // 예외 시에도
// }5.4 자동 반환의 장점
자동 반환의 장점:
- 명시적 unlock 불필요
- 예외 시에도 안전
- 데드락 방지 (락 잔류 X)
대조 (ReentrantLock):
- 명시적 unlock 필요
- try-finally 필수
- 깜박하면 데드락5.5 시각화
자동 반환:
정상:
monitorenter → [임계 영역] → monitorexit
↑ 자동
예외:
monitorenter → [임계 영역 중 예외] → monitorexit
↑ 자동 (예외 시에도)
→ 락 항상 반환 (안전)5.6 ILIC 의 맥락
@Service
public class AutoRelease {
private int counter = 0;
private final Object lock = new Object();
// 자동 반환 (예외 시에도)
public void process(Shipment shipment) {
synchronized (lock) {
counter++;
validate(shipment); // 예외 가능
// 예외 발생해도 락 자동 반환
}
// 데드락 위험 없음
}
private void validate(Shipment s) {
if (s == null) {
throw new IllegalArgumentException();
// 예외! 하지만 락은 반환됨
}
}
// synchronized 장점:
// - unlock 깜박할 일 없음
// - 예외 시에도 안전
// (ReentrantLock 은 try-finally 필수 — Phase 5)
}5.7 자기 점검 답변
락 자동 반환은?
답:
1. 자동 반환:
- 블록/메서드 종료 시
- 정상/예외 모두
-
예외 시:
- monitorexit 보장
- finally 처럼
-
장점:
- unlock 불필요
- 예외 안전
- 데드락 방지
-
vs Lock:
- synchronized: 자동
- ReentrantLock: 명시적 (try-finally)
6️⃣ 락 경쟁 시나리오 (100 스레드)
6.1 시나리오
100 스레드 락 경쟁:
100개 스레드가 같은 synchronized 블록 진입 시도.
결과:
- 1개만 성공 (락 획득)
- 99개 BLOCKED (대기)
→ 직렬화 (하나씩 처리)6.2 코드
public class HundredThreadsContention {
private int counter = 0;
private final Object lock = new Object();
public void demo() throws InterruptedException {
List<Thread> threads = new ArrayList<>();
for (int i = 0; i < 100; i++) {
Thread t = new Thread(() -> {
synchronized (lock) { // 100개 경쟁
counter++;
sleep(10); // 점유
}
});
t.start();
threads.add(t);
}
for (Thread t : threads) t.join();
System.out.println("Counter: " + counter); // 정확히 100
// 하지만 100 × 10ms = 약 1초 (직렬화)
}
}6.3 직렬화
100 스레드 직렬화:
락 1개 → 한 번에 1개만 진입.
스레드 1: [락][10ms]
스레드 2: [BLOCKED][락][10ms]
스레드 3: [BLOCKED][락][10ms]
...
전체 시간 = 100 × 10ms = 1초
(병렬성 없음, 직렬)6.4 경합의 영향
경합 (Contention) 의 영향:
높은 경합:
- 많은 BLOCKED
- 직렬화
- 처리량 ↓
- 컨텍스트 스위칭 ↑
낮은 경합:
- 적은 대기
- 빠른 처리
→ 경합 줄이기:
- 락 분리
- 범위 최소화
- lock-free (Atomic)6.5 시각화
락 경쟁:
lock 모니터
Owner: 스레드 1
Entry Set: [2,3,4,...,100] ← 99개 BLOCKED
스레드 1: [실행]
스레드 1 종료 → 반납
→ Entry Set 에서 1개 선택 (예: 스레드 50)
→ 스레드 50 실행
...
순차적 (직렬화)6.6 ILIC 의 맥락
@Service
public class ContentionExample {
private int processedCount = 0;
private final Object lock = new Object();
// ❌ 높은 경합 (모든 요청이 같은 락)
public void processWithContention(Shipment shipment) {
synchronized (lock) {
processedCount++;
doProcess(shipment); // 시간 걸림
// 모든 스레드 직렬화
}
}
// ✓ 경합 줄이기 — Atomic
private final AtomicInteger atomicCount = new AtomicInteger();
public void processLowContention(Shipment shipment) {
doProcess(shipment); // 병렬
atomicCount.incrementAndGet(); // lock-free
}
// ✓ 경합 줄이기 — 락 분리
private final Object[] locks = new Object[16];
{
for (int i = 0; i < 16; i++) locks[i] = new Object();
}
public void processStriped(Shipment shipment) {
int stripe = (int)(shipment.getId() % 16);
synchronized (locks[stripe]) { // 분산
doProcess(shipment);
}
// 다른 stripe → 동시 가능
}
private void doProcess(Shipment s) { }
}6.7 자기 점검 답변
락 경쟁 시나리오 (100 스레드)는?
답:
1. 결과:
- 1개 성공
- 99개 BLOCKED
-
직렬화:
- 하나씩 처리
- 병렬성 X
-
경합 영향:
- 처리량 ↓
- 스위칭 ↑
-
줄이기:
- 락 분리
- Atomic (lock-free)
- 범위 최소화
7️⃣ 공정성 (Fairness)
7.1 공정성이란
공정성 (Fairness):
락 획득 순서가
대기 순서와 일치하는가.
공정 (Fair):
- 먼저 대기 → 먼저 획득 (FIFO)
비공정 (Non-fair):
- 순서 보장 X
- 새치기 가능 (barging)7.2 synchronized 는 비공정
synchronized 의 공정성:
공정성 보장 X (Non-fair).
- 락 획득 순서 미정의
- 먼저 대기한 스레드가
먼저 받는다는 보장 없음
- OS/JVM 이 결정7.3 비공정의 문제
비공정의 문제:
1. 기아 (Starvation)
- 특정 스레드가 계속 못 받음
- 무한 대기 가능
2. 예측 불가
- 어느 스레드가 받을지 모름
3. 순서 보장 안 됨
- 처리 순서 중요하면 문제
장점:
- 성능 (공정성 비용 없음)
- 처리량 ↑7.4 기아 시나리오
기아 (Starvation):
스레드 A, B, C 가 락 경쟁:
- A 가 자주 받음
- C 가 계속 못 받음
- C 기아 상태
비공정 락:
- 운 나쁘면 특정 스레드 기아
- 무한 대기 가능7.5 공정성이 필요하면
// synchronized 는 비공정
synchronized (lock) { } // 공정성 X
// 공정성 필요하면 ReentrantLock (Phase 5)
ReentrantLock fairLock = new ReentrantLock(true); // 공정 모드
fairLock.lock();
try {
// FIFO 순서
} finally {
fairLock.unlock();
}
// 단, 공정 모드는 성능 ↓ (순서 관리 비용)7.6 ILIC 의 맥락
@Service
public class FairnessExample {
private final Object lock = new Object();
// synchronized — 비공정 (순서 보장 X)
public void processNonFair(Shipment shipment) {
synchronized (lock) {
// 먼저 대기한 스레드가 먼저 받는다는 보장 X
doProcess(shipment);
}
}
// 공정성 필요 시 — ReentrantLock(true) (Phase 5)
private final ReentrantLock fairLock = new ReentrantLock(true);
public void processFair(Shipment shipment) {
fairLock.lock(); // FIFO 순서
try {
doProcess(shipment);
} finally {
fairLock.unlock();
}
// 순서 보장 (단 성능 ↓)
}
private void doProcess(Shipment s) { }
}7.7 자기 점검 답변
공정성 (Fairness)이 보장되는가?
답:
1. synchronized:
- 비공정 (Non-fair)
- 순서 보장 X
-
공정 vs 비공정:
- 공정: FIFO
- 비공정: 새치기 가능
-
문제:
- 기아 (starvation)
- 예측 불가
-
해결:
- ReentrantLock(true)
- 단 성능 ↓
8️⃣ synchronized의 단점 3가지
8.1 세 가지 단점
synchronized 의 단점 3가지:
1. 무한 대기
- 타임아웃 설정 불가
- 락 받을 때까지 무한
2. 인터럽트 불가
- 대기 중 외부에서 못 깨움
- interrupt() 안 통함
3. 공정성 보장 X
- 순서 미정의
- 기아 가능8.2 단점 1 — 무한 대기
무한 대기:
synchronized 진입 시 락 없으면
무한정 대기 (BLOCKED).
- 타임아웃 X
- "1초만 기다리고 포기" 불가
- 락 영원히 안 풀리면 영원히 대기
문제:
- 데드락 시 회복 불가
- 응답 지연8.3 단점 2 — 인터럽트 불가
// synchronized 대기 중 인터럽트 안 통함
Thread t = new Thread(() -> {
synchronized (lock) { // 락 대기 (BLOCKED)
// ...
}
});
t.start();
t.interrupt(); // ❌ BLOCKED 는 인터럽트 안 됨
// 락 받을 때까지 계속 대기
// ReentrantLock 은 lockInterruptibly() 가능 (Phase 5)8.4 단점 3 — 공정성 X
공정성 X (앞 섹션):
- 순서 보장 안 됨
- 기아 가능
- 예측 불가
ReentrantLock(true) 로 해결 가능8.5 ReentrantLock 의 극복 (Phase 5 예고)
// synchronized 한계
synchronized (lock) {
// 무한 대기, 인터럽트 X, 비공정
}
// ReentrantLock 극복 (Phase 5)
ReentrantLock lock = new ReentrantLock(true); // 공정
// 1. 타임아웃
if (lock.tryLock(5, TimeUnit.SECONDS)) { // 5초만
try { } finally { lock.unlock(); }
}
// 2. 인터럽트 가능
lock.lockInterruptibly(); // 인터럽트로 깰 수 있음
// 3. 공정성
new ReentrantLock(true); // FIFO8.6 ILIC 의 맥락
@Service
public class SynchronizedLimitations {
private final Object lock = new Object();
// ❌ synchronized 한계
public void processSync(Shipment shipment) {
synchronized (lock) {
// 1. 무한 대기 (타임아웃 X)
// 2. 인터럽트 X
// 3. 비공정
doProcess(shipment);
}
}
// ✓ ReentrantLock 극복 (Phase 5)
private final ReentrantLock reentrantLock = new ReentrantLock();
public boolean processWithTimeout(Shipment shipment) {
try {
// 1. 타임아웃
if (reentrantLock.tryLock(5, TimeUnit.SECONDS)) {
try {
doProcess(shipment);
return true;
} finally {
reentrantLock.unlock();
}
}
return false; // 5초 내 못 얻음
} catch (InterruptedException e) {
// 2. 인터럽트 가능
Thread.currentThread().interrupt();
return false;
}
}
private void doProcess(Shipment s) { }
}8.7 자기 점검 답변
synchronized의 단점 3가지는?
답:
1. 무한 대기:
- 타임아웃 X
- 데드락 회복 불가
-
인터럽트 불가:
- BLOCKED 못 깨움
- interrupt() 안 통함
-
공정성 X:
- 순서 미정의
- 기아 가능
-
극복:
- ReentrantLock (Phase 5)
- tryLock, lockInterruptibly, fair
9️⃣ 면접 + 자기 점검 + 마스터 50문항
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| 모니터 락? | 모든 객체의 내장 락 |
| intrinsic lock? | 고유 락 (내재) |
| 락 획득? | 성공 RUNNABLE, 실패 BLOCKED |
| BLOCKED? | 락 대기 (Entry Set) |
| 락 반환? | 종료 시 자동 (예외 포함) |
| 100 스레드? | 1개 성공, 99개 BLOCKED |
| 공정성? | 보장 X (비공정) |
| 기아? | 특정 스레드 계속 못 받음 |
| 단점 3가지? | 무한 대기, 인터럽트 X, 비공정 |
| Mark Word? | 객체 헤더의 락 정보 |
9.2 마스터 자기 점검 체크리스트
모니터 락
- 정의 (intrinsic)
- 모든 객체
- 구성
객체 헤더
- Mark Word
- 락 상태 전이
락 획득
- 성공 (RUNNABLE)
- 실패 (BLOCKED)
- monitorenter/exit
BLOCKED
- Entry Set
- 깨어남 (락 반납)
- vs WAITING
자동 반환
- 정상/예외
- 데드락 방지
경쟁
- 100 스레드
- 직렬화
- 경합 줄이기
공정성
- 비공정
- 기아
단점
- 무한 대기
- 인터럽트 X
- 비공정
9.3 모니터 락 마스터 50문항
모니터 락 개념 (10문항)
Q1. 모니터 락? → 모든 객체 내장 락
Q2. intrinsic lock? → 고유 락
Q3. 모든 객체? → Object 상속
Q4. 모니터 구성? → 락 + 대기 집합
Q5. 객체 헤더? → Mark Word + Klass
Q6. Mark Word? → 락 정보
Q7. 락 상태 전이? → Biased→Lightweight→Heavyweight
Q8. Biased Lock? → 단일 스레드 최적화
Q9. 소유 스레드? → 현재 락 보유
Q10. 재진입 카운트? → 재획득 횟수락 획득/반환 (10문항)
Q11. 진입 시? → monitorenter
Q12. 성공? → RUNNABLE
Q13. 실패? → BLOCKED
Q14. 종료 시? → monitorexit
Q15. 예외 시 반환? → 보장 (자동)
Q16. 자동 반환 장점? → unlock 불필요
Q17. Entry Set? → 락 대기 (BLOCKED)
Q18. Wait Set? → wait (WAITING)
Q19. BLOCKED 깨어남? → 락 반납
Q20. 인터럽트로 BLOCKED? → 안 깨어남락 경쟁 (10문항)
Q21. 100 스레드? → 1 성공, 99 BLOCKED
Q22. 직렬화? → 하나씩
Q23. 경합? → 대기 많음
Q24. 높은 경합 영향? → 처리량 ↓
Q25. 경합 줄이기? → 락 분리, Atomic
Q26. Lock Striping? → 분할 락
Q27. lock-free? → Atomic (CAS)
Q28. 컨텍스트 스위칭? → 경합 시 ↑
Q29. 범위 최소화? → 경합 ↓
Q30. 무상태? → 경합 X공정성 (10문항)
Q31. 공정성? → 획득 순서 = 대기 순서
Q32. synchronized 공정? → 비공정
Q33. 비공정? → 새치기 가능
Q34. 기아? → 계속 못 받음
Q35. 공정 락? → ReentrantLock(true)
Q36. 공정 단점? → 성능 ↓
Q37. 비공정 장점? → 처리량 ↑
Q38. barging? → 새치기
Q39. FIFO? → 공정 락
Q40. 순서 중요 시? → 공정 락단점/극복 (10문항)
Q41. 단점 1? → 무한 대기
Q42. 단점 2? → 인터럽트 X
Q43. 단점 3? → 공정성 X
Q44. 무한 대기 문제? → 데드락 회복 X
Q45. 타임아웃? → tryLock (Phase 5)
Q46. 인터럽트 가능? → lockInterruptibly
Q47. 공정성? → ReentrantLock(true)
Q48. 극복 도구? → ReentrantLock
Q49. synchronized 장점? → 간단, 자동 반환
Q50. 언제 synchronized? → 단순, 짧은 임계9.4 채점
50 / 50 → 모니터 락 마스터
45-49 → 거의 마스터
40-44 → 복습
< 40 → Unit 4.4 재학습9.5 추가 심화 질문
Q1: Biased Locking 이 제거된 이유 (Java 15+)?
답:
- JDK 15 부터 deprecated, 비활성화
- 현대 앱에서 이점 적음
- 복잡도 증가
- 단일 스레드 가정 약화
Q2: spin lock 과 모니터?
답:
- spin lock: 락 얻을 때까지 반복 (busy)
- Lightweight Lock 에서 짧은 스핀
- 그래도 안 되면 Heavyweight (모니터)
- 적응형 스피닝
Q3: 모니터 락과 happens-before?
답:
- monitorexit happens-before 다음 monitorenter
- 가시성 보장
- JMM 규칙
- 락 해제 시 변경 flush
Q4: 데드락 4가지 조건?
답:
- 상호 배제 (Mutual Exclusion)
- 점유 대기 (Hold and Wait)
- 비선점 (No Preemption)
- 순환 대기 (Circular Wait)
- 모두 충족 시 데드락
Q5: synchronized 와 메모리 배리어?
답:
- monitorenter: acquire 배리어
- monitorexit: release 배리어
- 재정렬 방지
- 가시성 보장
🎯 핵심 요약 — 3줄 정리
1. 모니터 락
- 모든 객체의 내장 락 (intrinsic)
- 획득 성공: RUNNABLE, 실패: BLOCKED
- 종료 시 자동 반환 (예외 포함)
2. 경쟁과 공정성
- 100 스레드 → 1 성공, 99 BLOCKED (직렬화)
- 공정성 X (순서 미정의, 기아 가능)
3. 단점 3가지
- 무한 대기 (타임아웃 X)
- 인터럽트 불가
- 공정성 X
- → ReentrantLock 극복 (Phase 5)
📚 다음으로...
Unit 4.5 — volatile (메모리 가시성) (★ 마스터)
이번 Unit에서 모니터 락을 봤다면, 다음은 volatile (★ 마스터).
- 메모리 가시성 문제
- CPU 캐시
- volatile 의 효과
- 원자성 보장 X
- synchronized 와 차이
Phase 4 진행 상황
🚀 Phase 4 — synchronized & volatile (★ 1차 정점)
✅ Unit 4.1 임계 영역과 동기화의 필요성
✅ Unit 4.2 synchronized 메서드
✅ Unit 4.3 synchronized 블록
✅ Unit 4.4 모니터 락 (★ 마스터) ← 여기
⏭ Unit 4.5 volatile (★ 마스터) — Phase 4 완주4주차 누적 진행
✅ Phase 1 — 동시성의 기초 (4 Unit)
✅ Phase 2 — 4분면 매트릭스 (3 Unit)
✅ Phase 3 — 스레드 다루기 (5 Unit)
🚀 Phase 4 — synchronized & volatile (4/5 진행) ★ 1차 정점
총: 16/35 Unit
Software Developer