1. 들어가며

Java의 멀티스레딩 환경에서 동기화는 필수입니다. 가장 흔히 사용하는 synchronized 외에도, java.util.concurrent.locks 패키지에 포함된 ReentrantLock은 보다 정교한 제어를 가능하게 합니다. 이 글에서는 ReentrantLock을 synchronized와 비교하며, 그 내부 원리와 어떠한 특징이 있는지 알아보겠습니다.

2. synchronized vs ReentrantLock

멀티스레드 환경에서 공유 자원을 보호하기 위한 가장 대표적인 방법은 synchronized입니다. 하지만 보다 유연하고 확장 가능한 락이 필요할 때는 ReentrantLock을 사용하는 것이 더 적합합니다. 두 방법은 다음과 같은 차이점을 가집니다

항목	synchronized	ReentrantLock
선언 방식	키워드 사용 (synchronized)	객체 생성 후 명시적 lock/unlock
공정성(Fairness) 설정	불가능	가능 (new ReentrantLock(true))
인터럽트 대응	불가능	가능 (lockInterruptibly())
타임아웃 설정	불가능	가능 (tryLock(timeout))
Condition 지원	wait/notify	Condition 객체 사용
코드 유연성	제한적	높음 (lock을 여러 위치에서 제어 가능)

• synchronized는 간결하고 직관적이지만, 세밀한 동기화 제어에는 한계가 있습니다.
• ReentrantLock은 명시적인 lock/unlock 제어와 다양한 확장 기능(공정성, 인터럽트, 타임아웃, Condition 등)을 제공하여 복잡한 동기화 요구에 대응할 수 있습니다.

3. ReentrantLock의 내부 동작 원리

ReentrantLock은 내부적으로 AbstractQueuedSynchronizer(AQS)라는 프레임워크를 활용해 락 획득과 해제를 구현합니다. 여기에서는 AQS의 개념과, ReentrantLock이 이를 어떻게 확장하여 사용하는지 자세히 살펴보겠습니다.

3.1 AQS(AbstractQueuedSynchronizer)

AbstractQueuedSynchronizer는 락, 세마포어 등 다양한 동기화 구조의 기반이 되는 클래스입니다.
실제로 ReentrantLock 이외에도 Semaphore, CountDownLatch, ReentrantReadWriteLock 등에서 AQS를 활용하고 있습니다.
핵심은 int state 상태값과 FIFO 방식의 대기 큐를 통해 스레드 간 접근을 제어한다는 점입니다.

• acquire(), release() 등 템플릿 메서드로 동기화 흐름을 정의
• tryAcquire(), tryRelease() 등 메서드를 하위 클래스에서 구현하도록 위임
• 대기 중인 스레드는 내부 큐에 Node 형태로 관리되며, LockSupport.park()/unpark()로 블로킹 제어

3.1.1 AQS의 Node

스레드들이 FIFO 순서로 연결리스트에 붙고, 앞 노드의 신호에 의해 락을 순차적으로 획득함으로써,
공정성(fairness)과 캐시 효율성(locality)을 동시에 달성하는 락 대기 메커니즘이다.

// AbstractQueuedSynchronizer.java
abstract static class Node {
	volatile Node prev;
	volatile Node next;
	Thread waiter;
    volatile int status;
...
}

⚡ AQS의 캐시 효율성

락 상태 확인 시 앞 노드의 상태(status)만 확인

• 여러 스레드가 동일한 메모리 주소(CAS 대상 필드)를 반복적으로 읽고 쓴다면?

  • CPU 간 캐시 일관성(MESI protocol) 유지에 따른 비용 증가
  • 여러 코어가 같은 변수에 쓰기를 시도하면서 캐시 invalidation이 빈번하게 발생

• 캐시 효율성을 달성하는 메커니즘

메커니즘	설명
읽기 전용 감시 구조	스레드는 대부분 prev.status만 읽기 전용 접근 → 캐시 히트율 ↑
쓰기 최소화	대기열 진입 시 tail에만 CAS → 공유 필드 쓰기 감소, 캐시 경합 최소화
노드 간 독립적 메모리 배치	각 스레드는 자신만의 노드를 사용하며, 다른 스레드와 동일한 캐시라인을 공유하지 않음 → false sharing 방지
LockSupport 기반 블로킹	스핀을 최소화하여 캐시라인 invalidation 비용 감소

