Unit 4.3 — synchronized 블록

F-LAB JAVA · 4주차 · Phase 4 · 동기화: synchronized와 메모리 가시성

📌 학습 목표

이 Unit을 끝내면 다음을 답할 수 있어야 한다.

synchronized 블록 의 정의와 동작은?
동기화 범위 최소화 의 의미와 효과는?
잠금 대상 명시 의 방법은?
synchronized (this) vs synchronized (new Object()) 의 차이는?
임계 영역을 너무 넓게 잡으면 어떤 문제가?
메서드 vs 블록 의 선택 가이드는?
private final 락 객체 를 쓰는 이유는?
여러 락 객체 로 세밀한 동기화는?
synchronized 블록의 실무 패턴 은?

🎯 핵심 한 문장

synchronized 블록은 메서드의 일부 코드만 동기화하여 동기화 범위를 최소화하고, 잠금 대상을 명시적으로 지정할 수 있는 방식이다.
synchronized (lock) { ... } 형태로 임계 영역만 감싸므로, 메서드 전체를 잠그는 synchronized 메서드보다 동기화 범위가 좁아 성능이 좋다 (비임계 영역은 병렬 실행).
잠금 대상은 임의의 객체를 지정할 수 있으며 (this, 클래스.class, 별도 객체), synchronized (new Object()) 는 매번 새 객체라 동기화 효과가 없다 (각 스레드가 다른 락).
임계 영역을 너무 넓게 잡으면 불필요한 부분까지 직렬화 되어 병렬성이 떨어지고, 너무 좁으면 데이터 일관성 이 깨질 수 있다 — 적절한 범위가 핵심이다.
실무에서는 private final 락 객체 를 별도로 두어 외부에서 락에 간섭하지 못하게 하고 (캡슐화), 여러 독립 자원에 여러 락 객체 를 두어 세밀하게 동기화한다.

비유 — 회의실 일부만 잠금

synchronized 메서드 = 회의실 전체 잠금:
  - 회의실 들어가는 순간부터 나갈 때까지
  - 자료 정리, 발표, 토론 전부 동안 잠금
  - 다른 사람 못 들어옴 (비효율)

synchronized 블록 = 금고만 잠금:
  - 회의실은 자유 (병렬)
  - 금고 (공유 자원) 사용할 때만 잠금
  - 짧게 → 효율적

잠금 대상 명시:
  - 어느 금고 (락 객체) 인지 지정
  - 금고 A, 금고 B 따로

new Object() 매번 = 매번 새 금고:
  - 각자 새 금고 → 잠금 의미 없음
  - 서로 다른 금고라 충돌 X (잘못)

private final 락 = 전용 금고 열쇠:
  - 외부에서 못 건드림
  - 안전한 동기화

→ synchronized 블록 = 필요한 부분만 잠금, 잠금 대상 명시.

🧭 9개 섹션 로드맵

1. synchronized 블록의 정의
2. 동기화 범위 최소화
3. 잠금 대상 명시
4. synchronized (this) vs new Object()
5. 너무 넓은 임계 영역의 문제
6. 메서드 vs 블록 선택
7. private final 락 객체
8. 여러 락 객체 (세밀한 동기화)
9. 면접 + 자기 점검

1️⃣ synchronized 블록의 정의

1.1 synchronized 블록

public void increment() {
    // 비동기 영역 (병렬)
    doSomethingElse();
    
    synchronized (lock) {   // 임계 영역만
        count++;
    }
    
    // 비동기 영역 (병렬)
    doMore();
}

1.2 문법

synchronized (락_객체) {
    // 임계 영역
}

// 락_객체:
// - this (현재 인스턴스)
// - 클래스.class (Class 객체)
// - 별도 객체 (private final Object lock)

1.3 동작

synchronized 블록 동작:

  블록 진입 시:
    - 락 객체의 모니터 락 획득
    - 성공 → 진입
    - 실패 → BLOCKED

  블록 종료 시:
    - 락 자동 반납

  → 블록 내부만 동기화

