오늘은 락(Lock)에 대해서 조금 공부해보려고 한다. 자바에서 멀티스레드 환경을 다루다 보면, 여러 스레드가 동시에 같은 자원에 접근할 때 문제가 생길 수 있는데, 이런 걸 막기 위해 락을 사용한다. 이번에는 특히 ReentrantLock과 ReentrantReadWriteLock이 어떻게 동작하는지, 그리고 언제 쓰면 좋은지 살펴볼 예정이다. 아직까지 락(Lock)과 동시성은 나한테 너무 어렵다...

---

기존 문제점

왜 우리는 락(Lock)을 사용하는 걸까? 솔직하게 나는 락(Lock)에 대해 안 지 얼마 되지 않았다.

그런데 멀티스레드 환경에서 여러 스레드가 동시에 같은 자원에 접근하면, 값이 꼬이거나 예상과 다른 결과가 나오는 경우가 생긴다는 걸 알게 되었다. 그래서 이런 문제를 막고, 안전하게 공유 자원을 다루기 위해 락이 필요하다는 것을 배우게 된 것이다.

일단 락(Lock)을 사용하지 않으면 어떻게 되는지 코드로 확인해보자

public class NoLockExample {

    static int count = 0;

    public static void main(String[] args) {
        Thread a = new Thread(addCount("A "));
        Thread b = new Thread(addCount("B "));
        Thread c = new Thread(addCount("C "));
        Thread d = new Thread(addCount("D "));
        Thread e = new Thread(addCount("E "));

        a.start();
        b.start();
        c.start();
        d.start();
        e.start();
    }

    static Runnable addCount(String threadName) {
        return () -> IntStream.range(0, 20000).forEach(i -> {
            System.out.println(threadName + count++);
        });
    }
}

우리는 5개의 스레드가 각각 20,000번씩 count를 증가시키니까, 최종적으로 99999까지 증가할 것을 예상한다.

하지만 실제로 코드를 실행하면, 결과는 99,989까지만 증가하는 등 예상과 달리 값이 누락되는 현상을 확인할 수 있다.

그 이유는 count++ 연산이 읽기 → 더하기 → 저장의 3단계로 이루어져 있고, 여러 스레드가 동시에 접근하면 서로 덮어쓰기가 발생하기 때문이다.

즉, 락을 걸지 않으면 스레드 간 간섭으로 인해 값이 꼬이는 문제(race condition)가 발생하게 된다.

물론 간단하게 예전에 정리했던 synchronized 키워드를 사용하여 이를 해결할 수 있다.

참고
📚 [Java] - synchronized

public class LockExample {

    static int count = 0;

    public static void main(String[] args) {
        Thread a = new Thread(addCount("A "));
        Thread b = new Thread(addCount("B "));
        Thread c = new Thread(addCount("C "));
        Thread d = new Thread(addCount("D "));
        Thread e = new Thread(addCount("E "));

        a.start();
        b.start();
        c.start();
        d.start();
        e.start();
    }

    static Runnable addCount(String threadName) {
        return () -> IntStream.range(0, 20000).forEach(i -> {
            incrementCount(threadName);
        });
    }

    static synchronized void incrementCount(String threadName) {
        System.out.println(threadName + count++);
    }
}

하지만 synchronized는 thread-Safe한 작업이 가능했지만 성능 저하가 생기기 쉽고 , 세밀한 제어가 어렵고, 읽기/쓰기 구분이 안 되어 병렬 처리 효율이 떨어진다.

이런 단점을 해결하기 위해 나온 것이 ReentrantLock과 ReentrantReadWriteLock 이다.

---

📌 ReentrantLock

• 자바에서 동시에 여러 스레드가 접근하는 것을 제어하기 위한 동기화 메커니즘 중 하나다.

void lock() // lock 잠금
void unlock() // lock 해제
boolean isLocked() // lock이 잠겼는지 확인
boolean tryLock() // lock polling
boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException

• 수동으로 락을 걸고(lock()), 풀 수(unlock()) 있는 객체

• 즉, 잠금 영역의 시작과 끝을 개발자가 직접 제어할 수 있다는 뜻이다.

• ReentrantLock은 이름 그대로 재진입 가능(Reentrant) → 같은 스레드가 이미 획득한 락을 다시 획득할 수 있음

• tryLock(), 공정성 옵션(fairness) 등 synchronized보다 유연한 기능 제공한다.

코드로 확인해보자!!

public class LockExample {

    static int count = 0;
    static ReentrantLock lock = new ReentrantLock();

