Unit 5.4 — tryLock()으로 데드락 회피
F-LAB JAVA · 4주차 · Phase 5 · 정교한 락: LockSupport와 ReentrantLock
★ 마스터 Unit (실무 직결) + 🏆 Phase 5 완주
📌 학습 목표
이 Unit을 끝내면 다음을 답할 수 있어야 한다.
- tryLock() 의 두 형태 (즉시 / 타임아웃) 는?
- 데드락 (Deadlock) 의 4가지 조건 은?
- 데드락 회피 시나리오 (락1·락2 순환) 는?
- lock() 이면 영원히 멈추는 이유는?
- tryLock() 으로 데드락 회피 하는 원리는?
- lock() 만 쓰는 시스템에서 데드락 회복 방법은?
- tryLock(5, SECONDS) 실패 후 전략 은?
- 락 순서 일관성 으로 데드락 방지는?
- 실무의 데드락 진단/예방 은?
🎯 핵심 한 문장
tryLock()은 락 획득을 시도하되 실패하면 즉시 (또는 타임아웃 후) 포기하는 메서드로, 무한 대기 대신 포기·재시도를 가능하게 하여 데드락을 회피한다.
boolean tryLock()은 즉시 시도하여 실패 시 false 를 반환하고,boolean tryLock(time, unit)은 지정 시간만큼 시도한 후 실패하면 false 를 반환한다.
데드락은 두 스레드가 서로 다른 순서로 두 락을 잡으려 할 때 (A 가 락1 보유·락2 대기, B 가 락2 보유·락1 대기) 발생하며,lock()을 쓰면 둘 다 영원히 대기 하지만tryLock()을 쓰면 한 쪽이 포기하고 보유 락을 풀어 데드락을 회피 한다.
lock()만 쓰는 시스템에서 데드락이 발생하면 회복 방법이 없어 재시작뿐 이므로, tryLock 으로 타임아웃·재시도를 두거나 모든 스레드가 락을 항상 같은 순서로 획득 하도록 (락 순서 일관성) 설계해야 한다.
tryLock(timeout) 실패 후에는 백오프 (backoff) 후 재시도, 대체 경로, 또는 작업 포기 등의 전략을 사용한다.
비유 — 좁은 다리에서 마주친 두 사람
데드락 = 좁은 외나무다리:
상황:
- A 가 왼쪽에서, B 가 오른쪽에서
- 다리 중간에서 마주침
- 서로 비켜주길 기다림
- 영원히 멈춤 (데드락)
lock() = 고집:
- "당신이 비켜요"
- 둘 다 안 비킴
- 영원히 (회복 불가)
tryLock() = 양보:
- "5초 기다려봤는데 안 되네"
- 한 명이 뒤로 물러남 (포기)
- 다시 시도 (재시도)
- 데드락 회피
락 순서 일관성 = 규칙:
- "항상 키 작은 사람이 먼저"
- 순서 정하면 마주침 없음
- 데드락 원천 차단→ tryLock = 포기/재시도로 데드락 회피, 락 순서 일관 = 원천 방지.
🧭 9개 섹션 로드맵
1. tryLock()의 두 형태
2. 데드락의 4가지 조건
3. 데드락 시나리오
4. lock()이면 영원히 멈춤
5. tryLock()으로 회피
6. lock()만 쓰는 시스템의 회복
7. tryLock 실패 후 전략
8. 락 순서 일관성
9. 면접 + 자기 점검 + 마스터 50문항 + Phase 5 완주1️⃣ tryLock()의 두 형태
1.1 두 형태
// 1. 즉시 시도
boolean tryLock();
// 2. 타임아웃 시도
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;1.2 즉시 tryLock()
// 즉시 시도 (실패 시 false)
if (lock.tryLock()) {
try {
// 락 획득 성공
doWork();
} finally {
lock.unlock();
}
} else {
// 락 획득 실패 (즉시)
log.info("이미 처리중인 작업이 있습니다.");
// 대기 안 함
}1.3 타임아웃 tryLock(time, unit)
// 타임아웃 시도
try {
if (lock.tryLock(5, TimeUnit.SECONDS)) {
try {
// 5초 내 획득 성공
doWork();
} finally {
lock.unlock();
}
} else {
// 5초 내 실패
log.warn("락 획득 타임아웃");
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}1.4 lock() 과 비교
lock vs tryLock:
lock():
- 무한 대기
- 반드시 획득 (또는 영원히)
tryLock():
- 즉시 시도
- 실패 시 false (대기 X)
tryLock(time):
- 시간 내 시도
- 실패 시 false1.5 반환값 처리
// tryLock 반환값 반드시 확인
boolean acquired = lock.tryLock();
if (acquired) {
try {
// 임계 영역
} finally {
lock.unlock(); // 획득했을 때만
}
}
// 획득 못 했으면 unlock 호출 X (예외)1.6 ILIC 의 맥락
@Service
public class TryLockBasics {
private final ReentrantLock lock = new ReentrantLock();
// 즉시 시도 — 중복 처리 방지
public boolean processIfAvailable(Shipment shipment) {
if (lock.tryLock()) { // 즉시
try {
doProcess(shipment);
return true;
} finally {
lock.unlock();
}
}
log.info("이미 처리중: {}", shipment.getId());
return false; // 다른 스레드가 처리 중
}
// 타임아웃 시도
public boolean processWithTimeout(Shipment shipment) throws InterruptedException {
if (lock.tryLock(5, TimeUnit.SECONDS)) { // 5초
try {
doProcess(shipment);
return true;
} finally {
lock.unlock();
}
}
log.warn("처리 타임아웃: {}", shipment.getId());
return false;
}
private void doProcess(Shipment s) { }
}1.7 자기 점검 답변
tryLock()의 두 형태는?
답:
1. 즉시 tryLock():
- 시도, 실패 시 false
- 대기 X
-
타임아웃 tryLock(time):
- 시간 내 시도
- 실패 시 false
-
vs lock():
- lock: 무한 대기
- tryLock: 포기 가능
-
반환값:
- 확인 후 unlock
2️⃣ 데드락의 4가지 조건
2.1 4가지 조건
데드락 4가지 조건 (모두 충족 시):
1. 상호 배제 (Mutual Exclusion)
- 자원을 한 번에 하나만
2. 점유 대기 (Hold and Wait)
- 자원 보유한 채 다른 자원 대기
3. 비선점 (No Preemption)
- 자원 강제 회수 불가
4. 순환 대기 (Circular Wait)
- 서로 순환적으로 대기2.2 각 조건
상호 배제:
- synchronized, lock
- 한 스레드만 임계 영역
점유 대기:
- 락A 보유 + 락B 대기
비선점:
- 락 강제로 뺏기 불가
- 스스로 풀어야
순환 대기:
- A→B→A 순환
- 서로 기다림2.3 데드락 방지 = 조건 깨기
데드락 방지 — 조건 하나 깨기:
1. 상호 배제 깨기:
- 어려움 (락의 본질)
2. 점유 대기 깨기:
- 모든 락 한 번에 (전부 또는 포기)
3. 비선점 깨기:
- tryLock (타임아웃 → 포기)
4. 순환 대기 깨기:
- 락 순서 일관 (가장 실용적)2.4 시각화
데드락 4조건:
스레드 A: 락1 보유 ──점유대기──→ 락2 대기
↑
순환대기
↓
스레드 B: 락2 보유 ──점유대기──→ 락1 대기
상호 배제 + 점유 대기 + 비선점 + 순환 대기
→ 데드락2.5 ILIC 의 맥락
// 데드락 4조건이 충족되는 예
public class DeadlockConditions {
private final ReentrantLock lockA = new ReentrantLock();
private final ReentrantLock lockB = new ReentrantLock();
// 스레드 1
public void method1() {
lockA.lock(); // 1. 상호 배제 (A)
try {
// 2. 점유 대기 (A 보유한 채)
lockB.lock(); // B 대기
try {
// ...
} finally {
lockB.unlock();
}
} finally {
lockA.unlock(); // 3. 비선점 (스스로만)
}
}
// 스레드 2 (반대 순서)
public void method2() {
lockB.lock(); // B 먼저
try {
lockA.lock(); // A 대기 (4. 순환 대기)
try {
// ...
} finally {
lockA.unlock();
}
} finally {
lockB.unlock();
}
}
// method1 + method2 동시 → 데드락
}2.6 자기 점검 답변
데드락의 4가지 조건은?
답:
1. 4가지:
- 상호 배제
- 점유 대기
- 비선점
- 순환 대기
-
모두 충족:
- 4개 모두 시 데드락
-
방지:
- 하나 깨기
- 순환 대기 깨기 (실용)
-
tryLock:
- 비선점 깨기 (포기)
3️⃣ 데드락 시나리오
3.1 고전 시나리오
계좌 이체 데드락:
스레드 1: transfer(accA, accB)
- accA 락 획득
- accB 락 대기
스레드 2: transfer(accB, accA)
- accB 락 획득
- accA 락 대기
→ 서로 대기 → 데드락3.2 코드
public class TransferDeadlock {
static class Account {
final ReentrantLock lock = new ReentrantLock();
int balance;
}
// ❌ 데드락 위험
public void transfer(Account from, Account to, int amount) {
from.lock.lock(); // from 먼저
try {
to.lock.lock(); // to 대기
try {
from.balance -= amount;
to.balance += amount;
} finally {
to.lock.unlock();
}
} finally {
from.lock.unlock();
}
}
// 데드락 발생:
// 스레드 1: transfer(accA, accB) → accA → accB
// 스레드 2: transfer(accB, accA) → accB → accA
// → 순환 대기
}3.3 시각화
이체 데드락:
스레드 1: transfer(A, B)
A.lock() 성공
B.lock() 대기 ───┐
│ (B 는 스레드 2 보유)
스레드 2: transfer(B, A)
B.lock() 성공
A.lock() 대기 ───┘
(A 는 스레드 1 보유)
서로 대기 → 영원히3.4 발생 타이밍
데드락 발생 타이밍:
타이밍 의존 (비결정적):
- 동시에 두 transfer
- 각자 첫 락 획득
- 두 번째 락 대기
가끔 발생:
- 운 나쁘면 데드락
- 재현 어려움
- 운영 중 갑자기3.5 ILIC 의 맥락
@Service
public class ShipmentTransferDeadlock {
// ❌ 데드락 위험 — 계정 간 잔액 이체
public void transferBalance(ShipmentAccount from, ShipmentAccount to,
BigDecimal amount) {
from.lock.lock();
try {
to.lock.lock(); // 순서 불일치 시 데드락
try {
from.balance = from.balance.subtract(amount);
to.balance = to.balance.add(amount);
} finally {
to.lock.unlock();
}
} finally {
from.lock.unlock();
}
}
// transferBalance(accA, accB) 와
// transferBalance(accB, accA) 동시 → 데드락
static class ShipmentAccount {
final ReentrantLock lock = new ReentrantLock();
BigDecimal balance = BigDecimal.ZERO;
}
}3.6 자기 점검 답변
데드락 시나리오는?
답:
1. 시나리오:
- A 가 락1 보유 + 락2 대기
- B 가 락2 보유 + 락1 대기
-
이체 예:
- transfer(A,B) + transfer(B,A)
- 순서 불일치
-
타이밍:
- 비결정적
- 가끔 발생
-
결과:
- 서로 대기
- 영원히
4️⃣ lock()이면 영원히 멈춤
4.1 lock() 의 무한 대기
lock() 데드락:
두 스레드 모두 lock() 사용:
- 첫 락 획득
- 두 번째 락 무한 대기
→ 서로 대기
→ 영원히 멈춤
→ 회복 불가4.2 회복 불가
lock() 데드락 회복 불가:
- 타임아웃 X (무한 대기)
- 인터럽트 X (lock() 은)
- 자원 강제 회수 X (비선점)
→ 회복 방법 없음
→ 재시작뿐4.3 시각화
lock() 데드락:
스레드 1: A.lock() 성공
B.lock() [무한 대기──────────]
↑ 영원히
스레드 2: B.lock() 성공
A.lock() [무한 대기──────────]
↑ 영원히
→ 둘 다 영원히
→ 회복 불가4.4 운영 영향
운영 영향:
- 두 스레드 영원히 점유
- 관련 자원 락
- 스레드 풀 고갈 가능
- 서비스 장애
진단:
- jstack → "deadlock" 감지
- 하지만 회복 불가 (재시작)4.5 jstack 데드락 감지
$ jstack <pid>
# 데드락 감지:
Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor ... (Account B)
which is held by "Thread-2"
"Thread-2":
waiting to lock monitor ... (Account A)
which is held by "Thread-1"
# jstack 이 데드락 알려줌
# 하지만 lock() 은 회복 불가4.6 ILIC 의 맥락
@Service
public class LockDeadlockProblem {
private final ReentrantLock lockA = new ReentrantLock();
private final ReentrantLock lockB = new ReentrantLock();
// ❌ lock() — 데드락 시 회복 불가
public void process1() {
lockA.lock();
try {
sleep(100);
lockB.lock(); // 무한 대기 (데드락 시)
try {
doWork();
} finally {
lockB.unlock();
}
} finally {
lockA.unlock();
}
}
public void process2() {
lockB.lock(); // 반대 순서
try {
sleep(100);
lockA.lock(); // 무한 대기
try {
doWork();
} finally {
lockA.unlock();
}
} finally {
lockB.unlock();
}
}
// 동시 호출 시 데드락 → 재시작뿐
private void doWork() { }
private void sleep(long ms) { try { Thread.sleep(ms); } catch (Exception e) {} }
}4.7 자기 점검 답변
lock()이면 영원히 멈추는 이유는?
답:
1. 무한 대기:
- lock() 은 타임아웃 X
- 둘 다 두 번째 락 대기
-
회복 불가:
- 타임아웃/인터럽트 X
- 강제 회수 X
-
운영 영향:
- 스레드 점유
- 서비스 장애
-
진단:
- jstack (감지)
- 하지만 재시작뿐
5️⃣ tryLock()으로 회피
5.1 회피 원리
tryLock 데드락 회피:
두 번째 락을 tryLock 으로:
- 실패 시 첫 락도 풀기
- 재시도
→ 한 쪽이 양보
→ 순환 대기 깨짐
→ 데드락 회피5.2 코드
// ✓ tryLock 으로 데드락 회피
public boolean transfer(Account from, Account to, int amount)
throws InterruptedException {
while (true) {
if (from.lock.tryLock()) { // 첫 락 시도
try {
if (to.lock.tryLock()) { // 두 번째 시도
try {
from.balance -= amount;
to.balance += amount;
return true; // 성공
} finally {
to.lock.unlock();
}
}
// to 실패 → from 도 풀고 재시도
} finally {
from.lock.unlock();
}
}
// 둘 다 못 얻음 → 잠시 후 재시도
Thread.sleep(10); // 백오프
}
}5.3 회피 메커니즘
회피 메커니즘:
스레드 1: from.tryLock() 성공
to.tryLock() 실패
→ from 풀기 (양보)
→ 재시도
스레드 2: 그 사이 to, from 획득
→ 처리 완료
한 쪽 양보 → 데드락 깨짐5.4 시각화
tryLock 회피:
스레드 1: A.tryLock() 성공
B.tryLock() 실패 → A 풀기 (양보)
[잠시 대기]
재시도...
스레드 2: B 보유
A.tryLock() 성공 (1 이 풀었으니)
처리 완료
B, A 풀기
스레드 1: 재시도 → A, B 획득 → 완료
→ 데드락 회피 (양보 + 재시도)5.5 타임아웃 버전
// 타임아웃 tryLock 회피
public boolean transferWithTimeout(Account from, Account to, int amount)
throws InterruptedException {
long timeout = 1000;
if (from.lock.tryLock(timeout, TimeUnit.MILLISECONDS)) {
try {
if (to.lock.tryLock(timeout, TimeUnit.MILLISECONDS)) {
try {
from.balance -= amount;
to.balance += amount;
return true;
} finally {
to.lock.unlock();
}
}
} finally {
from.lock.unlock();
}
}
return false; // 타임아웃 → 포기 (데드락 회피)
}5.6 ILIC 의 맥락
@Service
public class TryLockDeadlockAvoidance {
// ✓ tryLock — 데드락 회피
public boolean transferBalance(ShipmentAccount from, ShipmentAccount to,
BigDecimal amount) throws InterruptedException {
int retries = 0;
while (retries < 10) {
if (from.lock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
if (to.lock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
from.balance = from.balance.subtract(amount);
to.balance = to.balance.add(amount);
return true;
} finally {
to.lock.unlock();
}
}
// to 실패 → from 풀고 재시도
} finally {
from.lock.unlock();
}
}
retries++;
Thread.sleep(ThreadLocalRandom.current().nextInt(50)); // 랜덤 백오프
}
log.warn("이체 실패 (재시도 초과)");
return false;
}
static class ShipmentAccount {
final ReentrantLock lock = new ReentrantLock();
BigDecimal balance = BigDecimal.ZERO;
}
}5.7 자기 점검 답변
tryLock()으로 회피하는 원리는?
답:
1. 원리:
- 두 번째 락 tryLock
- 실패 시 첫 락 풀기
- 재시도
-
메커니즘:
- 한 쪽 양보
- 순환 대기 깨짐
-
타임아웃:
- tryLock(time)
- 포기
-
재시도:
- 백오프 (랜덤)
6️⃣ lock()만 쓰는 시스템의 회복
6.1 회복 방법
lock() 만 쓰는 시스템 데드락 회복:
근본적으로 회복 불가:
- 타임아웃 X
- 인터럽트 X (lock())
유일한 방법:
- 프로세스 재시작6.2 재시작뿐
회복 = 재시작:
데드락 발생:
- 두 스레드 영원히
- 자원 점유
회복:
- 서버 재시작
- 데드락 스레드 강제 종료
- (다른 방법 없음)
비용:
- 다운타임
- 진행 중 작업 손실6.3 사전 방지가 답
사후 회복 불가 → 사전 방지:
lock() 데드락은 회복 불가하므로
사전 방지가 유일한 해결.
방지:
1. 락 순서 일관 (섹션 8)
2. tryLock 사용 (타임아웃)
3. 락 최소화
4. 단일 락6.4 모니터링
// 데드락 감지 (ThreadMXBean)
public class DeadlockDetector {
public void detectDeadlock() {
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] deadlocked = bean.findDeadlockedThreads();
if (deadlocked != null) {
log.error("데드락 감지! {} 스레드", deadlocked.length);
ThreadInfo[] infos = bean.getThreadInfo(deadlocked);
for (ThreadInfo info : infos) {
log.error("Deadlocked: {}", info.getThreadName());
}
// 알림 발송 → 운영자가 재시작 판단
// (자동 회복 불가)
}
}
}6.5 변환 — lock → tryLock
// ❌ lock() (회복 불가)
public void process() {
lockA.lock();
try {
lockB.lock(); // 데드락 시 무한
try { } finally { lockB.unlock(); }
} finally { lockA.unlock(); }
}
// ✓ tryLock (회피 가능)
public boolean processSafe() throws InterruptedException {
if (lockA.tryLock(1, TimeUnit.SECONDS)) {
try {
if (lockB.tryLock(1, TimeUnit.SECONDS)) {
try { return true; }
finally { lockB.unlock(); }
}
} finally { lockA.unlock(); }
}
return false; // 포기 (회복)
}6.6 ILIC 의 맥락
@Service
public class DeadlockRecoveryStrategy {
// 데드락 감지 + 알림 (회복은 재시작)
@Scheduled(fixedRate = 30000)
public void monitorDeadlock() {
ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] deadlocked = bean.findDeadlockedThreads();
if (deadlocked != null) {
alertService.sendCritical("데드락 감지! 재시작 필요");
// lock() 데드락은 자동 회복 불가
// → 운영자 개입 (재시작)
}
}
// 예방 — tryLock 으로 전환
private final ReentrantLock lock1 = new ReentrantLock();
private final ReentrantLock lock2 = new ReentrantLock();
public boolean safeProcess() throws InterruptedException {
if (lock1.tryLock(1, TimeUnit.SECONDS)) {
try {
if (lock2.tryLock(1, TimeUnit.SECONDS)) {
try {
doWork();
return true;
} finally {
lock2.unlock();
}
}
} finally {
lock1.unlock();
}
}
return false; // 데드락 회피
}
private void doWork() { }
}6.7 자기 점검 답변
lock()만 쓰는 시스템에서 데드락 회복 방법은?
답:
1. 회복 불가:
- 타임아웃/인터럽트 X
- 재시작뿐
-
재시작:
- 강제 종료
- 다운타임
-
사전 방지:
- 락 순서 일관
- tryLock
-
모니터링:
- ThreadMXBean
- 감지 → 알림
7️⃣ tryLock 실패 후 전략
7.1 실패 후 전략들
tryLock(5, SECONDS) 실패 후:
1. 재시도 (백오프)
- 잠시 후 다시
- 랜덤 백오프
2. 대체 경로
- 다른 방법으로
3. 작업 포기
- 사용자에게 알림
- 나중에
4. 큐에 적재
- 비동기 처리7.2 백오프 재시도
// 백오프 재시도
public boolean processWithRetry(Shipment shipment) throws InterruptedException {
int maxRetries = 5;
long backoff = 100;
for (int i = 0; i < maxRetries; i++) {
if (lock.tryLock(1, TimeUnit.SECONDS)) {
try {
doProcess(shipment);
return true;
} finally {
lock.unlock();
}
}
// 실패 → 백오프 후 재시도
Thread.sleep(backoff + ThreadLocalRandom.current().nextLong(50));
backoff *= 2; // 지수 백오프
}
return false; // 최종 실패
}7.3 지수 백오프 + 지터
지수 백오프 (Exponential Backoff):
재시도마다 대기 시간 증가:
- 1차: 100ms
- 2차: 200ms
- 3차: 400ms
- ...
지터 (Jitter):
- 랜덤 추가
- 동시 재시도 분산
- 충돌 방지
backoff = base * 2^retry + random7.4 대체 경로
// 대체 경로
public Result process(Shipment shipment) throws InterruptedException {
if (lock.tryLock(5, TimeUnit.SECONDS)) {
try {
return processFast(shipment); // 빠른 경로
} finally {
lock.unlock();
}
}
// 락 못 얻음 → 대체 경로
return processSlow(shipment); // 락 없는 느린 경로
}
private Result processFast(Shipment s) { return null; }
private Result processSlow(Shipment s) { return null; }7.5 큐 적재
// 큐에 적재 (비동기)
public void process(Shipment shipment) throws InterruptedException {
if (lock.tryLock(1, TimeUnit.SECONDS)) {
try {
doProcess(shipment);
} finally {
lock.unlock();
}
} else {
// 락 못 얻음 → 큐에 적재
deferredQueue.offer(shipment);
log.info("나중 처리 큐에 적재: {}", shipment.getId());
}
}7.6 ILIC 의 맥락
@Service
public class TryLockFailureStrategy {
private final ReentrantLock lock = new ReentrantLock();
private final BlockingQueue<Shipment> deferredQueue = new LinkedBlockingQueue<>();
public ProcessResult process(Shipment shipment) throws InterruptedException {
// 1. 즉시 시도 + 백오프 재시도
long backoff = 100;
for (int i = 0; i < 3; i++) {
if (lock.tryLock(2, TimeUnit.SECONDS)) {
try {
doProcess(shipment);
return ProcessResult.success();
} finally {
lock.unlock();
}
}
Thread.sleep(backoff + ThreadLocalRandom.current().nextLong(50));
backoff *= 2; // 지수 백오프
}
// 2. 재시도 실패 → 큐 적재 (대체 전략)
deferredQueue.offer(shipment);
log.warn("처리 지연: {} (큐 적재)", shipment.getId());
return ProcessResult.deferred();
}
private void doProcess(Shipment s) { }
record ProcessResult(String status) {
static ProcessResult success() { return new ProcessResult("SUCCESS"); }
static ProcessResult deferred() { return new ProcessResult("DEFERRED"); }
}
}7.7 자기 점검 답변
tryLock(5, SECONDS) 실패 후 전략은?
답:
1. 재시도:
- 백오프
- 지수 백오프 + 지터
-
대체 경로:
- 락 없는 방법
-
작업 포기:
- 알림
-
큐 적재:
- 비동기 처리
- 나중에
8️⃣ 락 순서 일관성
8.1 순환 대기 깨기
락 순서 일관성:
모든 스레드가 락을 항상 같은 순서로 획득.
효과:
- 순환 대기 불가
- 데드락 원천 방지
가장 실용적인 방법8.2 순서 정하기
// 락에 순서 부여 (예: id)
public void transferOrdered(Account from, Account to, int amount) {
// id 작은 것 먼저 (일관된 순서)
Account first = from.id < to.id ? from : to;
Account second = from.id < to.id ? to : from;
first.lock.lock(); // 항상 작은 id 먼저
try {
second.lock.lock();
try {
from.balance -= amount;
to.balance += amount;
} finally {
second.lock.unlock();
}
} finally {
first.lock.unlock();
}
}
// 모든 스레드가 id 순서 → 순환 X → 데드락 X8.3 왜 효과적
순서 일관성이 효과적인 이유:
순환 대기 (조건 4) 를 깸:
- 모두 같은 순서
- A→B 만 (B→A 없음)
- 순환 불가
예:
스레드 1: A→B
스레드 2: A→B (같은 순서)
→ 순환 X
→ 데드락 X8.4 시각화
순서 일관:
스레드 1: A.lock()→B.lock() (A 먼저)
스레드 2: A.lock()→B.lock() (A 먼저, 같음)
- 스레드 1 이 A 보유 시
- 스레드 2 는 A 대기 (B 안 잡음)
- 1 이 A,B 처리 후 풀면
- 2 가 진행
→ 순환 X → 데드락 X8.5 해시 기반 순서
// id 없으면 해시 기반
public void transfer(Object lockA, Object lockB) {
int hashA = System.identityHashCode(lockA);
int hashB = System.identityHashCode(lockB);
Object first = hashA < hashB ? lockA : lockB;
Object second = hashA < hashB ? lockB : lockA;
synchronized (first) {
synchronized (second) {
// 일관된 순서
}
}
// 해시 같으면 (드물게) 타이브레이커 락 추가
}8.6 ILIC 의 맥락
@Service
public class LockOrderingConsistency {
// ✓ 락 순서 일관 (id 기반)
public void transferBalance(ShipmentAccount from, ShipmentAccount to,
BigDecimal amount) {
// 항상 id 작은 것 먼저 (순환 방지)
ShipmentAccount first = from.id < to.id ? from : to;
ShipmentAccount second = from.id < to.id ? to : from;
first.lock.lock();
try {
second.lock.lock();
try {
from.balance = from.balance.subtract(amount);
to.balance = to.balance.add(amount);
} finally {
second.lock.unlock();
}
} finally {
first.lock.unlock();
}
// 모든 스레드 같은 순서 → 데드락 X
}
static class ShipmentAccount {
final long id;
final ReentrantLock lock = new ReentrantLock();
BigDecimal balance = BigDecimal.ZERO;
ShipmentAccount(long id) { this.id = id; }
}
}8.7 자기 점검 답변
락 순서 일관성으로 데드락 방지는?
답:
1. 순서 일관:
- 항상 같은 순서
- 순환 대기 깸
-
방법:
- id 순서
- 해시 기반
-
효과:
- 순환 불가
- 원천 방지
-
실용성:
- 가장 실용적
- tryLock 보다 근본적
9️⃣ 면접 + 자기 점검 + 마스터 50문항 + Phase 5 완주
9.1 면접 단골 질문 매핑
| Q | 핵심 답변 |
|---|---|
| tryLock 두 형태? | 즉시 / 타임아웃 |
| 데드락 4조건? | 상호배제/점유대기/비선점/순환대기 |
| 데드락 시나리오? | 락 순서 불일치 |
| lock() 데드락? | 영원히 (회복 불가) |
| tryLock 회피? | 포기/재시도 |
| 회복 방법? | 재시작 (lock()) |
| 실패 후 전략? | 백오프, 큐 |
| 락 순서 일관? | 순환 대기 깸 |
| 백오프? | 지수 + 지터 |
| 데드락 진단? | jstack, ThreadMXBean |
9.2 마스터 자기 점검 체크리스트
tryLock
- 두 형태
- 즉시/타임아웃
- 반환값
데드락 조건
- 4가지
- 깨기
시나리오
- 순서 불일치
- 타이밍
lock 데드락
- 영원히
- 회복 불가
tryLock 회피
- 양보/재시도
- 메커니즘
회복
- 재시작
- 사전 방지
실패 전략
- 백오프
- 큐
락 순서
- 일관성
- 순환 깸
9.3 tryLock/데드락 마스터 50문항
tryLock (12문항)
Q1. tryLock()? → 즉시 시도
Q2. tryLock(time)? → 타임아웃
Q3. 실패 시? → false
Q4. lock 과 차이? → 무한 vs 포기
Q5. 반환값? → boolean
Q6. 획득 후? → try-finally
Q7. 실패 후 unlock? → 안 함
Q8. InterruptedException? → tryLock(time)
Q9. 즉시 용도? → 중복 방지
Q10. 타임아웃 용도? → 데드락 회피
Q11. 백오프? → 재시도 간격
Q12. 지터? → 랜덤 분산데드락 조건 (13문항)
Q13. 4조건? → 상호배제/점유대기/비선점/순환대기
Q14. 상호 배제? → 한 번에 하나
Q15. 점유 대기? → 보유한 채 대기
Q16. 비선점? → 강제 회수 X
Q17. 순환 대기? → 서로 순환
Q18. 모두 충족? → 데드락
Q19. 방지? → 하나 깨기
Q20. 순환 깨기? → 락 순서
Q21. 비선점 깨기? → tryLock
Q22. 점유대기 깨기? → 전부 또는 포기
Q23. 가장 실용? → 순서 일관
Q24. 데드락 정의? → 서로 대기
Q25. 라이브락? → 계속 양보 (다름)lock/tryLock 회피 (13문항)
Q26. lock 데드락? → 영원히
Q27. 회복? → 재시작
Q28. tryLock 회피? → 양보/재시도
Q29. 양보? → 첫 락 풀기
Q30. 재시도? → 백오프
Q31. 타임아웃 회피? → tryLock(time)
Q32. 순환 깸? → 양보로
Q33. 회복 불가? → lock()
Q34. 회복 가능? → tryLock
Q35. 사전 방지? → 순서, tryLock
Q36. 진단? → jstack
Q37. ThreadMXBean? → findDeadlockedThreads
Q38. 감지 후? → 알림/재시작전략/순서 (12문항)
Q39. 실패 전략? → 백오프, 큐
Q40. 지수 백오프? → 2배씩
Q41. 지터? → 랜덤
Q42. 대체 경로? → 락 없는 방법
Q43. 큐 적재? → 비동기
Q44. 락 순서? → 일관성
Q45. 순서 방법? → id, 해시
Q46. 순서 효과? → 순환 X
Q47. id 순서? → 작은 것 먼저
Q48. 해시 순서? → identityHashCode
Q49. 순서 vs tryLock? → 근본 vs 회피
Q50. 권장? → 순서 + tryLock9.4 채점
50 / 50 → tryLock/데드락 마스터
45-49 → 거의 마스터
40-44 → 복습
< 40 → Unit 5.4 재학습9.5 Phase 5 완주 정리
Phase 5 — 정교한 락
Unit 5.1 — synchronized의 한계
- 무한 대기, 인터럽트 X, 공정성 X
Unit 5.2 — LockSupport
- park/unpark
- 저수준, 고수준 기반
Unit 5.3 — ReentrantLock
- lock/unlock, try-finally
- 재진입, 공정성, Condition
Unit 5.4 — tryLock (★ 마스터)
- 데드락 회피
- 락 순서 일관9.6 Phase 5 핵심 통찰
Phase 5 핵심 통찰 5가지:
1. synchronized 한계
- 무한 대기, 인터럽트 X
2. ReentrantLock
- 정교한 제어
- try-finally 필수
3. tryLock
- 포기/재시도
- 데드락 회피
4. 데드락 4조건
- 순환 대기 깨기 (락 순서)
5. 실무
- 락 순서 일관 + tryLock9.7 4주차 누적 진행
✅ Phase 1 — 동시성의 기초 (4 Unit)
✅ Phase 2 — 4분면 매트릭스 (3 Unit)
✅ Phase 3 — 스레드 다루기 (5 Unit)
✅ Phase 4 — synchronized & volatile (5 Unit) ★ 1차 정점
✅ Phase 5 — Lock 도구 (4 Unit) ← 완주
⏭ Phase 6 — 스레드 협력 (4 Unit)
⏭ Phase 7 — Executor (7 Unit) ★ 2차 정점
⏭ Phase 8 — 고급 비동기 (3 Unit)
총: 21/35 Unit (Phase 5 완주, 약 60%)9.8 추가 심화 질문
Q1: 라이브락 (Livelock)?
답:
- 데드락과 달리 계속 활동
- 서로 양보만 반복
- 진전 없음
- tryLock 회피 시 가능
- 랜덤 백오프로 완화
Q2: 기아 (Starvation) vs 데드락?
답:
- 데드락: 서로 대기 (멈춤)
- 기아: 특정 스레드 자원 못 받음
- 데드락은 멈춤, 기아는 지연
- 공정성으로 기아 완화
Q3: 데드락 예방 vs 회피 vs 감지?
답:
- 예방: 조건 깨기 (사전)
- 회피: 안전 상태 유지 (은행원 알고리즘)
- 감지: 발생 후 탐지 + 회복
- 자바: 주로 예방 (순서)
Q4: tryLock 의 공정성?
답:
- tryLock() 은 공정성 무시 (즉시)
- 공정 락이어도 새치기
- tryLock(time) 은 공정성 따름
- 주의 필요
Q5: 분산 환경 데드락?
답:
- 여러 노드 간 락
- 분산 락 (Redis, Zookeeper)
- 타임아웃 필수
- 데드락 더 복잡
🎯 핵심 요약 — 3줄 정리
1. tryLock
- 즉시 / 타임아웃 시도
- 실패 시 포기 (false)
2. 데드락
- 4조건 (상호배제/점유대기/비선점/순환대기)
- lock(): 영원히 (회복 불가)
- tryLock(): 포기/재시도 (회피)
3. 방지
- 락 순서 일관 (순환 깸, 근본)
- tryLock + 백오프 (회피)
🏆 Phase 5 완주 — Lock 도구 마스터
🚀 Phase 5 — 정교한 락
✅ Unit 5.1 synchronized의 한계
✅ Unit 5.2 LockSupport
✅ Unit 5.3 ReentrantLock
✅ Unit 5.4 tryLock (★ 마스터) ← 여기, Phase 5 완주
→ synchronized 한계 → ReentrantLock
→ tryLock 데드락 회피
→ 락 순서 일관성📚 다음으로...
Phase 6 — 스레드 간 협력 (생산자-소비자, 인터럽트, yield)
Phase 6 — 스레드 협력 (4 Unit)
Unit 6.1 — 생산자-소비자 문제
Unit 6.2 — wait()과 notify()
Unit 6.3 — 인터럽트(Interrupt) 메커니즘
Unit 6.4 — yield()4주차 누적 진행
✅ Phase 1~5 (21 Unit, 1차 정점 완료)
⏭ Phase 6 — 스레드 협력 (4 Unit)
총: 21/35 Unit (약 60%)★ 마스터 Unit — tryLock 데드락 회피 완료
🏆 Phase 5 완주 — Lock 도구 마스터
Software Developer