1.4 메서드와 비교

// synchronized 메서드 (전체)
public synchronized void method() {
    heavyWork();   // 락 안 (불필요)
    count++;       // 임계 영역
    moreWork();    // 락 안 (불필요)
}

// synchronized 블록 (일부)
public void method() {
    heavyWork();   // 락 밖 (병렬)
    synchronized (this) {
        count++;   // 임계 영역만
    }
    moreWork();    // 락 밖 (병렬)
}

1.5 효과

synchronized 블록의 효과:

  메서드와 동일한 효과:
    - 상호 배제
    - 가시성
    - 원자성

  추가:
    - 범위 최소화
    - 잠금 대상 선택
    - 성능 ↑

1.6 ILIC 의 맥락

@Service
public class ShipmentBlockExample {
    
    private int counter = 0;
    private final Object lock = new Object();
    
    public void process(Shipment shipment) {
        // 비임계 영역 (병렬)
        BigDecimal freight = calculateFreight(shipment);   // 무거운 계산
        validateShipment(shipment);                        // 검증
        
        // 임계 영역만 (짧게)
        synchronized (lock) {
            counter++;
        }
        
        // 비임계 영역 (병렬)
        repository.save(shipment);   // DB 저장
    }
    
    private BigDecimal calculateFreight(Shipment s) { return s.getWeight(); }
    private void validateShipment(Shipment s) { }
}

1.7 자기 점검 답변

synchronized 블록의 정의는?

답:
1. 정의:

메서드 일부 동기화
synchronized (lock) { }

문법:
- 락 객체 지정
- this, Class, 별도 객체
동작:
- 블록 진입 시 락
- 종료 시 반납
효과:
- 범위 최소화
- 잠금 대상 선택

2️⃣ 동기화 범위 최소화

2.1 범위 최소화의 의미

동기화 범위 최소화:

  임계 영역 (공유 자원 접근) 만 동기화.
  나머지는 락 밖에서 (병렬).

목적:
  - 병렬성 ↑
  - 락 점유 시간 ↓
  - 성능 ↑

2.2 효과

범위 최소화의 효과:

넓은 범위 (메서드 전체):
  - 모든 스레드 직렬화
  - 무거운 작업도 대기
  - 병목

좁은 범위 (블록):
  - 임계 영역만 직렬화
  - 무거운 작업 병렬
  - 처리량 ↑

2.3 예시 — 개선

// ❌ 넓은 범위 (느림)
public synchronized void processWide(Shipment shipment) {
    BigDecimal freight = expensiveCalc(shipment);   // 1초 (락 안)
    counter++;                                       // 즉시
    repository.save(shipment);                       // 0.5초 (락 안)
    // 전체 1.5초 동안 다른 스레드 대기
}

// ✓ 좁은 범위 (빠름)
public void processNarrow(Shipment shipment) {
    BigDecimal freight = expensiveCalc(shipment);   // 1초 (병렬)
    
    synchronized (lock) {
        counter++;   // 즉시 (락 안, 짧게)
    }
    
    repository.save(shipment);   // 0.5초 (병렬)
    // 임계 영역만 직렬화 (counter++)
}

2.4 시각화

범위 비교 (3 스레드):

넓은 범위:
  A: [████████████] 1.5초
  B:               [████████████] 1.5초 (대기 후)
  C:                            [████████████]
  전체: 4.5초 (직렬)

좁은 범위:
  A: [계산 병렬][lock][저장 병렬]
  B: [계산 병렬][lock][저장 병렬]
  C: [계산 병렬][lock][저장 병렬]
  전체: ~1.5초 (계산/저장 병렬, lock 만 직렬)

2.5 최소화의 한계

너무 좁으면 안 됨:

  데이터 일관성 필요한 부분은
  함께 동기화.