    public static void main(String[] args) {
        Thread a = new Thread(addCount("A "));
        Thread b = new Thread(addCount("B "));
        Thread c = new Thread(addCount("C "));
        Thread d = new Thread(addCount("D "));
        Thread e = new Thread(addCount("E "));

        a.start();
        b.start();
        c.start();
        d.start();
        e.start();
    }

    static Runnable addCount(String threadName) {
        return () -> IntStream.range(0, 20000).forEach(i -> {
            incrementCount(threadName);
        });
    }

    static void incrementCount(String threadName) {
        lock.lock(); // 락 획득
        try {
            System.out.println(threadName + count++);
        } finally {
            lock.unlock(); // 반드시 락 해제
        }
    }
}

역시 예상대로 99999 가 나오는 것을 확인 할 수 있다.

그런데 멀티스레드 환경에서 락(Lock)을 가진 채 오랫동안 작업을 하는 스레드가 있으면, 다른 스레드들은 그 락을 못 얻어서 기다려야 한다.

그래서 공유 데이터를 보호하는 것만큼, 락을 오래 잡고 있지 않게 하는 것도 중요하다.

자바에서는 이런 상황을 제어하기 위해 wait(), notify(), notifyAll() 같은 메서드를 제공한다.

wait()

실행 중인 스레드가 락을 반납하고 대기 상태로 들어가게 한다.

waiting pool이라는 곳에서 다른 스레드가 락을 사용할 수 있도록 기다림

락을 잡은 상태에서 오랫동안 멈춰있는 걸 방지한다.

notify()

waiting pool에 있는 하나의 스레드에게 작업을 계속할 수 있다고 알림

어떤 스레드가 락을 얻을지는 보장 못함 → JVM 스케줄러가 결정

notifyAll()

waiting pool에 있는 모든 스레드에게 알림

단, 락은 한 번에 하나의 스레드만 획득 가능 → 나머지는 락을 얻기 위해 다시 기다림

synchronized / Object	ReentrantLock / Condition	설명
synchronized	lock() / unlock()	락을 획득하고 해제. synchronized는 블록 단위, ReentrantLock은 수동 제어
wait()	await()	락을 반납하고 대기. Condition 객체를 통해 기다림
notify()	signal()	waiting pool에 있는 하나의 스레드를 깨워서 락을 다시 얻어 작업 진행
notifyAll()	signalAll()	waiting pool에 있는 모든 스레드에게 알림, 락은 한 번에 하나씩만 얻을 수 있음

🤔 Condition은 Lock과 함께 사용되며,
특정 조건이 만족될 때까지 스레드를 대기(wait) 시키거나, 조건이 만족되면 대기 중인 스레드를 깨우는(signal) 역할을 한다.

• 즉, "조건이 충족될 때까지 기다려!" → "조건이 됐어, 이제 일어나!" 이런 식의 흐름을 락 기반으로 구현할 수 있게 해주는 객체다.

---

ReadWriteLock

public interface ReadWriteLock {

    // 읽기 전용 락을 반환
    Lock readLock();

    // 쓰기 전용 락을 반환
    Lock writeLock();
}

ReadWriteLock은 읽기 락(read lock) 과 쓰기 락(write lock) 두 종류의 락을 제공하는 락 인터페이스다.

• 읽기 락 (Read Lock)

  • 데이터를 읽기만 하는 작업에서는 여러 스레드가 동시에 접근해도 데이터가 변경되지 않기 때문에 동시 접근이 안전하다.
    → 따라서 여러 스레드가 동시에 읽기 락을 얻을 수 있다.

• 쓰기 락 (Write Lock)

  • 데이터를 변경하는 작업은 단 하나의 스레드만 접근해야 한다.
    → 쓰기 락은 배타적(exclusive) 으로 동작한다.
    → 쓰기 락이 걸린 동안은 다른 읽기/쓰기 락 모두 획득할 수 없다.

가장 많이 쓰이는 구현체는 ReentrantReadWriteLock이 존재한다.

ReadWriteLock lock = new ReentrantReadWriteLock();

Lock readLock = lock.readLock();
Lock writeLock = lock.writeLock();

왜 사용할까?

💡 일반 Lock (ReentrantLock)의 한계

보통 ReentrantLock이나 synchronized는
한 번에 단 하나의 스레드만 접근할 수 있게 한다.

즉, 데이터 읽기만 해도 모든 스레드가 순서대로 기다려야 한다.

Thread A: read() 실행 중
Thread B: 기다림 
Thread C: 기다림 

하지만 읽기(read) 작업은 데이터 변경이 없기 때문에,
여러 스레드가 동시에 읽어도 안전하다.

