synchronized와 임계영역

Overview

같은 Monitor를 사용하는 임계영역에는 한 번에 하나의 Thread만 들어간다.

핵심 원리

Monitor 진입과 반환은 상호 배제와 메모리 공개 경계를 만든다.

flowchart LR; W[Waiting Threads] --> M{Monitor}; M --> C[Critical Section]

실무에서 발생하는 문제

긴 임계 구역, Lock 순서 불일치, 외부 I/O를 포함한 Monitor 점유는 대기와 Deadlock을 만든다. 같은 Lock으로 보호해야 할 상태가 여러 Lock에 흩어지는 문제도 흔하다.

Trade-off

Monitor는 상호 배제와 가시성을 함께 제공해 정확성이 명확하지만 경쟁 시 대기가 생긴다. Lock-free 구조는 특정 패턴에서 빠르지만 검증 난도가 높다.

흔한 오해

Method에 synchronized를 붙이는 것만으로 관련 객체 전체가 안전해지는 것은 아니다. Instance Method와 Static Method는 서로 다른 Monitor를 사용한다.

Interview Questions

• 이 기술이 해결하는 핵심 문제는 무엇인가?
• 내부에서는 어떤 순서로 동작하는가?
• 운영 환경에서 어떤 지표와 실패 모드를 확인해야 하는가?

왜 필요한가

여러 Thread가 공유 상태를 동시에 변경할 때 임계 구역을 한 Thread만 실행하게 하고, Lock 해제 전 변경을 다음 획득 Thread가 보게 한다.

내부 동작

Instance synchronized Method는 this, Static Method는 Class 객체의 Monitor를 획득한다. Block 형태는 명시한 객체를 Lock으로 사용한다. 획득 실패 Thread는 BLOCKED 상태가 되고, Monitor를 얻은 뒤 다시 실행한다.

Example

잔액 확인과 차감이 하나의 불변식이라면 두 작업을 같은 Monitor 안에서 수행한다. 외부 API 호출은 임계 구역 밖으로 옮기고, 여러 Lock이 필요하면 모든 코드에서 동일한 획득 순서를 지킨다.

Production Considerations

JFR의 Monitor Blocked 이벤트와 Thread Dump의 BLOCKED Stack으로 경쟁 지점을 찾는다. Lock 범위를 줄이기 전에 보호하는 불변식을 적고, 변경 후 동시성 Stress Test로 안전성을 검증한다.

Related Topics

Memory Visibility, CAS, Deadlock과 비교한다.