예:
  // ❌ 너무 좁음 (일관성 깨짐)
  synchronized (lock) { check(); }
  synchronized (lock) { act(); }
  // check 와 act 사이 다른 스레드 개입
  
  // ✓ 일관성 필요하면 함께
  synchronized (lock) {
      check();
      act();   // check-then-act 원자적
  }

2.6 ILIC 의 맥락

@Service
public class ShipmentRangeOptimization {
    
    private int stock = 100;
    private final Object lock = new Object();
    
    // ✓ 적절한 범위
    public boolean reserve(Shipment shipment, int quantity) {
        // 비임계 — 병렬
        validateShipment(shipment);
        logRequest(shipment);
        
        // 임계 영역 (check-then-act 함께)
        synchronized (lock) {
            if (stock >= quantity) {   // 확인
                stock -= quantity;      // 차감 (함께 — 일관성)
                return true;
            }
            return false;
        }
        // ↑ check 와 act 를 분리하면 안 됨
    }
    
    public void process(Shipment shipment) {
        // 무거운 작업 병렬
        BigDecimal freight = calculate(shipment);
        
        // 짧은 임계 영역
        synchronized (lock) {
            recordStats(freight);
        }
        
        // 무거운 작업 병렬
        repository.save(shipment);
    }
    
    private void validateShipment(Shipment s) { }
    private void recordStats(BigDecimal f) { }
}

2.7 자기 점검 답변

동기화 범위 최소화는?

답:
1. 의미:

임계 영역만 동기화
나머지 병렬

효과:
- 병렬성 ↑
- 처리량 ↑
한계:
- 너무 좁으면 일관성 깨짐
- check-then-act 함께
균형:
- 적절한 범위

3️⃣ 잠금 대상 명시

3.1 명시적 잠금 대상

// 다양한 잠금 대상

// 1. this
synchronized (this) { }

// 2. Class 객체
synchronized (MyClass.class) { }

// 3. 별도 객체
private final Object lock = new Object();
synchronized (lock) { }

// 4. 공유 자원 자체
synchronized (sharedList) { }

3.2 this 잠금

public class Counter {
    private int count = 0;
    
    public void increment() {
        synchronized (this) {   // 인스턴스 락
            count++;
        }
    }
    // synchronized 메서드와 동일한 락 (this)
}

3.3 Class 잠금

public class Counter {
    private static int count = 0;
    
    public void increment() {
        synchronized (Counter.class) {   // Class 락
            count++;
        }
    }
    // static synchronized 와 동일한 락
}

3.4 별도 객체 잠금

public class Counter {
    private int count = 0;
    private final Object lock = new Object();   // 전용 락
    
    public void increment() {
        synchronized (lock) {   // 전용 락
            count++;
        }
    }
    // this 와 독립적
    // 외부에서 간섭 불가
}

3.5 여러 락 분리

public class MultiResource {
    private int countA = 0;
    private int countB = 0;
    private final Object lockA = new Object();
    private final Object lockB = new Object();
    
    public void incrementA() {
        synchronized (lockA) {
            countA++;   // A 만 (B 와 독립)
        }
    }
    
    public void incrementB() {
        synchronized (lockB) {
            countB++;   // B 만
        }
    }
    // incrementA 와 incrementB 동시 가능 (다른 락)
}

3.6 ILIC 의 맥락

@Service
public class ShipmentLockTargets {
    
    private int shipmentCount = 0;
    private BigDecimal totalRevenue = BigDecimal.ZERO;
    
    // 독립적 자원 → 다른 락
    private final Object countLock = new Object();
    private final Object revenueLock = new Object();
    
    public void incrementCount() {
        synchronized (countLock) {   // count 전용 락
            shipmentCount++;
        }
    }
    
    public void addRevenue(BigDecimal amount) {
        synchronized (revenueLock) {   // revenue 전용 락
            totalRevenue = totalRevenue.add(amount);
        }
    }
    // count 와 revenue 동시 갱신 가능 (다른 락)
    // 세밀한 동기화
}

3.7 자기 점검 답변

잠금 대상 명시는?