3.1.2 state의 의미와 volatile 처리

private volatile int state;

• AQS의 핵심 필드는 volatile int state이며, 락의 보유 여부나 재진입 횟수 등을 나타냅니다.
• volatile 키워드를 통해 메모리 가시성이 보장됩니다. 즉, 한 스레드가 변경한 값을 다른 스레드가 즉시 볼 수 있습니다.
• compareAndSetState(int expect, int update)와 같은 CAS 연산을 통해 락 획득 및 해제를 원자적으로 수행합니다.
• ReentrantLock에서는 이 state가 재진입 횟수로도 활용됩니다.

3.1.3 AQS를 상속할 때 override할 method

인터페이스, 추상 클래스 등을 볼 때 오버라이드할 메서드를 확인하면 인터페이스 또는 추상클래스와 그것을 구현하는 클래스간의 관계를 파악할 수 있습니다.

AQS는 직접 사용하는 클래스가 아니라, 내부 헬퍼 클래스로 상속하여 사용하는 것이 원칙입니다. 실제 ReentrantLock, Semaphore, CountDownLatch 등은 모두 내부적으로 AQS를 상속하여 구현됩니다.

Subclasses should be defined as non-public internal helper classes that are used to implement the synchronization properties of their enclosing class.

AQS를 상속하여 동기화 도구를 구현할 때 오버라이드해야 하는 메서드는 다음과 같습니다:

• tryAcquire(int)
• tryRelease(int)
• tryAcquireShared(int)
• tryReleaseShared(int)
• isHeldExclusively()

이 메서드들은 모두 기본적으로 UnsupportedOperationException을 던지며, 하위 클래스에서 반드시 구현해야 합니다.

또한 동기화 상태를 다룰 때 사용하는 메서드는 다음과 같습니다:

• getState()
• setState(int)
• compareAndSetState(int, int)

Defining these methods is the only supported means of using this class. All other methods are declared final because they cannot be independently varied.

즉, AQS는 이 다섯 가지 메서드를 오버라이드하는 방식으로만 동작을 커스터마이징할 수 있으며, 그 외의 메서드는 모두 final로 선언되어 있어 변경이 불가능합니다.

---

3.2 ReentrantLock은 AQS를 어떻게 활용하는가

ReentrantLock은 내부의 Sync 클래스를 통해 AQS를 상속하여 락의 모든 동작을 구현합니다.

3.2.1 Sync 클래스 구조

public class ReentrantLock implements Lock, java.io.Serializable {
    private final Sync sync;

    abstract static class Sync extends AbstractQueuedSynchronizer {
        // 공통 동작 정의
    }

    static final class NonfairSync extends Sync {
        // 비공정 락 구현
    }

    static final class FairSync extends Sync {
        // 공정 락 구현
    }
}

• ReentrantLock은 생성 시점에 공정성 여부에 따라 FairSync 또는 NonfairSync를 sync에 할당합니다.

3.2.2 공정성과 Sync 선택

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

• fair = true이면 큐 순서를 엄격히 지키는 FairSync, 기본값은 NonfairSync입니다.

3.2.3 재진입과 락 획득 로직

abstract boolean initialTryLock();

@ReservedStackAccess
final void lock() {
    if (!initialTryLock())
        acquire(1); // AQS의 템플릿 메서드 호출
}

static final class NonfairSync extends Sync {
    final boolean initialTryLock() {
        Thread current = Thread.currentThread();
        if (compareAndSetState(0, 1)) {
            setExclusiveOwnerThread(current);
            return true;
        } else if (getExclusiveOwnerThread() == current) {
            int c = getState() + 1;
            if (c < 0)
                throw new Error("Maximum lock count exceeded");
            setState(c);
            return true;
        } else {
            return false;
        }
    }
}

• 락이 비어 있으면 CAS로 획득
• 현재 락 보유자가 다시 lock하면 재진입 허용 (state++)
• 그 외의 경우엔 실패하고 AQS 큐에 진입하여 대기

4. 주요 메서드 및 활용 예시

4.1 ReentrantLock 주요 메서드

4.1.1 기본 lock() / unlock()

Lock lock = new ReentrantLock();

lock.lock();
try {
    // critical section
} finally {
    lock.unlock();
}