이런 상황에서 단일 락을 쓰면 불필요하게 성능이 떨어진다.

그래서 등장한 게 ReadWriteLock이다.

이건 읽기 전용 구간은 여러 스레드가 동시에 접근하게 하고,
쓰기 구간은 오직 하나의 스레드만 접근하게 만든다.

언제 사용해야할까?

상황	설명
읽기 비중이 높을 때	대부분의 작업이 읽기라면, 동시에 여러 스레드가 접근 가능해서 성능이 크게 향상됨
쓰기 비중이 낮을 때	가끔만 데이터를 수정한다면, 잠금 경합(lock contention)을 줄임
캐시, 설정값, 조회 API 등	읽기가 많고 쓰기가 드문 곳에서 매우 적합

---

ReentrantReadWriteLock

ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

Lock readLock = lock.readLock();
Lock writeLock = lock.writeLock();

ReentrantReadWriteLock은 읽기 작업과 쓰기 작업을 구분하여 동시성을 높이기 위한 락이다.

여러 개의 스레드가 동시에 읽기 작업을 수행해도 데이터의 일관성이 깨지지 않기 때문에, 여러 스레드가 동시에 읽기 락(ReadLock) 을 얻을 수 있다.

즉, 읽기 락은 공유 락(Shared Lock)으로 동작하여 상호 배제 없이 병렬적인 읽기 접근을 허용하므로, 읽기 작업이 많은 환경에서 동시성이 크게 향상된다.

반면 쓰기 락(WriteLock) 은 배타적(Exclusive)으로 동작한다.

하나의 스레드가 쓰기 락을 보유하고 있는 동안에는 다른 어떤 스레드도 읽기 락이나 쓰기 락을 획득할 수 없다.

읽기 락이 유지되고 있는 동안에도 쓰기 락은 획득할 수 없으며, 만약 쓰기 락을 얻으려는 스레드가 대기 중인데 계속해서 새로운 읽기 요청이 들어온다면, 쓰기 스레드가 락을 얻지 못하고 기아(starvation) 상태에 빠질 수 있다
.
이를 방지하기 위해 ReentrantReadWriteLock은 생성 시 공정 모드(fair mode) 로 설정할 수 있으며, 이 경우 락은 대기열의 순서(FIFO)에 따라 부여되어 기아 현상이 완화된다.

읽기 락이 해제될 때(unlock() 호출 시), 내부적으로 보유 중인 읽기 락의 수가 하나씩 줄어들며, 모든 읽기 락이 해제되어 개수가 0이 되면 쓰기 락을 대기 중인 스레드가 락을 획득할 수 있다.

또한, ReentrantReadWriteLock에서 쓰기 락은 Condition 객체를 지원하지만, 읽기 락은 Condition을 지원하지 않는다. 따라서 readLock.newCondition()을 호출하면 UnsupportedOperationException이 발생한다.

---

🧹정리

구분	ReadWriteLock	ReentrantReadWriteLock	ReentrantLock
타입	인터페이스 (interface)	구현 클래스 (class)	구현 클래스 (class)
락의 종류	읽기 락, 쓰기 락 두 가지 제공	읽기 락(ReadLock), 쓰기 락(WriteLock) 모두 구현	단일 락 (읽기/쓰기 구분 없음)
동작 방식	읽기/쓰기 개념만 정의	읽기 락은 여러 스레드가 공유 가능, 쓰기 락은 단독 사용	하나의 스레드만 접근 가능 (배타적)
재진입 가능 여부	정의 없음	재진입 가능	재진입 가능
공정성 설정 (Fairness)	정의 없음	지원 (new ReentrantReadWriteLock(true))	지원 (new ReentrantLock(true))
Condition 지원 여부	정의 없음	WriteLock만 지원 / ReadLock은 지원하지 않음	지원
동시성 수준	개념상 중간	높음 (읽기 병렬 허용)	낮음 (단일 접근)
주요 메서드	readLock(), writeLock()	lock(), tryLock(), unlock(), getReadLockCount() 등	lock(), tryLock(), unlock(), newCondition()
적합한 상황	설계용 (직접 사용 불가)	읽기 작업이 많고 쓰기 작업이 적은 경우	단순한 상호 배제가 필요한 경우
구현 기반	없음 (인터페이스)	AbstractQueuedSynchronizer (AQS) 기반	AbstractQueuedSynchronizer (AQS) 기반
객체 생성	불가능 (인터페이스)	new ReentrantReadWriteLock()	new ReentrantLock()

---

참고

[Java] Lock, ReentrantLock, ReadWriteLock,