답:
1. 방법:

this
Class 객체
별도 객체
공유 자원

this:
- synchronized 메서드와 동일
별도 객체:
- 전용 락
- 외부 간섭 X
여러 락:
- 독립 자원 분리
- 세밀한 동기화

4️⃣ synchronized (this) vs new Object()

4.1 핵심 차이

synchronized (this) vs synchronized (new Object()):

synchronized (this):
  - 같은 객체의 this 락
  - 여러 스레드 공유
  - 정상 동기화

synchronized (new Object()):
  - 매번 새 객체 (다른 락)
  - 각 스레드 다른 락
  - 동기화 효과 없음! (버그)

4.2 new Object() 의 함정

// ❌ 동기화 효과 없음
public void brokenSync() {
    synchronized (new Object()) {   // 매번 새 객체!
        count++;
        // 각 스레드가 다른 락
        // → 서로 배타 X
        // → 동기화 안 됨
    }
}

// 스레드 A: new Object() → 락 A
// 스레드 B: new Object() → 락 B (다름!)
// → 동시 진입 (배타 X)
// → count++ 손실

4.3 왜 효과 없나

new Object() 가 효과 없는 이유:

  synchronized 는 같은 락 객체를 공유해야 배타.

  new Object() 매번:
    - 각 호출이 다른 객체
    - 다른 락
    - 서로 배타 안 됨

핵심:
  - 락은 공유되어야 의미
  - 매번 새 객체 = 공유 X

4.4 올바른 방법

// ✓ 공유 락 객체
public class Correct {
    private int count = 0;
    private final Object lock = new Object();   // 한 번 생성, 공유
    
    public void increment() {
        synchronized (lock) {   // 공유 락
            count++;
        }
    }
    // 모든 스레드가 같은 lock
    // → 배타 → 동기화 O
}

4.5 시각화

synchronized (lock) — 공유:
  스레드 A ─┐
  스레드 B ─┼→ 같은 lock 객체 (배타)
  스레드 C ─┘

synchronized (new Object()) — 매번 새로:
  스레드 A → 락 A
  스레드 B → 락 B   (서로 다름)
  스레드 C → 락 C
  → 배타 X (동기화 안 됨)

4.6 ILIC 의 맥락

@Service
public class LockObjectExample {
    
    private int counter = 0;
    
    // ❌ 버그 — 매번 새 객체
    public void incrementBroken() {
        synchronized (new Object()) {   // 효과 없음!
            counter++;   // 손실 발생
        }
    }
    
    // ✓ 올바름 — 공유 락
    private final Object lock = new Object();
    
    public void incrementCorrect() {
        synchronized (lock) {   // 공유 락
            counter++;   // 안전
        }
    }
    
    // ✓ this 도 가능
    public void incrementThis() {
        synchronized (this) {   // this 공유
            counter++;
        }
    }
}

4.7 자기 점검 답변

synchronized (this) vs new Object()?

답:
1. this:

공유 락 (this)
정상 동기화

new Object():
- 매번 새 객체
- 다른 락
- 효과 없음 (버그)
이유:
- 락은 공유되어야 배타
- 매번 새로 = 공유 X
올바름:
- private final 공유 락

5️⃣ 너무 넓은 임계 영역의 문제

5.1 넓은 임계 영역

너무 넓은 임계 영역:

  불필요한 코드까지 동기화.

문제:
  - 직렬화 (병렬성 ↓)
  - 락 점유 시간 ↑
  - 처리량 ↓
  - 데드락 위험 ↑

5.2 예시

// ❌ 너무 넓음
public void processWide(Shipment shipment) {
    synchronized (lock) {
        // 무거운 작업 (락 불필요)
        BigDecimal freight = expensiveCalc(shipment);   // 1초
        Tracking tracking = callApi(shipment);          // 2초 (I/O)
        
        // 실제 임계 영역
        counter++;
        
        // 무거운 작업 (락 불필요)
        repository.save(shipment);   // 0.5초
    }
    // 3.5초 동안 락 점유 → 다른 스레드 대기
}

