**ReentrantReadWriteLock**의 읽기 잠금을 해제하지 않고 쓰기 잠금으로 업그레이드하려 할 때 발생하는 아키텍처적 위험은 무엇이며, **StampedLock**의 낙관적 읽기 메커니즘이 이 특정 교착 상태 벡터를 어떻게 완화합니까?

질문에 대한 답변.

질문의 역사.

Java 5에서 도입된 ReentrantReadWriteLock는 여러 동시 독자 허용을 통해 단일 뮤텍스보다 상당한 동시성 개선을 제공했습니다. 그러나 그 설계는 명시적으로 잠금 업그레이드를 금지합니다. 즉, 읽기 잠금을 보유한 상태에서 쓰기 잠금을 획득하는 것은 불가능합니다. 이는 구현이 스레드당 읽기 보유 수를 추적하기 때문입니다. 읽기 잠금을 보유한 스레드가 쓰기 잠금을 획득하려고 하면 자체적으로 교착 상태에 빠집니다: 쓰기 잠금은 독점 소유권을 요구하는데, 읽기 잠금(스레드 자신의 포함)을 보유하는 동안에는 이를 부여할 수 없습니다. Java 8에서 도입된 StampedLock은 비재진입 대안으로 이 한계를 낙관적 읽기 스탬프를 통해 해결하여 읽기 단계에서 잠금 소유권 없이 작동하며, 원자적 검증 및 변환 메커니즘을 결합합니다.

문제.

근본적인 위험은 잠금 획득 의미론의 비대칭성에서 발생합니다. ReentrantReadWriteLock에서는 업그레이드를 위해 읽기 잠금을 해제한 다음 쓰기 잠금을 획득해야 하므로, 해제와 재획득 사이에 다른 스레드가 쓰기 잠금을 획득하거나 상태를 수정할 수 있는 취약한 창이 생성됩니다. 이는 개발자들이 복잡한 이중 확인 잠금 패턴 또는 재시도 루프를 구현하도록 강제하여 코드 복잡성과 대기 시간을 증가시킵니다. 또한, 개발자가 실수로 직접 업그레이드를 시도하는 경우(writeLock().lock()을 호출하면서 readLock()을 보유하는 경우) 스레드는 자신의 읽기 허가를 해제하기를 기다리며 회복 불가능한 교착 상태에 빠지게 됩니다.

해결책.

StampedLock은 읽기 허용 없이 긴 스탬프를 반환하는 **tryOptimisticRead()**를 통해 이 위험을 제거합니다. 스레드는 읽기 작업을 수행한 후 **validate(stamp)**를 호출합니다; 만약 스탬프가 여전히 유효하다면(사이에 쓰기가 발생하지 않았다면) 읽기가 차단되지 않고 일관성이 있습니다. 스레드가 쓰기가 필요하다고 판단하면, **tryConvertToWriteLock(stamp)**를 시도하여 스탬프를 원자적으로 검증하고 상태가 낙관적 읽기 시작 이후 변경되지 않았을 경우에만 쓰기 잠금을 획득합니다. 이 접근 방식은 잠금 전환 동안 스레드가 충돌하는 읽기 잠금을 보유하지 않도록 하여 교착 상태를 방지하고, 상태 일관성에 따라 업그레이드를 조건부로 만듭니다.

코드 예.

import java.util.concurrent.locks.StampedLock;

public class AtomicUpgradeCache {
    private final StampedLock lock = new StampedLock();
    private int value = 0;

    public void conditionalUpdate(int threshold, int newValue) {
        long stamp = lock.tryOptimisticRead();
        int current = value;
        
        // 행동하기 전에 검증
        if (!lock.validate(stamp)) {
            stamp = lock.readLock();
            try {
                current = value;
            } finally {
                lock.unlockRead(stamp);
            }
        }
        
        if (current < threshold) {
            // 원자적 업그레이드 시도
            stamp = lock.tryConvertToWriteLock(stamp);
            if (stamp == 0L) {
                // 변환 실패, 새로운 쓰기 잠금 획득
                stamp = lock.writeLock();
            }
            try {
                // 독점 잠금 아래에서 조건을 재검사
                if (value < threshold) {
                    value = newValue;
                }
            } finally {
                lock.unlock(stamp);
            }
        }
    }
}

실생활의 상황

문제 설명.

고주파 거래 플랫폼은 실시간 시장 깊이를 나타내는 메모리 내 주문서 캐시를 유지 관리하며, 수백 개의 스레드에서 초당 약 50,000회의 읽기가 필요하지만 가격 변동이 있을 때만 간헐적인 업데이트가 필요합니다. 초기 구현은 synchronized 블록을 사용하여 시장 변동성이 클 때 모니터를 놓고 스레드가 경쟁하면서 치명적인 대기 시간 스파이크를 초래했으며, 읽기 대기 시간은 가끔 500밀리초를 초과했습니다. 엔지니어링 팀은 가격 업데이트가 관찰에서 변동으로 업그레이드되는 동안 교착 상태 없이 주문서를 원자적으로 확인하고 수정할 수 있도록 하면서 읽기 측면의 경쟁을 완전히 제거해야 했습니다.

