[Java] JVM 동시성 제어 원리 (Implicit Lock)

앞선 글에서 자바 동시성 제어 방식인 `synchronized`, `ReentrantLock`, `Semaphore`에 대해 알아봤다. 이 중 `ReentrantLock`, `Semaphore` 은 자바에서 제공하는 고수준 락 (Explicit Lock)이며 OS 수준의 모니터 락과는 무관하게 자체적인 대기 큐와 락 획득 메커니즘을 사용하여 동작한다.

 

반면에 `synchronized` 는 객체가 가지고 있는 헤더를 사용하여 제어하며 JVM에서 관리하는 JVM 내장 락, 즉 저수준 락 (Implicit Lock) 이다.`synchronized`는 JVM 모니터 락을 기반으로 성능 최적화를 위해 `Biased Locking -> Lightweight Locking -> Heavyweight Locking`을 단계적으로 적용한다. 이와 같이 경쟁 상황에 따라 가벼운 락 방식에서 모니터 방식으로 점진적으로 전환되는 과정을 이번 글에서 자세하게 다룰 것이다.

 

 

---

 

☑️ 공유 객체

 

객체는 한정된 자원으로, 생성되면 Heap 영역에 저장된다. 또한 스레드는 Stack 영역에 생성되는데, 해당 스레드들은 객체를 참조하게 되고 이 과정에서 두 개 이상의 스레드가 하나의 동일 객체를 참조하는 일이 발생하게 된다. 이때 필요한 개념이 동기화이다. 동기화를 위해서는 Lock이 필요한데 이는 객체의 Object 헤더 부분에 포함되어 있다. 객체 해더 중 해당 객체의 여러가지 메타데이터(락 상태, GC 정보 등)를 확인할 수 있는 부분을 Mark Word라고 한다. 

 

 

위 사진 우측에 Mark Word는 UnLock 상태이며 이 떄 Hash Code는 객체의 고유번호를 의미한다. 이 외의 비트들은 경쟁 상태에 따라 변경되는데 이는 아래에서 더 자세하게 살펴볼 예정이다.

 

 

1️⃣ Biased Locking

서비스 유형에 따라 다르겠지만, 일반적으로 객체에 대해서 경쟁이 일어나지 않는 경우가 많으며, 경쟁이 일어나더라도 특정 객체에 동일한 하나의 스레드가 계속해서 접근하는 경우가 대부분이다. 이 때 동일한 스레드에 대한 반복적인 동기화 작업은 CPU의 낭비로 이어지기 때문에 Mark Word를 특정 스레드 전용 Mark Word로 변환하는데 이를 Biased Locking이라고 한다.

 

 

 

 

그림과 같이 Hash Code부분은 접근하는 스레드의 ID로, Biased의 비트는 1로 바뀌게 된다.

이후에 동일한 스레드가 해당 객체에 다시 한번 접근한다면 스레드 ID 값의 비교를 통해 쉽게 Lock을 흭득할 수 있는 것이다.

 

 

 

 

2️⃣ Lightweight Locking

여전히 경쟁이 심하지 않을 때 사용되는 락 방식으로, 공유 객체에 대한 경쟁이 시작되었을 때 Biased Locking이 해제되고 Lightweight Locking이 적용된다. 이때 객체의 락을 흭득한 스레드는 객체의 Mark Word와 객체의 주소를 자신의 스택영역에 저장해놓는다. 또한 객체의 Mark Word는 Lock Record Address로 변환되며 이는 Lock Record가 저장된 스레드의 스택 영역을 가리킨다. 이렇듯 서로를 포인팅하고 있는 상태가 되면 Lock을 흭득한 것이다,

 

 

 

Lightweight Locking 상태에서 락을 흭득하지 못한 스레드는 Spin Lock을 돌게 되며, 이를 통해 컨택스트 스위치 비용을 절감할 수 있다. 이 때 로우 코드 수준에서의 상호배제를 위해 CPU 수준의 CAS 연산이 일어나게 되며 이와 같은 원리로 원자적인 연산을 사용자 수준에서 할 수 있도록 구현해놓은 것이 `cocurrent.atomic` 패키지이다.

 

 

 

3️⃣ Heavyweight Locking

 

스레드 간의 경쟁이 심화되면 Lightweight Locking은 Heavyweight Locking으로 변환되며 이 때부터 모니터 방식의 상호배제가 사용된다. 스레드가 락 흭득을 위해 대기할 떄 블로킹되어, 락을 해제할 때까지 CPU를 사용하지 않고 대기한다. 또한 OS 수준의 컨텍스트 스위칭이 일어나기 때문에 비교적 큰 비용이 발생한다. 

 

 

 

위 사진과 같은 모니터 방식을 Non-blocking Monitor 방식이라고 한다. 스레드는 모니터에 진입하기 위해 Wait Set과 Entry Set에서 대기한다. Wait Set은 조건 변수와 함께 사용되어 특정 조건을 만족할 때까지 스레드가 대기하는 장소이며, 다른 스레드에 의해 깨어나게 되면 Entry Set으로 이동하여 락을 흭득할 수 있는 상태가 된다. 또한 Entry Set은 락을 흭득하기 위해 대기하는 장소로, 락이 반납되면 Entry Set에 있는 스레드 중 하나의 스레드가 락을 흭득하며 임계영역으로 진입하게 된다.

 

하지만 위와 같은 방식은 Entry Set에 있는 스레드들에 우선순위가 부여되지 않기 때문에 Entry Set 내에서 오랫동안 대기하는 스레드가 생기는 공평성 문제가 발생할 수 있다. 이 문제를 해결할 수 있는 방법이 자바 표준 API에서 제공하는 `java.util.concurrent.locks` 패키지의 Explicit Lock이다.

 

 

---

 

 

☑️ 결론

JVM 내부적으로 경쟁상태에 따라 락의 방식을 단계적으로 변경하여 성능 향상이 가능토록 했다.

하지만 synchronized는 단일 JVM 환경에서는 유효하지만 현대 애플리케이션은 다중 서버나 다중 JVM에서 구동되는 경우가 많기 때문에 분산 환경에서 적합하지 않을 수 있다. 따라서 성능적 요구사항을 충족시키기 위해서는 락 오버헤드를 줄일 수 있는 ReentrantLock, Atomic 클래스를,  분산 시스템을 지원하기 위해서는 Redis, Zookeeper와 같은 분산락 동시성 제어 도구들을 사용해야한다.