• lock() 호출 시 락을 즉시 얻을 수 있으면 바로 반환하고, 아니면 AQS 큐에 진입해 대기합니다.
• unlock()은 state를 감소시키고, 0이 되면 다음 대기 중인 스레드를 깨웁니다.

4.1.2 lockInterruptibly()

try {
    lock.lockInterruptibly();
    try {
        // 작업 수행
    } finally {
        lock.unlock();
    }
} catch (InterruptedException e) {
    // 인터럽트 응답 처리
}

• synchronized와 달리 인터럽트에 응답할 수 있습니다.
• 긴 작업 중 인터럽트 처리를 요구하는 경우 유용합니다.

4.1.3 tryLock(long timeout, TimeUnit unit)

if (lock.tryLock(3, TimeUnit.SECONDS)) {
    try {
        // 락 획득 성공 시 수행
    } finally {
        lock.unlock();
    }
} else {
    // 락 획득 실패
}

• 일정 시간 동안 락을 시도하다가 실패하면 false를 반환합니다.
• 교착 상태 회피 로직 등에 활용됩니다.

4.1.4 Condition 객체

Condition condition = lock.newCondition();

lock.lock();
try {
    while (!조건) {
        condition.await(); // 대기
    }
    // 조건 만족 → 작업 수행
    condition.signal(); // 조건 만족 알림
} finally {
    lock.unlock();
}

• wait/notify와 유사하지만, 하나의 락에 여러 Condition을 만들 수 있습니다.
• 보다 정교한 동기화 로직을 구현할 수 있습니다.

---

4.2 공정성과 락 획득 순서: Fair vs NonFair 모드

ReentrantLock은 생성 시 공정성 여부를 지정할 수 있습니다:

Lock fairLock = new ReentrantLock(true);  // 공정 모드
Lock unfairLock = new ReentrantLock();    // 비공정 모드 (기본값)

4.2.1 Fair 모드

• 락 요청이 먼저 큐에 들어온 순서대로 (FIFO) 락을 부여합니다.
• hasQueuedPredecessors()를 통해 자신의 차례인지 확인합니다.
• 장점: 공정한 락 분배
• 단점: 전체 처리량(throughput)이 떨어질 수 있음

protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    } else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        setState(nextc);
        return true;
    }
    return false;
}

4.2.2 NonFair 모드

• 먼저 락을 즉시 CAS로 시도하고, 실패할 경우에만 AQS 큐에 들어갑니다.
• 큐의 앞에 다른 스레드가 있어도 락을 먼저 얻을 수 있음 → 공정하지 않음.
• 장점: 처리량(throughput)이 높고 context switching 비용이 적음
• 단점: 특정 스레드가 락을 얻지 못하는 starvation이 발생할 수 있음

// ReentrantLock.NonfairSync 내부의 nonfairTryAcquire
protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
}

final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 큐 상태 확인 없이 바로 CAS 시도
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    } else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        setState(nextc);
        return true;
    }
    return false;
}

4.2.3 Fair vs NonFair 모드 성능 비교 및 차이 발생 요인

✅ 일반적인 성능 경향

항목	공정 모드 (Fair)	비공정 모드 (NonFair)
평균 처리량 (Throughput)	낮음	높음
지연 시간 편차	작음	큼
Starvation 발생 가능성	낮음	높음
Lock 획득 속도	느림	빠름

💡 성능 비교

• 경쟁 스레드 수가 많을수록 NonFair 모드가 좀 더 빠른 처리량을 보입니다.
• 단, NonFair 모드는 특정 스레드가 반복적으로 락을 얻으며 지연이 편중되는 현상이 발생할 수 있습니다.

⚙️ 성능 차이를 만들어내는 핵심 요소들

1. 선점 기회와 CAS 시도 시점

   • NonFair 모드는 compareAndSetState(0, 1)을 바로 시도.
   • Fair 모드는 hasQueuedPredecessors() 조건 확인으로 분기 비용 존재.

2. Context Switching 빈도

   • Fair 모드는 큐 순서를 보장하려다 보니 스레드 간 전환이 자주 발생.
   • NonFair 모드는 락 소유자가 바로 재진입하여 스위칭 최소화.