고려된 다양한 해결책.

해결책 1: 해제 및 재획득을 통한 ReentrantReadWriteLock.

이 접근 방식은 시장 조건을 검사하기 위해 읽기 잠금을 획득한 후 이를 해제하고, 업데이트가 필요할 경우 즉시 쓰기 잠금을 획득하려고 시도하는 것이었습니다. 이 방법은 교착 상태를 방지했지만 상당한 경합 조건을 도입했습니다: 읽기 잠금을 해제하고 쓰기 잠금을 획득하는 사이에 경쟁하는 스레드가 동일한 오래된 상태를 관찰하고 중복 데이터베이스 쿼리나 API 호출을 시작하여 천둥 무리 현상과 자원 낭비를 초래할 수 있습니다. 또한 읽기 및 쓰기 모드 간의 지속적인 문맥 전환은 높은 거래량 기간 동안 측정할 수 있는 오버헤드를 추가했습니다.

해결책 2: 변동 참조가 있는 불변 스냅샷.

이 솔루션은 전체 잠금을 포기하고 주문서를 변동 필드로 참조되는 불변 데이터 구조로 유지하는 것을 선택했습니다. 독자는 단순히 변동을 역참조하여 일관된 스냅샷을 얻었고, 작성자는 실시간으로 주문서 사본을 만들고 참조에 대해 원자적 비교 및 설정 작업을 수행했습니다. 이 방법은 읽기 경쟁을 완전히 제거하고 뛰어난 읽기 성능을 제공했습니다. 그러나 각 사소한 가격 업데이트는 전체 주문서 구조를 복사해야 하므로 대규모 할당 압력을 발생시켜 빈번한 젊은 세대 가비지 수집 중단이 발생했으며 이는 변동 시장에서 애플리케이션의 10밀리초 대기 시간 SLA를 위반했습니다.

해결책 3: 낙관적 읽기 및 조건부 변환을 가진 StampedLock.

선택된 솔루션은 StampedLock을 활용하여 핫 패스에 대한 낙관적 읽기 액세스를 제공했습니다: 스레드는 **tryOptimisticRead()**를 사용하여 주문서 상태를 낙관적으로 읽고, 스탬프를 검증하며, 동시 쓰기가 발생하지 않았을 경우에만 진행합니다. 드문 쓰기 작업의 경우 시스템은 **tryConvertToWriteLock()**를 사용하여 스탬프를 직접 쓰기 잠금으로 변환하려고 시도했으며, 이를 통해 관찰된 상태가 현재로 유지되고 독점 액세스를 얻기 위해 valid한 경우에만 쓰기 잠금을 확보했습니다. 변환이 실패하면 시스템은 전통적인 재시도 논리를 사용하여 명시적 쓰기 잠금 획득으로 돌아갑니다. 이 접근 방식은 낙관적 읽기가 발생했을 때 원자적 안전을 보장했습니다.

선택된 솔루션(이유 포함).

팀은 해결책 3을 선택했습니다. 이는 극한의 읽기 처리량 요구(낙관적 읽기는 스레드 수에 따라 선형적으로 확장됨)와 조건부 업데이트에 대한 원자적 안전 요구를 독특하게 조화시켰습니다. 해결책 1과는 달리 스탬프 검증 메커니즘을 통해 읽기 해제와 쓰기 획득 사이의 경합 창을 제거했습니다. 해결책 2와는 달리 모든 사소한 가격 조정을 위한 전체 구조 복사를 요구하는 대신 변환된 쓰기 잠금 아래에서 원인 수정이 가능하도록 하여 메모리 할당 압력을 피했습니다. 검증 및 변환을 원자적으로 수행하는 능력은 가격 업데이트가 결정 기준과 완전히 일치하는 경우에만 발생하도록 보장하였으며 이는 이전 프로토타입에서 발생한 일관성 위반을 방지했습니다.

결과.

구현 후, 이 애플리케이션은 초당 50,000개의 동시 읽기를 유지하며 p99.9 대기 시간은 15마이크로초 이하로 떨어졌습니다. 이는 이전의 동기화된 접근 방식에 비해 30배의 개선을 나타냈습니다. 1,000개의 동시 가격 업데이트가 발생하는 변동 시장에서 시스템은 교착 상태가 없고 가비지 수집 중단 시간은 2밀리초 미만으로 유지되었습니다. StampedLock 구현은 단일 동시성 관련 사건이나 데이터 경합 없이 6개월간의 생산 거래를 원활하게 처리하며, 고주파 읽기 시나리오에 대한 낙관적 잠금을 사용하기로 한 건축적 결정이 유효함을 입증했습니다.