5.3 I/O 를 락 안에 두는 위험

I/O 를 락 안에 두면:

  - 네트워크/DB 대기 동안 락 점유
  - 다른 스레드 모두 BLOCKED
  - 응답 지연
  - 처리량 급감

원칙:
  - I/O 는 락 밖에서
  - 락 안에는 메모리 연산만

5.4 개선

// ✓ 범위 최소화
public void processNarrow(Shipment shipment) {
    // 무거운 작업 (락 밖, 병렬)
    BigDecimal freight = expensiveCalc(shipment);
    Tracking tracking = callApi(shipment);
    
    // 임계 영역만 (메모리 연산)
    synchronized (lock) {
        counter++;
    }
    
    // 무거운 작업 (락 밖, 병렬)
    repository.save(shipment);
}

5.5 데드락 위험

넓은 범위 + 여러 락 = 데드락 위험:

  // ❌ 위험
  synchronized (lockA) {
      doSomething();
      synchronized (lockB) {   // 중첩 (데드락 가능)
          ...
      }
  }
  
  // 다른 스레드:
  synchronized (lockB) {
      synchronized (lockA) {   // 반대 순서 (데드락!)
          ...
      }
  }

핵심:
  - 락 점유 길수록 데드락 ↑
  - 중첩 락 순서 주의

5.6 ILIC 의 맥락

@Service
public class WideCriticalSectionProblem {
    
    private int counter = 0;
    private final Object lock = new Object();
    
    // ❌ I/O 를 락 안에 (위험)
    public void processBad(Shipment shipment) {
        synchronized (lock) {
            Tracking tracking = trackingApi.fetch(shipment.getBlNo());   // 2초 I/O
            // 모든 스레드가 2초씩 대기
            counter++;
            repository.save(shipment);   // 0.5초 I/O
        }
    }
    
    // ✓ I/O 는 락 밖
    public void processGood(Shipment shipment) {
        Tracking tracking = trackingApi.fetch(shipment.getBlNo());   // 병렬
        
        synchronized (lock) {
            counter++;   // 메모리 연산만
        }
        
        repository.save(shipment);   // 병렬
    }
}

5.7 자기 점검 답변

너무 넓은 임계 영역의 문제는?

답:
1. 문제:

직렬화
락 점유 시간 ↑
처리량 ↓

I/O 위험:
- 대기 중 락 점유
- 모든 스레드 BLOCKED
데드락:
- 점유 길수록 ↑
- 중첩 락 주의
원칙:
- I/O 는 락 밖
- 메모리 연산만

6️⃣ 메서드 vs 블록 선택

6.1 선택 기준

synchronized 메서드 vs 블록:

메서드 전체가 임계 영역:
  → synchronized 메서드

일부만 임계 영역:
  → synchronized 블록 (성능 ↑)

잠금 대상 제어 필요:
  → synchronized 블록

6.2 메서드가 적합

// 메서드 전체가 임계 영역
public synchronized void transfer(int amount) {
    // 모든 코드가 동기화 필요
    balance -= amount;
    history.add(new Transaction(amount));
    updateTimestamp();
    // 전체 일관성
}
// 블록으로 나눌 이유 없음

6.3 블록이 적합

// 일부만 임계 영역
public void process(Shipment shipment) {
    BigDecimal freight = calculate(shipment);   // 락 불필요
    
    synchronized (lock) {
        counter++;   // 이 부분만 임계 영역
    }
    
    save(shipment);   // 락 불필요
}
// 블록으로 범위 최소화

6.4 비교 표

기준	메서드	블록
범위	전체	일부
잠금 대상	this/Class 고정	자유
가독성	간결	명시적
성능	넓음 (느림)	좁음 (빠름)
적합	전체 임계	일부 임계

6.5 선택 가이드

선택 가이드:

1. 전체가 임계 영역?
   - Yes → 메서드
   - No → 블록

