LockSuport.park()는 모니터락을 사용하지 않는다는거야?

[ljh468]

자바 동기화 메커니즘 Q&A

Q1. 자바에서 synchronized 키워드가 사용하는 락의 정체가 무엇이야?

A1.

• synchronized는 자바 객체(Object)에 내장된 모니터 락(Monitor Lock)을 사용함. 모든 객체는 이 모니터 락을 가지고 있으며, synchronized 메서드나 블록에 접근할 때 이 락을 획득하고 해제함

---

Q2. LockSupport.park()는 모니터 락을 사용하지 않는다면, 어떤 메커니즘으로 스레드를 제어하는거야?

A2.

• LockSupport.park()는 모니터 락과는 완전히 독립적인 퍼밋(Permit)이라는 저수준(Low-level) 메커니즘을 사용함. 퍼밋은 스레드별로 관리되는 단 하나의 허가증(0 또는 1) 같은 것임

---

Q3. LockSupport.park()는 스레드를 언제 WAITING 상태로 만드는 거야?

A3.

• park()는 호출 시 스레드가 퍼밋(Permit)을 가지고 있는지 확인함
• 퍼밋이 없을 경우 (0): 스레드는 WAITING 상태로 전환되어 CPU를 사용하지 않고 대기함
• 퍼밋이 있을 경우 (1): park()는 즉시 반환되며, 스레드는 대기하지 않고 계속 실행됨 (이 퍼밋은 이전의 unpark() 호출로 인해 미리 주어진 것)

---

Q4. LockSupport.unpark(Thread t)의 역할은 무엇이며, 퍼밋과 어떻게 연관되나요?

A4.

• unpark(Thread t)는 대상 스레드에게 퍼밋을 제공하여 대기 상태에서 벗어나도록 신호를 주는 역할을 함
• 대기 중인 스레드인 경우: 스레드를 WAITING에서 RUNNABLE 상태로 깨우고, 퍼밋을 다시 0으로 초기화함
• 대기 중이 아닌 스레드인 경우: 해당 스레드의 퍼밋을 1로 설정함. 이 스레드가 나중에 park()를 호출하면 즉시 통과하게 됨(0으로 초기화)

---

Q5. LockSupport의 퍼밋이 모니터 락을 사용하는 Object.wait()보다 좋은점은?

A5.

• LockSupport는 선행 unpark()가 가능하다는 점이 가장 큰 장점
• Object.wait()는 반드시 wait()가 호출된 후에 notify()가 호출되어야 스레드를 깨울 수 있음
• 순서가 바뀌면 스레드는 영원히 대기할 수 있음
• LockSupport는 unpark()가 먼저 호출되어도 퍼밋을 남겨두기 때문에, 스레드가 나중에 park()를 호출해도 즉시 통과할 수 있음
• 이는 경쟁 조건으로 인한 스레드의 영구 대기(Lost Wakeup) 문제를 방지하게 됨

---

LockSupport의 퍼밋(Permit) 개념과 구현 원리

• LockSupport의 퍼밋(Permit)은 스레드 간의 통신과 스레드 대기/해제를 제어하는 데 사용되는 가장 단순한 형태의 동기화 상태 변수임

1. 퍼밋의 개념: 단일 이진(Binary) 상태

• 퍼밋은 각 스레드마다 존재하며, 가질 수 있는 상태는 두 가지뿐
• 퍼밋 없음 (0): 스레드는 대기 상태로 들어갈 수 있음 (park 호출 시).
• 퍼밋 있음 (1): 스레드는 대기 상태로 들어가지 않고 즉시 통과 (park 호출 시).
• 이 퍼밋은 마치 "열쇠"나 "티켓"과 같은 것
• park(): "열쇠"가 없으면 잠들고, 있으면 통과함
• unpark(): "열쇠"를 대상 스레드에게 건네줌

2. 구현 원리: JVM의 저수준 관리

• LockSupport.park()와 unpark()는 자바 코드 레벨에서 퍼밋 변수를 직접 관리하는 것이 아니라, JVM(Java Virtual Machine)의 내부 구현과 운영체제(OS)의 스레드 관리 기능에 의존함

1) JVM 및 OS 연동

LockSupport의 실제 작동은 JVM이 스레드 객체 내부에 숨겨진 필드를 사용하거나, OS에서 제공하는 뮤텍스(Mutex)나 세마포어(Semaphore) 같은 저수준 동기화 기본 요소를 호출하여 구현됨

• park() 호출 시: JVM은 스레드의 상태를 WAITING으로 변경하고, OS에게 CPU 자원을 반납하도록 요청함
• unpark() 호출 시: JVM은 대상 스레드를 WAITING에서 RUNNABLE로 전환하도록 OS 스케줄러에게 알림

2) 선행 호출 (Pre-Acquisition)의 구현

unpark()가 park()보다 먼저 호출될 때 퍼밋을 1로 설정하여 나중에 park()가 즉시 통과하게 만드는 메커니즘은, synchronized의 wait/notify와 달리 "Lost Wakeup"을 방지하는 핵심임

예시: 스레드 A가 unpark()를 호출하면, JVM은 A 스레드의 숨겨진 퍼밋 상태를 1로 설정. 나중에 A 스레드가 park()를 호출하면, JVM은 퍼밋(1)을 확인하고 0으로 초기화한 뒤 즉시 park() 호출을 통과시킴

한줄로 정리해보자면?

• 퍼밋(Permit)은 JVM이 스레드별로 관리하는 원자적인 이진 상태(0 또는 1) 변수이며, LockSupport.park()와 unpark()를 통해 스레드의 대기/재실행을 제어하는 가장 Atomic한 동기화 요소임

---

추가 synchronized와 LockSupport 메커니즘의 차이점 요약

특징	synchronized (모니터 락)	LockSupport.park() (퍼밋 메커니즘)
기본 작동 원리	락(Lock)을 획득/반납하는 상호 배제	퍼밋(허가증)을 주고받아 스레드 실행을 제어
대기 상태	BLOCKED	WAITING 또는 TIMED_WAITING
락/퍼밋 해제 방식	synchronized 블록 종료 시 JVM이 자동 해제	unpark() 또는 interrupt() 호출로 개발자가 수동 해제
주요 사용처	기본 스레드 안전성 보장 (간편함)	ReentrantLock, Semaphore 등 고급 동기화 도구의 내부 구현

참고: LockSupport는 ReentrantLock과 같은 더 유연한 동기화 도구를 구축하기 위해 JVM이 제공하는 저수준(primitive) 동기화 구성 요소임

[YuDeokRin]

오 저도 궁금했던 점이고 클로드랑 같이 대화했던 내용이랑 비슷하네요 ㅎㅎ