후보자들이 놓치는 점

왜 StampedLock은 재진입을 지원하지 않으며, 스레드가 동일한 잠금을 재귀적으로 획득하려고 시도할 때 어떤 치명적인 실패 모드가 발생합니까?

StampedLock은 내부 상태 추적을 최소화하고 처리량을 극대화하기 위해 명시적으로 비재진입 잠금으로 설계되었습니다. ReentrantReadWriteLock과 달리, 보유 스레드 map 및 보유 수를 유지하는 대신, StampedLock은 어떤 스레드가 접근하고 있는지만 추적합니다. 결과적으로 읽기 잠금을 보유한 스레드가 동일한 StampedLock 인스턴스에서 다른 읽기 잠금을 획득하려고 시도하면 즉시 교착 상태에 빠집니다: 획득 호출은 모든 기존 잠금이 해제될 때까지 차단되지만, 차단된 스레드는 그 잠금 중 하나를 보유하고 있어 해결할 수 없는 순환 종속성이 발생합니다. 개발자는 코드 리팩토링을 통해 현재 스탬프를 메서드 매개변수로 전달해야 하며, 종종 스레드 로컬 잠금 상태에 의존했던 내부 API의 설계 변경이 필요합니다.

StampedLock의 낙관적 읽기 모드의 메모리 가시성 의미론은 비관적 읽기 잠금과 어떻게 다르며, 왜 **validate()만으로는 적절한 발생-이전 관계 없이 일관성을 보장하기에 충분하지 않은가요?

**tryOptimisticRead()**를 통한 낙관적 읽기는 그 자체로 발생-이전 보장도 제공하지 않습니다; 그것은 메모리 장벽을 발생시키거나 명령 재정렬을 방지하지 않고 단순히 버전 스탬프를 캡처합니다. 낙관적 단계에서 관찰된 데이터는 오래된 CPU 캐시 라인 또는 아직 초기화 중인 객체를 반영할 수 있습니다. JVM 메모리 모델은 낙관적 읽기를 일반적인 변수 접근으로 취급하며 동기화 의미론이 없습니다. 그러나 **validate(stamp)**가 true를 반환할 때는 낙관적 읽기 시작 이후 쓰기 잠금이 획득되지 않았다는 것을 확립함으로써 가장 최근의 쓰기 잠금 해제에 대한 발생-이전 가장자리를 생성합니다. 그러나 후보자들은 **validate()**가 잠금 상태만 보장할 뿐 데이터 구조의 내부 일관성을 보장하지 않는다는 점을 종종 간과합니다: 보호된 데이터가 변동 객체에 대한 비훈련 참조를 포함하고 있다면, 낙관적 읽기는 다른 스레드에 의해 여전히 초기화되고 있는 객체에 대한 참조를 관찰할 수 있습니다(불안전한 게시). 따라서 낙관적 읽기에는 보호된 상태가 변동 참조 또는 불변 객체로만 구성되어 있어야 안전한 게시가 가능합니다.

StampedLock과 Virtual Threads(Project Loom) 사이의 근본적인 비호환성은 무엇이며, 이것이 현대의 높은 동시성 애플리케이션에서 StampedLock을 피해야 하는 이유는 무엇인가요?**

StampedLock 구현은 잠금을 보유하고 있는 동안 가상 스레드가 차단될 때 기본 Platform Thread(운반 스레드)를 고정하는 LockSupport.park 연산에 의존합니다. 가상 스레드가 경쟁되는 StampedLock(읽기 또는 쓰기)에 접근하려 할 때, JVM은 잠금 내부가 가상 스레드 양도의 적응을 받지 않은 기본 동기화 원시들을 사용하기 때문에 가상 스레드를 그 운반체에서 언마운트할 수 없습니다. 이 고정은 수천 개의 가상 스레드를 몇 개의 플랫폼 스레드로 멀티플렉스하는 가상 스레드의 핵심 확장성을 무효화합니다. 여러 가상 스레드가 동시에 StampedLock 경쟁에서 차단되면, 애플리케이션이 이론적으로 여전히 사용 가능하지만 전체 운반 스레드 풀을 독점하게 됩니다. 반면, ReentrantLock과 Semaphore는 가상 스레드에서 호출될 때 고정을 피하기 위해 비차단 알고리즘 또는 특별한 양도 메커니즘을 사용하여 수정되었습니다. 따라서 VirtualThread 실행기를 사용하는 현대 애플리케이션은 StampedLock을 ReentrantLock 또는 동시 데이터 구조로 교체하여 운반 스레드 고갈을 방지해야 합니다.