Java의 동기화 기법 - synchronized & ReentrantLock 에 대해

다음과 같은 순으로 글이 이어집니다.

synchronized 소개
synchronized vs static synchronized 
synchronized 단점을 극복한 ReentrantLock 소개
synchronized vs ReentrantLock

 

1. synchronized 소개

멀티스레드 환경에서는 여러 스레드가 동시에 같은 자원에 접근할 경우, 예상치 못한 문제(데이터 손상, 충돌 등)가 발생할 수 있습니다. 이를 방지하기 위해 동기화(synchronization) 기법이 필요합니다.

Java에서 제공하는 synchronized 키워드는 모니터 락(Monitor Lock)을 이용해 동기화를 지원합니다.

 

모니터는 OS가 아닌 프로그래밍 언어 수준에서 제공하는 동기화 메커니즘입니다. Java의 모든 객체(인스턴스)는 내부적으로 고유한 모니터를 가지며, 이를 획득하고 해제하며 동기화 작업을 수행합니다. 즉, 모니터와 락은 서로 상호보완적인 관계로 대체하거나 비교할 수 있는 개념이 아닙니다.

- 출처 : In Java, what is the difference between a monitor and a lock

 

synchronized 특징

• 스레드가 synchronized 키워드가 붙은 메서드에 진입하려면 해당 객체의 락을 획득해야 합니다.
• 락을 획득하지 못한 스레드는 RUNNABLE 상태에서 BLOCKED 상태로 전환됩니다. 락을 획득할 때까지 대기하며, 이 동안 CPU 실행 스케줄링에서 제외됩니다.
• 여러 스레드가 대기 중일 경우, 락 획득 순서는 보장되지 않습니다.
• synchronized 블록 안에서는 변수의 메모리 가시성 문제가 자동으로 해결되므로, 별도의 volatile 선언이 필요하지 않습니다.

synchronized 단점 2가지

• 무한 대기 : BLOCKED 상태의 스레드는 락이 풀릴 때까지 무한 대기로 인터럽트, 타임아웃 적용이 안됩니다.
• 공정성 문제: 락이 돌아왔을 때, BLOCKED 상태의 여러 스레드 중에 어떤 스레드가 락을 획득할 지 알수 없습니다.

BLOCKED 는 스레드의 상태 중 일부로 스레드의 상태는 다음과 같습니다.

NEW	스레드가 생성되었지만 아직 시작되지 않은 상태. Thread thread = new Thread(runnable)
RUNNABLE	실행 중이거나 실행 준비가 완료된 상태. thread.start()
BLOCKED	동기화 락을 기다리는 상태. (synchronized 사용 시 발생) synchronized (lock) {…}
WAITING	다른 스레드의 특정 작업이 완료되기를 무한정 기다리는 상태. (wait(), join() 호출 시)
TIMED_WAITING	특정 시간 동안 대기하는 상태. (sleep(), wait(timeout), join(timeout) 호출 시)
TERMINATED	스레드의 실행이 완료된 상태.

 

BLOCKED & WAITING 은 모두 스레드가 대기하며 CPU 실행 스케줄링에 들어가지 않기 때문에, CPU에서 보면 실행하지 않는 비슷한 상태이지만 큰 차이가 있습니다.

 

BLOCKED → 인터럽트가 걸려도 여전히 BLOCKED

• synchronized 에서 락을 획득하기 위해 대기할 때 사용하는 특별한 상태입니다.

WAITING(TIME_WAITING) → 인터럽트가 걸리면 RUNNABLE 변경

• 스레드가 특정 조건이나 시간 동안 대기할 때 발생하는 상태입니다.

 

2. synchronized vs static synchronized

synchronized 키워드가 인스턴스별로 작동하는지, static synchronized가 클래스 레벨에서 작동하는지 실험을 통해 확인해보겠습니다.

 

실험 1, synchronized 메서드의 동작 확인

실험 코드

public class SyncMain {

    public static void main(String[] args) {
        MyTask task1 = new MyTask();

        Thread thread1 = new Thread(task1, "thread1");
        thread1.start();

        Thread thread2 = new Thread(task1, "thread2");
        thread2.start();
    }

    static class MyTask implements Runnable {

        Logger logger = new Logger();

        @Override
        public void run() {
            String name = Thread.currentThread().getName();
            while (true) {
                logger.logging(name);
                sleep(1000);
            }
        }
    }
}

public class Logger {

    public synchronized void logging(String threadName) {
        while (true) {
            System.out.println("logging: " + threadName);
            sleep(1000);
        }
    }
}

실험 목적: 동일 인스턴스의 synchronized 메서드를 여러 스레드에서 호출할 경우 동기화가 이루어지는지 확인합니다.

예상 결과: 한 스레드가 logging 메서드(임계영역)에 진입하면, 다른 스레드는 BLOCKED 상태가 되어 로그를 남길 수 없습니다.