2. 잠금 대상 제어?
   - 필요 → 블록 (별도 락)
   - 불필요 → 메서드 (this)

3. 성능 중요?
   - Yes → 블록 (범위 최소화)

대부분:
  - 블록 권장 (범위 제어)
  - 또는 Atomic/동시성 컬렉션

6.6 ILIC 의 맥락

@Service
public class MethodVsBlockChoice {
    
    private int counter = 0;
    private final Object lock = new Object();
    private BigDecimal balance = BigDecimal.ZERO;
    
    // 메서드 — 전체가 임계 영역
    public synchronized void transfer(BigDecimal amount) {
        balance = balance.subtract(amount);
        recordTransaction(amount);
        // 전체 일관성 (메서드 적합)
    }
    
    // 블록 — 일부만 임계 영역
    public void processWithStats(Shipment shipment) {
        BigDecimal freight = calculate(shipment);   // 병렬
        
        synchronized (lock) {
            counter++;   // 임계 영역만
        }
        
        repository.save(shipment);   // 병렬
        // 블록 적합 (범위 최소화)
    }
    
    private void recordTransaction(BigDecimal amount) { }
    private BigDecimal calculate(Shipment s) { return s.getWeight(); }
}

6.7 자기 점검 답변

메서드 vs 블록 선택은?

답:
1. 메서드:

전체가 임계 영역
간결

블록:
- 일부만 임계 영역
- 잠금 대상 제어
- 성능 ↑
기준:
- 전체 임계: 메서드
- 일부: 블록
권장:
- 블록 (범위 제어)
- 또는 Atomic

7️⃣ private final 락 객체

7.1 전용 락 객체

public class SafeCounter {
    private int count = 0;
    private final Object lock = new Object();   // 전용 락
    
    public void increment() {
        synchronized (lock) {
            count++;
        }
    }
}

7.2 왜 private final

private final 락 객체의 이유:

private:
  - 외부에서 접근 불가
  - 외부가 락 못 건드림

final:
  - 락 객체 불변
  - 다른 객체로 교체 X
  - 일관된 락

7.3 this 잠금의 위험

// ❌ this 잠금의 위험
public class RiskyThis {
    public synchronized void method() {   // this 락
        count++;
    }
}

// 외부에서:
RiskyThis obj = new RiskyThis();
synchronized (obj) {   // ★ 외부가 같은 락 점유!
    // 오래 점유하면
    // obj.method() 가 영원히 대기
}
// 외부 코드가 동기화 간섭

7.4 전용 락의 안전성

// ✓ 전용 락 (안전)
public class SafeLock {
    private int count = 0;
    private final Object lock = new Object();   // private
    
    public void method() {
        synchronized (lock) {   // 외부가 모르는 락
            count++;
        }
    }
}

// 외부에서:
SafeLock obj = new SafeLock();
// synchronized (obj.lock)   // ❌ 접근 불가 (private)
// 외부가 간섭 못 함

7.5 락 객체 패턴

// 락 객체 명명 패턴
public class LockPatterns {
    
    // 단일 락
    private final Object lock = new Object();
    
    // 여러 락 (자원별)
    private final Object readLock = new Object();
    private final Object writeLock = new Object();
    
    // 의미 있는 이름
    private final Object stockLock = new Object();
    private final Object historyLock = new Object();
    
    // final 필수 (불변)
    // private 필수 (캡슐화)
}

7.6 ILIC 의 맥락

@Service
public class ShipmentPrivateLock {
    
    private int counter = 0;
    private final List<Shipment> history = new ArrayList<>();
    
    // 전용 락 (private final)
    private final Object counterLock = new Object();
    private final Object historyLock = new Object();
    
    public void incrementCounter() {
        synchronized (counterLock) {   // 외부 간섭 X
            counter++;
        }
    }
    
    public void addHistory(Shipment shipment) {
        synchronized (historyLock) {   // 독립 락
            history.add(shipment);
        }
    }
    // 외부에서 락에 접근 불가
    // 안전한 동기화
    // counter 와 history 독립 (다른 락)
}