3. 락 해제 후 다음 스레드 선택 방식

   • Fair 모드는 unparkSuccessor(head)로 큐 앞을 깨움.
   • NonFair는 락 요청자가 새로 선점 가능.

4. JVM 최적화 및 캐시 일관성

   • Fair는 상태 공유가 많아 cache coherence 비용 증가.
   • NonFair는 상태 공유 적고, 경로 단순 → JIT 최적화 유리.

✅ Fair, NonFair 선택 기준

상황	추천 모드
성능이 가장 중요하고 락 점유 시간이 짧은 경우	NonFair
공정성이 중요한 예약/스케줄링 시스템	Fair
락 획득 순서에 민감한 이벤트 처리 시스템	Fair
대부분의 애플리케이션 (기본 설정)	NonFair

5. ReentrantLock 사용 시 스레드 상태 변화

ReentrantLock은 AQS를 기반으로 스레드 상태를 관리하기 때문에, 락 획득 실패, 조건 대기 등 상황에 따라 JVM의 스레드 상태가 다양한 방식으로 변화합니다. 이 장에서는 주요 상태 전이 흐름과 예시를 살펴보겠습니다.

5.1 스레드 상태 전이 흐름

NEW → RUNNABLE → BLOCKED / WAITING / TIMED_WAITING → RUNNABLE → TERMINATED

• lock() 실패 시: AQS 대기 큐에 진입하며 LockSupport.park()를 통해 WAITING 또는 TIMED_WAITING 상태가 됩니다.
• unlock() 시: AQS 내부에서 다음 노드를 unpark()하여 깨어나게 함 → RUNNABLE로 전환
• Condition.await()를 호출한 스레드: WAITING 상태로 진입하며, signal() 또는 signalAll() 호출 시 깨어남

5.2 상태 변화 예시 시나리오

Thread A: lock() 성공 → 작업 수행
Thread B: lock() 실패 → AQS 큐 대기 → WAITING
Thread A: unlock() → Thread B 깨움 → RUNNABLE
Thread B: lock() 재시도 → 작업 수행

• 스레드 B는 락을 얻지 못했기 때문에 AQS 큐에 등록되고, 내부적으로 LockSupport.park()로 인해 블로킹됩니다.
• 스레드 A가 락을 해제하면 AQS는 다음 노드(스레드 B)를 unpark()하여 다시 락 획득을 시도할 수 있게 합니다.

5.3 Condition 대기 상태 흐름

ReentrantLock은 Condition 객체를 통해 wait/notify와 유사한 조건 대기 메커니즘을 제공합니다. 이때 스레드는 일반 AQS 큐가 아닌 별도의 Condition 대기 큐에 들어가며 상태 전이 역시 다르게 나타납니다.

lock.lock();
try {
    while (!조건) {
        condition.await(); // WAITING 상태로 진입
    }
    // 조건 만족 시 작업 수행
} finally {
    lock.unlock();
}

• await()를 호출하면 현재 락을 반납하고 Condition 대기 큐에 들어가며 WAITING 상태가 됩니다.
• 이후 signal() 호출 시 다시 AQS 큐로 이동하여 lock() 재진입을 시도하게 됩니다.

6. 마치며

synchronized는 간단하고 안정적인 동기화 도구입니다. 하지만 복잡한 동기화 제어가 필요한 실무 환경에서는 ReentrantLock이 훨씬 더 강력한 선택지가 됩니다. 특히 다음과 같은 요구 사항이 있는 경우에 큰 장점을 가집니다:

• 공정성(Fairness): 락 획득 순서를 제어하고 싶은 경우 (new ReentrantLock(true))
• 조건 기반 대기/알림: Condition을 통해 여러 조건을 독립적으로 다루고 싶은 경우
• 인터럽트/타임아웃 처리: lockInterruptibly(), tryLock(timeout) 등으로 유연한 제어가 필요한 경우
• 재진입 추적: state를 통한 재귀적 락 획득 관리가 필요한 경우

ReentrantLock의 내부 구현은 AQS(AbstractQueuedSynchronizer)를 기반으로 하며, 이를 통해 높은 수준의 제어와 확장 가능성을 제공합니다. 단순한 lock-unlock을 넘어서 스레드 상태 제어, 조건 대기, 공정성 보장 등 다양한 기능을 유연하게 제공하는 것이 큰 장점입니다.