결과: 한 스레드의 로그만 출력됩니다. 동기화가 정상적으로 이루어졌음을 확인했습니다.

 

실험 2, synchronized의 인스턴스별 락 확인

실험 코드

MyTask task1 = new MyTask();
MyTask task2 = new MyTask();

Thread thread1 = new Thread(task1, "thread1");
thread1.start();

Thread thread2 = new Thread(task2, "thread2");
thread2.start();

실험 목적: 각기 다른 인스턴스가 서로 독립적인 모니터 락을 가지는지 확인합니다.

예상 결과

• 각 인스턴스는 자신만의 모니터 락을 가지고 있습니다.
• 두 스레드는 서로 다른 인스턴스의 logging 메서드를 실행하므로 각각 로그를 남길 수 있습니다.

결과: 스레드별로 로그가 출력됩니다. 이는 각 인스턴스가 고유한 모니터 락을 가지고 있음을 의미합니다.

 

실험 3, static synchronized의 클래스 레벨 락 확인

실험 코드

public class SyncMain {

    public static void main(String[] args) {
        MyTask task1 = new MyTask();
        MyTask task2 = new MyTask();

        Thread thread1 = new Thread(task1, "thread1");
        thread1.start();

        Thread thread2 = new Thread(task2, "thread2");
        thread2.start();
    }

    static class MyTask implements Runnable {
        
        @Override
        public void run() {
            String name = Thread.currentThread().getName();
            while (true) {
                Logger.logging(name);
                sleep(1000);
            }
        }
    }
}

public class Logger {

    public static synchronized void logging(String threadName) {
        while (true) {
            System.out.println("logging: " + threadName);
            sleep(1000);
        }
    }
}

실험 목적: static synchronized 메서드가 여러 인스턴스에서도 클래스 레벨의 락을 공유하는지 확인합니다.

예상 결과

• 서로 다른 MyTask 인스턴스를 생성했지만, static synchronized 키워드로 인해 클래스 레벨의 락을 공유합니다.
• 한 스레드가 락을 소유한 동안, 다른 스레드는 BLOCKED 상태가 되어 로그를 남길 수 없습니다.

결과: 한 스레드만 로그를 남깁니다. 클래스 레벨의 락이 공유되고 있음을 확인했습니다.

결론

synchronized 키워드는 인스턴스마다 고유한 모니터 락을 사용합니다.

• 동일 인스턴스에서 동기화된 메서드를 호출할 경우, 스레드는 락을 얻기 위해 BLOCKED 상태로 대기합니다.

static synchronized 키워드는 클래스 레벨의 모니터 락을 사용합니다.

• 서로 다른 인스턴스라도 동일한 락을 공유하여, 한 스레드가 락을 점유하면 다른 스레드는 대기해야 합니다.

 

3. synchronized 단점을 극복한 ReentrantLock 소개

synchronized 키워드는 동기화를 제공하지만, 무한 대기와 비공정성이라는 단점이 있습니다.

이러한 문제를 해결하기 위해 Java 5부터 ReentrantLock이 도입되었습니다. ReentrantLock은 LockSupport를 활용하여 위 단점을 극복합니다.

 

1. 무한 대기 극복

LockSupport는 concurrent 패키지에 위치하며, 저수준의 객체입니다. LockSupport는 스레드가 락을 획득하려고 대기할 때, 스레드의 상태를 BLOCKED 대신 WAITING으로 변경해서 인터럽트를 허용하게 해줍니다. 이를 통해 synchronized의 무한 대기 문제를 해결합니다.

 

2. 공정성 극복

ReentrantLock은 공정 모드와 비공정 모드를 제공하며, 필요에 따라 선택할 수 있습니다.

 

2-1. 공정 모드 (Fair Mode)

특징

• 대기 큐에 있는 스레드가 락을 요청한 순서대로 락을 획득합니다 
• 모든 스레드가 언젠가는 락을 획득할 수 있습니다.(기아 현상 방지)

단점

• 대기 큐 관리로 인해 성능이 저하될 수 있습니다.

사용 방법

Lock lock = new ReentrantLock(true); // 공정 모드 설정

 

2-2. 비공정 모드 (Non-Fair Mode)

특징

• 성능을 중시하는 환경에서 사용됩니다.
• 비공정 모드이지만, ReentrantLock은 내부적으로 큐로 구현되어있기 때문에 스레드 간 경합이 크지 않는 이상 순서대로 처리됩니다.

사용 방법

 

Lock lock = new ReentrantLock(); // 기본은 비공정 모드

 

ReentrantLock의 기본 사용법

ReentrantLock은 임계영역에 대해 명시적으로 lock()과 unlock()을 호출합니다.
unlock()은 반드시 finally 블록에서 호출하여, 락이 항상 해제되도록 보장해야 합니다.

Lock lock = new ReentrantLock();