7.7 자기 점검 답변

private final 락 객체를 쓰는 이유는?

답:
1. private:

외부 접근 불가
간섭 방지

final:
- 락 불변
- 일관성
this 위험:
- 외부가 같은 락 점유
- 동기화 간섭
전용 락:
- 캡슐화
- 안전

8️⃣ 여러 락 객체 (세밀한 동기화)

8.1 락 분리

여러 락 객체:

  독립적 자원에 별도 락.

효과:
  - 세밀한 동기화
  - 병렬성 ↑
  - 불필요한 경합 방지

8.2 단일 락의 문제

// ❌ 단일 락 (불필요한 경합)
public class SingleLock {
    private int countA = 0;
    private int countB = 0;
    private final Object lock = new Object();
    
    public void incA() {
        synchronized (lock) {   // A 갱신에 lock
            countA++;
        }
    }
    
    public void incB() {
        synchronized (lock) {   // B 갱신도 같은 lock!
            countB++;
        }
    }
    // A 와 B 는 독립인데 같은 락
    // → incA, incB 동시 불가 (불필요한 경합)
}

8.3 락 분리

// ✓ 락 분리 (세밀)
public class SeparateLocks {
    private int countA = 0;
    private int countB = 0;
    private final Object lockA = new Object();
    private final Object lockB = new Object();
    
    public void incA() {
        synchronized (lockA) {   // A 전용
            countA++;
        }
    }
    
    public void incB() {
        synchronized (lockB) {   // B 전용
            countB++;
        }
    }
    // A 와 B 독립 → incA, incB 동시 가능
    // 병렬성 ↑
}

8.4 lock striping

// Lock Striping — 여러 락으로 분할
public class StripedMap {
    private static final int STRIPES = 16;
    private final Object[] locks = new Object[STRIPES];
    private final Map<String, String>[] segments;
    
    public StripedMap() {
        for (int i = 0; i < STRIPES; i++) {
            locks[i] = new Object();
        }
        // ... segments 초기화
    }
    
    public void put(String key, String value) {
        int stripe = Math.abs(key.hashCode() % STRIPES);
        synchronized (locks[stripe]) {   // 키별 다른 락
            segments[stripe].put(key, value);
        }
    }
    // 다른 키 → 다른 락 → 동시 가능
    // ConcurrentHashMap 의 아이디어
}

8.5 데드락 주의

// 여러 락 사용 시 데드락 주의
// ❌ 락 순서 불일치
public void transfer(Account from, Account to, int amount) {
    synchronized (from) {
        synchronized (to) {   // 순서: from → to
            // ...
        }
    }
}
// 스레드 A: transfer(acc1, acc2)  → acc1 → acc2
// 스레드 B: transfer(acc2, acc1)  → acc2 → acc1
// → 데드락! (순환 대기)

// ✓ 일관된 순서 (예: id 순)
public void transferSafe(Account from, Account to, int amount) {
    Account first = from.getId() < to.getId() ? from : to;
    Account second = from.getId() < to.getId() ? to : from;
    synchronized (first) {
        synchronized (second) {   // 항상 id 순
            // ...
        }
    }
}

8.6 ILIC 의 맥락

@Service
public class ShipmentMultiLock {
    
    private final Map<String, BigDecimal> revenueByRoute = new HashMap<>();
    private final Map<String, Integer> countByRoute = new HashMap<>();
    
    // 라우트별 락 (세밀)
    private final Map<String, Object> routeLocks = new ConcurrentHashMap<>();
    
    private Object getLock(String route) {
        return routeLocks.computeIfAbsent(route, k -> new Object());
    }
    
    public void record(String route, BigDecimal revenue) {
        Object lock = getLock(route);
        synchronized (lock) {   // 라우트별 락
            revenueByRoute.merge(route, revenue, BigDecimal::add);
            countByRoute.merge(route, 1, Integer::sum);
        }
        // 다른 라우트 → 다른 락 → 동시 가능
    }
    
    // 실무: ConcurrentHashMap + AtomicReference 권장
}

8.7 자기 점검 답변

여러 락 객체로 세밀한 동기화는?

답:
1. 락 분리:

독립 자원 별도 락
병렬성 ↑

단일 락 문제:
- 불필요한 경합
- 독립 자원도 직렬화
Lock Striping:
- 여러 락 분할
- ConcurrentHashMap
데드락 주의:
- 락 순서 일관성

9️⃣ 면접 + 자기 점검

9.1 면접 단골 질문 매핑

Q	핵심 답변
synchronized 블록?	일부만 동기화
범위 최소화?	임계 영역만, 성능 ↑
잠금 대상?	this/Class/별도 객체
new Object() 매번?	효과 없음 (다른 락)
넓은 범위 문제?	직렬화, I/O 위험
메서드 vs 블록?	전체 vs 일부
private final 락?	외부 간섭 방지
여러 락?	세밀한 동기화
Lock Striping?	분할 락 (ConcurrentHashMap)
데드락 방지?	락 순서 일관

9.2 자기 점검 체크리스트

블록

정의
문법
동작

범위 최소화

의미
효과
한계 (일관성)

잠금 대상

this/Class/객체
new Object() 함정

넓은 범위

직렬화
I/O 위험

메서드 vs 블록

선택 기준

락 객체

private final
여러 락
데드락

9.3 추가 심화 질문

Q1: synchronized 블록의 바이트코드?

답:

monitorenter (진입)
monitorexit (종료)
예외 시에도 monitorexit (보장)
메서드는 플래그 (ACC_SYNCHRONIZED)

Q2: 락 객체로 String 리터럴?

답:

위험
String 리터럴은 상수 풀 공유
다른 코드가 같은 리터럴 락
의도치 않은 경합
→ 전용 Object 권장

Q3: synchronized 블록 안에서 예외?

답:

monitorexit 보장 (락 반납)
finally 처럼 동작
예외 전파되지만 락은 반납
데드락 방지

Q4: 이중 검사 잠금 (Double-Checked Locking)?

답:

if (instance == null) {           // 1차 (락 없이)
    synchronized (lock) {
        if (instance == null) {   // 2차 (락 안)
            instance = new ...;
        }
    }
}
// volatile 필수 (가시성)

Q5: synchronized vs Atomic 성능?

답:

경합 적으면: Atomic (CAS) 빠름
경합 많으면: 상황 따라
Atomic: lock-free
synchronized: 락 (Java 6+ 최적화)

🎯 핵심 요약 — 3줄 정리

1. synchronized 블록

일부만 동기화 (범위 최소화)
잠금 대상 명시 (this/Class/별도 객체)

2. 주의점

new Object() 매번 = 효과 없음
넓은 범위 = 직렬화 (I/O 는 락 밖)
private final 락 (외부 간섭 방지)

3. 세밀한 동기화

여러 락 객체 (독립 자원)
Lock Striping
데드락 (락 순서 일관)

📚 다음으로...

Unit 4.4 — 모니터 락(Monitor Lock)의 동작 (★ 마스터)

이번 Unit에서 synchronized 블록을 봤다면, 다음은 모니터 락의 내부 동작 (★ 마스터, 면접 단골).

모든 객체의 모니터 락
intrinsic lock
BLOCKED 와 락 경쟁
공정성
synchronized 의 한계
마스터 Unit (50문항)

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 (★ 마스터)

4주차 누적 진행

✅ Phase 1 — 동시성의 기초 (4 Unit)
✅ Phase 2 — 4분면 매트릭스 (3 Unit)
✅ Phase 3 — 스레드 다루기 (5 Unit)
🚀 Phase 4 — synchronized & volatile (3/5 진행) ★ 1차 정점

총: 15/35 Unit

4주차 Unit 4.3 — synchronized 블록

댓글