try {
    lock.lock(); // 락 획득
    // 임계영역
} finally {
    lock.unlock(); // 락 해제
}

ReentrantLock은 Lock 인터페이스를 구현한 대표적인 클래스입니다. 이 인터페이스가 제공하는 주요 메서드를 살펴보겠습니다. 

 

void lock()

• 락을 획득한다. 만약, 다른 스레드가 이미 락을 획득 했다면 락이 풀릴 때까지 현재 스레드는 WAITING 상태가 된다. 하지만 인터럽트에 응답하지 않는다.
• WAITING 상태지만 왜 인터럽트에 응답하지 않는 이유?
  • 내부 구현에서 인터럽트가 발생하면 순간 WAITING 상태를 빠져나와서 RUNNABLE 상태가 되지만, 다시 해당 스레드를 WAITING 상태로 강제로 변경해버린다.
• 이 락은 모니터 락이 아니고, Lock 인터페이스와 ReentrantLock 이 제공하는 기능이며, 모니터 락과 BLOCKED 상태는 synchronized 에서만 사용된다.

void lockInterruptibly()

• 락 획득을 시도하되, 다른 스레드가 인터럽트를 발생시켜 WAITING 상태에서 벗어나서 락 획득을 포기 할 수 있다.

boolean tryLock()

• 락 획득을 시도하고, 즉시 성공 여부를 반환. 락을 획득하면 true, 아니면 false

boolean tryLock(long time, TimeUnit unit)

• 주어진 시간 안에 락을 획득하면 true 를 반환, 주어진 시간 안에 락 획득 못하면 false 반환. 락 획득 대기 중 인터럽트가 발생하면 락 획득을 포기한다.

void unlock()

• 락을 획득한 스레드가 호출해야 하며, 락을 해제한다.

Condition newCondition()

• Condition 객체는 락과 결합되어 사용되며, 스레드가 특정 조건을 기다리거나 신호를 받는다. Object 클래스의 wait, notify 메서드와 유사한 역할을 한다.

 

4. synchronized vs ReentrantLock

synchronized와 ReentrantLock은 모두 동기화 문제를 해결할 수 있는 기법입니다.

하지만 둘 사이에는 몇 가지 중요한 차이점이 있습니다.

 

1. 제공 방식

• synchronized는 자바 언어 차원에서 제공하는 키워드로 모든 인스턴스에는 모니터 락이 있습니다.(wait set 포함)
• ReentrantLock은 Java의 java.util.concurrent 라이브러리에서 제공하는 클래스입니다. 코드적으로 지원합니다.

2. 스레드 대기 상태

• synchronized를 사용할 때, 스레드가 락을 기다리는 상태는 BLOCKED입니다. 이 상태에서는 인터럽트를 통해 스레드를 깨울 수 없습니다.
• 반면, ReentrantLock을 사용할 경우, 스레드가 락을 기다리는 상태는 WAITING 또는 TIMED_WAITING으로, 인터럽트를 통해 대기를 중단할 수 있습니다.

3. 생산자-소비자 문제, 한정된 버퍼 문제에서의 효율성

• synchronized를 사용할 경우, 대기 집합(wait set)에서 원하는 스레드만 선택적으로 깨울 수 없어서 비효율적입니다.(비효율적이지 생산자-소비자 문제와 한정된 버퍼 문제를 해결할 수는 있습니다.)
• ReentrantLock은 Condition 객체를 활용하여 원하는 스레드만 선택적으로 깨울 수 있어 생산자-소비자 문제를 효율적으로 해결할 수 있습니다.

* 생산자-소비자 문제에 대해 synchronized 와 ReentrantLock 차이를 더 자세히 알고 싶다면 김영한님의 고급 자바 강의를 추천드립니다.

 

 

마치며..

이번 글에서는 synchronized와 ReentrantLock에 대해 알아보았습니다.

그동안 Async와 Sync의 차이, Non-Blocking과 Blocking의 차이를 이해했기에 멀티스레드를 충분히 이해했다고 생각했던 제 자신을 돌아보게 되었습니다. 이번 학습을 통해 Java는 애초에 멀티스레드를 염두에 두고 설계된 언어이며, 이를 지원하기 위한 다양한 동기화 방법을 제공한다는 점을 새롭게 깨달았습니다.

 

이 글을 작성하며 synchronized 는 스레드 간 데이터 전달이 필요 없는 간단한 동기화에서 사용할 수 있을 것 같고, ReentrantLock 은 concurrent 패키지에 있는 BlockingQueue의 내부 구현에 사용됩니다. 그러니, BlockingQueue 는 스레드 간의 데이터 전달하는 상황(생산자-소비자 문제 같이)에 사용하기에 적합하다는 생각이 듭니다.

읽어주셔서 감사합니다.

 

 

출처

- 김영한님의 고급 자바 강의

- Stackoverflow: What`s a monitor in Java?

- 테코블: Java로 동기화를 해보자!