park와 interrupt, BLOCKED와 WAITING

앞 글에서는 unpark가 허가증을 주면 park가 돌아온다는 것을 보았습니다. 그런데 park가 돌아오는 이유는 그것만이 아닙니다. 다른 스레드가 기다리는 스레드를 interrupt해도 돌아오고, 아무 이유 없이 돌아올 수도 있습니다. 이 글은 그중 interrupt를 자세히 봅니다. park는 Thread.sleep이나 Object.wait와 달리 InterruptedException을 던지지 않고 interrupt 플래그도 지우지 않기 때문에, 이 차이를 모르고 대기 반복문을 짜면 스레드가 쉬지도 끝나지도 않고 헛돌게 됩니다.

뒤에서는 parkNanos로 기다리는 시간에 상한을 두는 방법과, 스레드 덤프에서 비슷해 보이는 두 대기 상태 BLOCKED와 WAITING의 차이를 다룹니다. 둘 다 스레드가 멈춰 있다는 점은 같지만 기다리는 대상이 다르고 interrupt에 반응하는 방식도 달라서, 문제를 풀 때 써야 할 도구가 달라집니다. interrupt 플래그 자체의 동작은 interrupt 플래그와 취소를 다룬 글에서 설명했습니다.

interrupt를 받은 park는 예외 없이 돌아온다

먼저 sleep과 park를 나란히 놓고 interrupt에 어떻게 반응하는지 보겠습니다. 아래 프로그램에서 main 스레드는 스스로 interrupt 플래그를 세운 뒤 Thread.sleep을 한 번 호출하고, 다시 플래그를 세운 뒤 LockSupport.park를 한 번 호출합니다. 다른 스레드를 쓰지 않으므로 실행할 때마다 같은 결과가 나옵니다.

import java.util.concurrent.locks.LockSupport;

public final class SleepVersusPark {
    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        try {
            Thread.sleep(1_000);
            System.out.println("sleep: returned normally");
        } catch (InterruptedException e) {
            System.out.println(
                    "sleep: InterruptedException, flag=" + Thread.currentThread().isInterrupted());
        }

        Thread.currentThread().interrupt();
        LockSupport.park();
        System.out.println("park: returned, flag=" + Thread.currentThread().isInterrupted());
    }
}

sleep: InterruptedException, flag=false
park: returned, flag=true

첫 줄에서 sleep은 플래그가 이미 서 있는 것을 보고 1초를 기다리지 않은 채 곧바로 InterruptedException을 던졌습니다. 예외를 던지면서 플래그를 지웠기 때문에 catch 안에서 읽은 값은 false입니다. 두 번째 줄의 park도 기다리지 않고 바로 돌아왔지만, 예외를 던지지 않았고 플래그도 true 그대로입니다. 즉 park는 interrupt 요청이 오면 돌아오기만 하고, 그 요청을 어떻게 처리할지는 호출한 코드에 맡깁니다.

park가 플래그를 지우지 않는다는 것은 바로 다음 park도 기다리지 않는다는 뜻입니다. 아래 작업자는 스스로 interrupt한 뒤 park를 두 번 호출합니다. 첫 번째 park가 interrupt 요청을 써 버린다고 잘못 생각하면 두 번째 park에서는 작업자가 멈출 것이라고 예상하게 되는데, 출력의 wrong-second-wait가 바로 이 잘못된 예상을 나타냅니다. 첫 park 뒤에 플래그가 지워져 있었다면 !afterFirst가 true가 되어 예상이 맞았다는 뜻이 됩니다.

import java.util.concurrent.locks.LockSupport;

public final class ParkInterruptFlagAssumption {
    public static void main(String[] args) throws InterruptedException {
        Thread worker =
                new Thread(
                        () -> {
                            Thread.currentThread().interrupt();
                            LockSupport.park();
                            boolean afterFirst = Thread.currentThread().isInterrupted();
                            LockSupport.park();
                            System.out.println(
                                    "wrong-second-wait="
                                            + !afterFirst
                                            + ", flag="
                                            + Thread.currentThread().isInterrupted());
                        },
                        "flagged-parker");
        worker.start();
        worker.join();
    }
}

실행하면 wrong-second-wait=false, flag=true 한 줄을 출력하고 바로 끝납니다. 첫 park 뒤에 읽은 플래그가 true였으므로 !afterFirst는 false이고, 두 번째 park도 기다리지 않고 돌아와서 마지막에 읽은 플래그도 true입니다. 작업자가 스스로 플래그를 세우므로 결과가 스레드 실행 순서에 좌우되지 않고, 200번 실행했을 때도 매번 같은 줄이 나왔습니다.

대기 방법마다 interrupt에 반응하는 방식을 모아 보면 다음과 같습니다. 아래쪽 세 줄은 이 글 뒤쪽과 다음 글들에서 다시 다루는데, 비교하기 좋도록 미리 넣었습니다.

플래그를 확인하지 않는 park 반복문은 헛돈다

park는 대개 조건이 참이 될 때까지 기다리는 반복문 안에서 씁니다. 앞 글에서 본 것처럼 park는 이유 없이 돌아올 수도 있으므로, 돌아올 때마다 조건을 다시 확인해야 하기 때문입니다. 그런데 이 반복문이 interrupt 플래그를 확인하지 않으면 문제가 생깁니다. 플래그는 한 번 서면 누군가 지우기 전까지 남아 있으므로 그 뒤의 park는 모두 기다리지 않고 돌아오고, 반복문은 조건을 확인하고 park를 부르는 일을 쉬지 않고 되풀이합니다.

아래 프로그램은 그 상황을 100ms 동안 재현합니다. 플래그를 세운 뒤 조건 대신 시간을 보며 park를 계속 부르고, 그동안 park가 몇 번 돌아왔는지 셉니다.

import java.util.concurrent.locks.LockSupport;

public final class InterruptedParkSpin {
    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        long end = System.nanoTime() + 100_000_000L; // 100ms
        long parks = 0;
        while (System.nanoTime() - end < 0) {
            LockSupport.park();
            parks++;
        }
        System.out.println("parks=" + parks + ", flag=" + Thread.currentThread().isInterrupted());
    }
}

한 번 실행한 결과는 다음과 같습니다. parks는 100ms 동안 park가 돌아온 횟수이고, flag는 반복이 끝난 뒤의 인터럽트 상태입니다. park가 한 번이라도 제대로 기다렸다면 횟수는 아주 작아야 합니다.

parks=421381, flag=true

횟수는 실행할 때마다 크게 달라집니다. 이 글을 쓰며 2코어 환경에서 40번 실행했을 때 적게는 68,340번, 많게는 1,105,618번이었고, 플래그는 매번 true였습니다. 중요한 것은 정확한 값이 아니라, 기다려야 할 스레드가 0.1초 동안 수만 번에서 백만 번 넘게 깨어났다는 사실입니다. 실제 서비스에서 이런 반복문은 아무 일도 하지 않으면서 CPU 코어 하나를 계속 차지합니다. 게다가 park는 검사 예외를 던지지 않으므로 컴파일러도 이 실수를 알려 주지 않습니다.

해결하려면 park가 돌아온 뒤 플래그를 확인하고, 그 interrupt를 어떻게 처리할지 정해야 합니다. 대개 두 가지 중 하나를 고릅니다. interrupt를 그만 기다리라는 취소 요청으로 받아들여 sleep이나 wait처럼 InterruptedException을 던지거나, 끝까지 기다려야 하는 대기라면 요청이 왔다는 사실만 기억해 두었다가 대기가 끝난 뒤 플래그를 다시 세우는 것입니다. 아래 클래스의 두 메서드가 각각 이 두 정책입니다.

import java.util.concurrent.locks.LockSupport;

public final class ParkWaitPolicies {
    private volatile boolean ready;

    // 정책 1: interrupt를 취소 요청으로 받아들여 sleep·wait처럼 예외를 던진다
    void awaitReady() throws InterruptedException {
        while (!ready) {
            LockSupport.park(this);
            if (Thread.interrupted()) {
                throw new InterruptedException();
            }
        }
    }

    // 정책 2: 끝까지 기다리되, 받은 interrupt 요청은 대기가 끝난 뒤 되돌려 놓는다
    void awaitReadyUninterruptibly() {
        boolean interrupted = false;
        while (!ready) {
            LockSupport.park(this);
            if (Thread.interrupted()) {
                interrupted = true;
            }
        }
        if (interrupted) {
            Thread.currentThread().interrupt();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        ParkWaitPolicies cancellable = new ParkWaitPolicies();
        Thread.currentThread().interrupt();
        try {
            cancellable.awaitReady();
        } catch (InterruptedException e) {
            System.out.println(
                    "awaitReady: InterruptedException, flag="
                            + Thread.currentThread().isInterrupted());
        }

        ParkWaitPolicies stubborn = new ParkWaitPolicies();
        Thread waiter =
                new Thread(
                        () -> {
                            stubborn.awaitReadyUninterruptibly();
                            System.out.println(
                                    "awaitReadyUninterruptibly: returned, flag="
                                            + Thread.currentThread().isInterrupted());
                        },
                        "stubborn-waiter");
        waiter.start();
        waiter.interrupt();
        stubborn.ready = true;
        LockSupport.unpark(waiter);
        waiter.join();
    }
}

awaitReady: InterruptedException, flag=false
awaitReadyUninterruptibly: returned, flag=true

awaitReady는 Thread.interrupted()로 플래그를 읽으면서 지운 뒤 예외를 던집니다. 플래그를 지우고 예외를 던지는 것은 sleep이나 wait와 같은 규칙이므로, 호출하는 쪽은 이 메서드를 다른 블로킹 메서드와 똑같이 다룰 수 있습니다. main은 플래그를 미리 세워 둔 채 이 메서드를 부르므로, 첫 park가 곧바로 돌아오고 예외가 던져져 첫 줄의 flag=false가 나옵니다.

awaitReadyUninterruptibly도 Thread.interrupted()로 플래그를 지우지만 목적이 다릅니다. 플래그를 지워야 다음 park가 다시 기다리므로, 앞에서 본 헛도는 반복을 막을 수 있습니다. 대신 지역 변수 interrupted에 요청이 왔다는 사실을 적어 두었다가, 조건이 참이 되어 반복문을 빠져나온 뒤 Thread.currentThread().interrupt()로 플래그를 다시 세웁니다. 이렇게 해야 이 메서드를 부른 상위 코드가 취소 요청을 잃지 않습니다. 앞의 표에서 ReentrantLock.lock()이 락을 얻은 뒤에도 플래그를 남겨 두는 것도 안에서 이와 같은 일을 하기 때문입니다.

main의 두 번째 부분은 작업자를 시작하자마자 interrupt하고, 이어서 ready를 true로 만든 뒤 unpark합니다. 작업자가 반복문에 들어가기 전에 이 일이 모두 끝날 수도 있고, 반복문 안에서 interrupt를 먼저 받을 수도 있습니다. 앞의 경우에는 플래그를 지운 적이 없으므로 그대로 남아 있고, 뒤의 경우에는 지웠다가 반복문이 끝난 뒤 다시 세우므로, 어느 순서로 실행되든 두 번째 줄은 flag=true가 됩니다. 실제로 200번 실행했을 때 두 줄 모두 매번 같았습니다.

더 깊이: park가 예외를 던지지 않는 이유

park는 응용 코드보다는 동기화 도구를 만드는 데 쓰라고 만든 저수준 부품입니다. ReentrantLock, Semaphore, CountDownLatch 같은 도구는 내부의 AbstractQueuedSynchronizer(AQS)로 대기 큐를 관리하고, 큐에 들어간 스레드를 park로 재웁니다. 그런데 이 도구들은 interrupt를 다루는 정책이 서로 다릅니다. lock()은 interrupt를 받아도 계속 기다렸다가 락을 얻은 뒤 플래그를 다시 세워 두고, lockInterruptibly()는 곧바로 InterruptedException을 던집니다.

park가 예외를 던지거나 플래그를 지워 버린다면 앞의 정책은 만들 수 없습니다. park는 돌아오기만 하고 플래그는 건드리지 않기 때문에, 그 위에 올라가는 코드가 원하는 정책을 고를 수 있습니다. 앞에서 본 ParkWaitPolicies의 두 메서드가 이 두 정책을 아주 작게 줄인 모습입니다.

다른 스레드가 기다리는 스레드를 interrupt할 때

지금까지는 스레드가 스스로 interrupt했지만, 실제로는 다른 스레드가 기다리는 스레드를 interrupt하는 경우가 대부분입니다. 아래 프로그램에서 작업자는 래치 entered를 연 뒤 park에 들어가고, main은 작업자가 WAITING이 된 것을 확인한 다음 interrupt하고 작업자가 끝나기를 기다립니다. park에 넘긴 문자열은 앞 글에서 본 blocker로, 스레드 덤프에서 무엇 때문에 기다리는지 보여 주는 용도입니다.

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.locks.LockSupport;

public final class ParkInterruptObservation {
    public static void main(String[] args) throws InterruptedException {
        CountDownLatch entered = new CountDownLatch(1);
        Thread worker =
                new Thread(
                        () -> {
                            entered.countDown();
                            LockSupport.park("cancel-observation");
                            System.out.println(
                                    "returned flag=" + Thread.currentThread().isInterrupted());
                        },
                        "park-observer");
        worker.start();
        entered.await();
        while (worker.getState() != Thread.State.WAITING) {
            Thread.onSpinWait();
        }
        System.out.println("before=" + worker.getState());
        worker.interrupt();
        worker.join();
        System.out.println("after=" + worker.getState());
    }
}

이 글을 쓰며 200번 실행했을 때 출력은 매번 다음과 같았습니다. 첫 줄과 마지막 줄은 main이, 가운데 줄은 작업자가 출력한 것입니다.

before=WAITING
returned flag=true
after=TERMINATED

main이 래치만 기다리지 않고 상태까지 확인하는 이유는, 래치가 park 호출보다 먼저 열리기 때문입니다. 래치가 열렸다는 것은 작업자가 park 직전까지 왔다는 뜻일 뿐, 이미 기다리기 시작했다는 뜻은 아닙니다. 그래서 getState()가 WAITING을 돌려줄 때까지 Thread.onSpinWait()로 짧게 반복한 뒤 before를 찍고 interrupt를 보냅니다. 그러면 작업자의 park가 돌아오고, 작업자는 플래그를 읽어 returned flag=true를 찍은 뒤 끝납니다. join이 정상적으로 돌아온 뒤 읽은 상태는 TERMINATED입니다.

하지만 세 줄 가운데 언제나 성립하는 것은 마지막 줄뿐입니다. getState()는 그 순간의 상태를 찍은 사진이고, before를 출력할 때는 상태를 한 번 더 조회하므로 그 값이 여전히 WAITING이라는 보장도 없습니다. park가 이유 없이 먼저 돌아왔다면 작업자는 interrupt를 받기 전에 returned flag=false를 찍고 끝나며, 이 줄이 before보다 먼저 나올 수도 있습니다. 작업자가 WAITING에 머문 순간을 main이 한 번도 보지 못한 채 작업자가 끝나 버리면, 상한이 없는 확인 반복은 끝나지 않습니다. 그래서 상태 조회는 실험에서 들여다보는 용도로만 쓰고, 실제 코드에서 스레드끼리 진행을 맞출 때는 volatile 조건이나 래치 같은 동기화 수단을 써야 합니다.

위 단계 그림은 앞의 두 프로그램을 나란히 놓고, 각각에서 확실히 말할 수 있는 결과와 실행마다 달라질 수 있는 결과를 나눕니다. ParkInterruptFlagAssumption의 flag=true는 park가 플래그를 지우지 않는다는 규칙에서 나오는 결과입니다. 반면 ParkInterruptObservation의 before와 returned flag는 스케줄링에 따라 달라질 수 있는 순간의 조회입니다.

parkNanos로 기다리는 시간에 상한 두기

기다림에 시간 제한이 필요하면 parkNanos(nanos)를 씁니다. 허가증이 없고 interrupt도 없으면 최대 nanos 나노초 동안 기다리지만, 그 전에 unpark나 interrupt를 받거나 이유 없이 돌아올 수도 있습니다. 그리고 park와 마찬가지로 왜 돌아왔는지는 알려 주지 않습니다. 그래서 시간 제한 대기도 반복문으로 쓰고, 돌아올 때마다 조건과 interrupt와 남은 시간을 직접 확인해야 합니다.

아래 프로그램의 await는 ready 플래그가 참이 되기를 최대 30ms 동안 기다립니다. 이 예제에는 플래그를 바꾸는 스레드가 없으므로 시간 초과로 끝납니다.

import java.time.Duration;
import java.util.concurrent.locks.LockSupport;

public final class ParkNanosDeadline {
    private static final class ReadyFlag {
        volatile boolean ready;
    }

    public static void main(String[] args) throws InterruptedException {
        ReadyFlag flag = new ReadyFlag();
        Thread waiter =
                new Thread(
                        () -> System.out.println("outcome=" + await(flag, Duration.ofMillis(30))),
                        "timed-parker");
        waiter.start();
        waiter.join();
    }

    private static String await(ReadyFlag flag, Duration timeout) {
        long deadline = System.nanoTime() + timeout.toNanos();
        while (!flag.ready) {
            if (Thread.currentThread().isInterrupted()) return "interrupted";
            long remaining = deadline - System.nanoTime();
            if (remaining <= 0) return "timed-out";
            LockSupport.parkNanos(remaining);
        }
        return "ready";
    }
}

실행하면 outcome=timed-out이 출력되고, 200번 실행에서도 모두 같았습니다. 반복문은 매번 세 가지를 순서대로 확인합니다. ready가 참이면 성공, interrupt 플래그가 서 있으면 취소, 기한이 지났으면 시간 초과입니다. 셋 다 아니면 남은 시간만큼만 parkNanos로 기다린 뒤 처음으로 돌아가고, 30ms가 지나면 remaining이 0 이하가 되어 timed-out을 돌려줍니다.

여기서 핵심은 기한 deadline을 반복문 밖에서 한 번만 계산한다는 점입니다. 매번 parkNanos에 처음 받은 30ms를 그대로 넘기면, park가 일찍 돌아올 때마다 기다리는 시간이 새로 시작되어 전체 대기가 얼마든지 길어질 수 있습니다. 예산이 100ms이고 park가 두 번 일찍 돌아온 경우를 따라가 보겠습니다.

시간을 System.nanoTime()으로 재는 데도 이유가 있습니다. nanoTime은 경과 시간을 재기 위한 값이라서 벽시계 시각과 관계가 없고, 시스템 시계를 조정해도 경과 시간 계산이 흔들리지 않습니다. 대신 값 자체는 날짜와 아무 관련이 없어서, 같은 JVM 안에서 잰 두 값의 차이만 의미가 있습니다.

비교도 now >= deadline이 아니라 deadline - now <= 0처럼 뺄셈으로 해야 합니다. nanoTime의 기준점은 정해져 있지 않아서 deadline을 구하는 덧셈이 long 범위를 넘칠 수 있는데, 넘치더라도 두 값의 차이는 뺄셈으로 정확히 구해지기 때문입니다. LockSupport에는 기한을 절대 시각으로 받는 parkUntil(deadline)도 있지만, 이 인자는 1970년 1월 1일부터 센 밀리초, 즉 벽시계 시각입니다. 시스템 시계가 바뀌면 실제로 기다리는 시간도 달라질 수 있으므로, 최대 몇 밀리초까지 기다린다는 대기에는 nanoTime과 parkNanos의 조합이 맞습니다.

남은 시간이 0 이하인지를 parkNanos를 부르기 전에 확인하는 것도 의미가 있습니다. 문서에 따르면 parkNanos는 0이나 음수를 받으면 아무것도 하지 않고 바로 돌아옵니다. 그래서 이 확인이 없으면 기한이 지난 뒤로는 parkNanos가 곧바로 돌아오기만 하고, 반복문은 끝나지 않은 채 헛돕니다. 또 남은 시간이 아주 짧을 때는 park 자체의 비용과 운영체제 스케줄러의 시간 단위가 더 크기 때문에, 넘긴 값만큼만 정확히 기다리고 돌아온다고 기대할 수 없습니다.

이 예제에서 ready를 true로 바꾸는 쪽이 있다면 무엇을 해야 할까요? flag.ready = true로 조건을 바꾸고, 대기자의 Thread 참조를 보관해 두었다가 LockSupport.unpark도 호출해야 합니다. unpark를 빼먹어도 대기자는 언젠가 조건을 보지만, 그 시점은 parkNanos가 시간을 다 채우고 돌아온 뒤입니다. 반대로 unpark만 하고 조건을 바꾸지 않으면 대기자는 깨어나 조건을 확인한 뒤 다시 잠듭니다.

더 깊이: interrupt와 unpark가 보장하는 가시성

Java 메모리 모델에는 interrupt에 관한 순서 규칙이 하나 있습니다. JLS 17.4.4에 따르면 스레드 T1이 T2를 interrupt하면, 그 interrupt는 어느 스레드든 T2가 interrupt되었음을 알아내는 지점과 synchronizes-with 관계를 맺습니다. 알아내는 지점이란 InterruptedException이 던져지거나 Thread.interrupted 또는 isInterrupted를 호출한 곳입니다. 그래서 T1이 interrupt() 전에 쓴 값은, T2가 플래그를 확인해 true를 읽은 뒤라면 보입니다. 다만 park가 돌아온 것만으로는 이 순서가 생기지 않고, 플래그를 직접 읽어야 합니다.

unpark에는 이런 규칙이 없습니다. LockSupport 문서는 언제 park하고 unpark할지를 volatile(또는 원자) 변수로 정해야 안정적으로 쓸 수 있다고 하고, 이 메서드 호출들의 순서는 volatile 변수 접근에 대해서는 지켜지지만 일반 변수 접근에 대해서는 그렇지 않을 수 있다고 적고 있습니다. 즉 unpark 전에 일반 필드에 쓴 값이 깨어난 스레드에 보인다는 보장이 없습니다. ParkNanosDeadline의 ready나 연습 문제의 open을 volatile로 선언한 것이 이 때문입니다. volatile 변수에 쓴 값을 다른 스레드가 읽으면 두 동작 사이에 happens-before 관계가 생기므로, ready가 true인 것을 본 대기자는 그보다 앞서 쓰인 값도 볼 수 있습니다.

직접 만든 대기 반복문의 네 갈래

지금까지 본 대기 반복문은 모두 같은 뼈대를 가집니다. 반복할 때마다 조건이 참이면 성공으로, interrupt 플래그가 서 있으면 취소로, 기한이 지났으면 시간 초과로 끝내고, 어느 것도 아니면 다시 park합니다. park가 돌아왔다는 사실 자체는 이 네 갈래 어디에도 들어가지 않습니다. 허가증은 다시 확인해 보라는 신호일 뿐 대기 조건이 아니기 때문입니다.

여러 갈래가 동시에 참이면 확인 순서가 결과를 정합니다. ParkNanosDeadline은 조건을 가장 먼저 보므로, 조건이 참이 된 순간 interrupt도 와 있었다면 취소가 아니라 성공을 돌려줍니다. 취소를 무엇보다 먼저 존중해야 하는 작업이라면 interrupt 확인을 맨 앞으로 옮기면 됩니다. 어느 쪽이 맞는지는 업무가 정할 일이고, 중요한 것은 이 순서를 한곳에 모아 일부러 정해 두는 것입니다. 대기 코드를 도우미 메서드 하나에 모아 두면 호출하는 곳마다 park의 반환을 제각각 해석하는 실수도 줄어듭니다.

BLOCKED는 모니터를, WAITING은 사건을 기다린다

Thread.State에서 스레드가 멈춰 있는 상태는 세 가지입니다. BLOCKED는 synchronized 블록이나 메서드에 들어가려고 모니터 락을 기다리는 상태이고, wait에서 깨어난 스레드가 모니터를 다시 얻으려고 기다릴 때도 BLOCKED입니다. WAITING은 다른 스레드가 어떤 일을 해 주기를 시간 제한 없이 기다리는 상태로, 시간 제한 없는 Object.wait, 시간 제한 없는 Thread.join, LockSupport.park가 이 상태를 만듭니다. TIMED_WAITING은 같은 기다림에 시간 제한이 붙은 경우로 Thread.sleep, 시간 제한이 있는 wait와 join, parkNanos, parkUntil이 여기에 해당합니다.

아래 프로그램은 두 작업자를 각각 WAITING과 BLOCKED로 만든 뒤, BLOCKED인 작업자를 interrupt해 봅니다. plain-waiting은 park를 호출하고, monitor-blocked는 main이 쥐고 있는 monitor에 들어가려다 막힙니다.

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.locks.LockSupport;

public final class BlockedAndWaitingComparison {
    public static void main(String[] args) throws InterruptedException {
        Object monitor = new Object();
        CountDownLatch enteredPark = new CountDownLatch(1);
        Thread waiting =
                new Thread(
                        () -> {
                            enteredPark.countDown();
                            LockSupport.park();
                        },
                        "plain-waiting");
        Thread blocked =
                new Thread(
                        () -> {
                            synchronized (monitor) {
                                System.out.println("monitor-acquired");
                            }
                        },
                        "monitor-blocked");
        waiting.start();
        enteredPark.await();
        synchronized (monitor) {
            blocked.start();
            awaitState(waiting, Thread.State.WAITING);
            awaitState(blocked, Thread.State.BLOCKED);
            System.out.println("states=" + waiting.getState() + "," + blocked.getState());
            blocked.interrupt();
            System.out.println("blocked-after-interrupt=" + blocked.getState());
        }
        LockSupport.unpark(waiting);
        waiting.join();
        blocked.join();
    }

    private static void awaitState(Thread t, Thread.State state) throws InterruptedException {
        for (int i = 0; i < 200 && t.getState() != state; i++) {
            Thread.sleep(1);
        }
        if (t.getState() != state) throw new IllegalStateException(t.getName());
    }
}

200번 실행에서 출력은 매번 다음과 같았습니다. 앞의 두 줄은 main이 monitor를 쥔 채 출력하고, 마지막 줄 monitor-acquired는 blocked 작업자가 모니터에 들어간 뒤에 출력합니다.

states=WAITING,BLOCKED
blocked-after-interrupt=BLOCKED
monitor-acquired

main은 synchronized (monitor) 블록 안에서 blocked를 시작하므로 blocked는 블록 입구에서 멈춥니다. awaitState로 두 작업자가 기대한 상태가 된 것을 확인한 뒤 첫 줄을 찍고, 이어서 blocked를 interrupt합니다. 그래도 두 번째 줄처럼 blocked는 여전히 BLOCKED입니다. 모니터를 기다리는 스레드는 interrupt를 받아도 기다림을 포기하지 않고 예외도 받지 않습니다.

main이 블록을 빠져나가 모니터를 놓은 뒤에야 blocked가 들어가 monitor-acquired를 찍는데, 이때도 blocked의 interrupt 플래그는 true로 남아 있습니다. 마지막으로 main은 unpark(waiting)으로 park 중인 작업자를 깨우고 두 작업자를 join합니다.

awaitState는 1ms씩 쉬면서 최대 200번 상태를 확인하고, 그 안에 기대한 상태를 보지 못하면 IllegalStateException을 던집니다. 이 예외로 synchronized 블록을 빠져나가면 blocked는 결국 모니터를 얻고 끝나지만, 블록 뒤의 unpark(waiting)은 실행되지 않습니다. 그러면 waiting은 계속 park에 머물 수 있고, 데몬 스레드가 아니므로 JVM도 끝나지 않을 수 있습니다. 실제 코드라면 이런 정리 작업은 finally에 두어야 합니다.

대기가 끝나는 조건을 정리하면 다음과 같습니다. 같은 interrupt라도 WAITING인 스레드는 깨우지만, BLOCKED인 스레드는 플래그만 세워진 채 계속 모니터를 기다린다는 점이 가장 큰 차이입니다.

park는 쥐고 있는 모니터를 놓지 않는다

이 차이가 실제 문제로 이어지는 대표적인 경우가 synchronized 블록 안에서 park하는 코드입니다. 앞에서 본 것처럼 park로 기다리는 스레드는 WAITING이고, 모니터에 들어가지 못한 스레드는 BLOCKED입니다. 다음 코드에서 이 두 상태가 어떻게 맞물리는지 보세요.

synchronized (lock) {
    while (!ready) {
        LockSupport.park(); // lock을 쥔 채로 잠든다
    }
}

park는 이미 쥐고 있는 모니터를 놓지 않습니다. 그래서 이 스레드를 깨워 줄 스레드가 ready = true를 쓰려고 같은 lock에 들어가려 하면, 그 스레드는 BLOCKED가 되어 들어가지 못합니다. 한쪽은 WAITING으로 신호를, 다른 쪽은 BLOCKED로 모니터를 기다리면서 둘 다 진행하지 못하는 것입니다. 이 글을 쓰며 이 구조를 실행해 보니 0.3초가 지나도 두 스레드가 각각 WAITING과 BLOCKED에 머물러 있었고, ready는 여전히 false였습니다.

Object.wait는 이 점이 다릅니다. wait는 호출한 객체의 모니터를 내려놓고 기다리다가, 돌아오기 전에 그 모니터를 다시 얻습니다. 조건을 기다리는 동안 다른 스레드가 같은 모니터 안에서 조건을 바꿀 수 있는 것은 이 때문입니다. wait와 notify는 wait·notify와 모니터를 다룬 글에서 자세히 봅니다.

다만 wait가 놓는 것은 호출한 객체의 모니터 하나뿐이고, 그 스레드가 함께 쥐고 있던 다른 객체의 모니터는 쥔 채로 기다립니다. 그래서 대기 문제를 볼 때는 상태 이름만 보지 말고, 기다리는 동안 그 스레드가 어떤 락을 쥐고 있는지를 함께 확인해야 합니다.

ReentrantLock을 기다리는 스레드가 BLOCKED가 아니라 WAITING으로 보인다는 점도 기억해 둘 만합니다. ReentrantLock은 모니터가 아니라 대기 큐와 park로 만들어졌기 때문입니다. 스레드 덤프에서 어떻게 보이는지는 다음 글에서 봅니다.

기다림을 취소할 수 있어야 한다면

synchronized 진입을 기다리는 스레드는 interrupt로 멈출 수 없습니다. 사용자가 요청을 취소했거나 서버가 종료되는 중이라서 락을 기다리던 작업을 그만두게 해야 한다면, synchronized 대신 ReentrantLock의 lockInterruptibly()를 씁니다. 그러면 기다리는 중에 interrupt를 받았을 때 InterruptedException과 함께 빠져나올 수 있습니다. 일정 시간까지만 기다리고 싶다면 시간 제한이 있는 tryLock(time, unit)이 있습니다. 반대로 이런 요구가 없는 단순한 임계 영역이라면, 블록을 벗어날 때 자동으로 풀리는 synchronized가 더 읽기 쉽고 실수할 여지도 적습니다.

park로 동기화 도구를 직접 만드는 것은 마지막 수단입니다. 대기자가 여럿이면 대기 큐를 관리해야 하고, 시간 초과나 취소로 빠져나간 대기자를 큐에서 지우는 일과 놓친 신호를 처리하는 일까지 모두 직접 해야 합니다. 대기자 하나로 돌려 본 예제가 잘 동작했다고 해서 이런 경우까지 맞다는 뜻은 아닙니다. 대부분은 ReentrantLock, Semaphore, CountDownLatch, BlockingQueue 같은 java.util.concurrent의 도구로 충분합니다.

정리

• park는 interrupt를 받으면 예외 없이 돌아오고 플래그를 지우지 않습니다. 반면 sleep, wait, join은 InterruptedException을 던지면서 플래그를 지웁니다.
• 플래그를 확인하지 않는 park 반복문은 헛돌며 CPU를 씁니다. park가 돌아올 때마다 플래그를 확인해서 예외로 취소하거나, 기억해 두었다가 대기가 끝난 뒤 다시 세웁니다.
• 시간 제한 대기는 기한을 한 번만 계산하고, 돌아올 때마다 deadline - System.nanoTime()으로 남은 시간을 다시 구합니다.
• BLOCKED는 모니터를, WAITING은 unpark, notify, 스레드 종료 같은 사건을 기다립니다. 모니터 대기는 interrupt로 끝낼 수 없고, park는 쥐고 있는 모니터를 놓지 않습니다.
• getState()는 순간의 조회일 뿐이므로 스레드끼리 진행을 맞추는 데 쓰지 않습니다.

연습 문제

1. volatile boolean 조건과 대기자 Thread 참조를 써서, 최대 100ms 동안 열리기를 기다리는 게이트를 작성하세요. await(timeoutNanos)는 "opened", "interrupted", "timed-out" 중 하나를 돌려주고, open()은 조건을 먼저 true로 만든 뒤 unpark해야 합니다.
2. 1번 답안의 await를 같은 스레드에서 세 번 호출합니다. A는 이미 open()한 게이트에서 interrupt 플래그를 true로 세운 뒤 await(0)을 부릅니다. B는 새 게이트에서 플래그가 true인 채로, C는 새 게이트에서 플래그가 false인 채로 await(0)을 부릅니다. 각 호출의 반환값과 호출 뒤의 플래그를 구하세요.
3. 100ms 예산으로 기다리는 중에 parkNanos가 시작 후 32ms에, 그리고 다시 20ms 뒤에 일찍 돌아왔습니다. 두 번 모두 조건과 interrupt 플래그는 false였습니다. 각 재확인에서 다음 parkNanos에 넘길 값을 나노초로 구하세요. 그 뒤 48ms가 더 지나 돌아왔다면 결과는 무엇인가요?
4. 작업자 A는 synchronized (lock) 안에서 while (!ready) LockSupport.park();로 기다리고, 작업자 B는 같은 lock 안에서 ready = true를 쓴 뒤 A를 unpark하려 합니다. 다른 이유로 park가 돌아오는 일은 없다고 할 때 두 스레드는 어떻게 되나요? 또 BlockedAndWaitingComparison의 main이 synchronized (monitor) 블록 안에서 blocked.join()까지 호출하도록 바꾸면 어떻게 될까요?

import java.util.concurrent.locks.LockSupport;

public final class TimedParkGateSolution {
    private volatile boolean open;
    private volatile Thread waiter;

    String await(long timeoutNanos) {
        waiter = Thread.currentThread();
        long deadline = System.nanoTime() + timeoutNanos;
        while (!open) {
            if (Thread.currentThread().isInterrupted()) return "interrupted";
            long left = deadline - System.nanoTime();
            if (left <= 0) return "timed-out";
            LockSupport.parkNanos(this, left);
        }
        return "opened";
    }

    void open() {
        open = true;
        Thread target = waiter;
        if (target != null) LockSupport.unpark(target);
    }

    public static void main(String[] args) throws InterruptedException {
        TimedParkGateSolution gate = new TimedParkGateSolution();
        Thread worker =
                new Thread(() -> System.out.println(gate.await(100_000_000L)), "timed-gate");
        worker.start();
        while (gate.waiter == null) {
            Thread.onSpinWait();
        }
        gate.open();
        worker.join();
    }
}

import java.util.concurrent.locks.LockSupport;

public final class ConditionResultChecks {
    private static final class Gate {
        private volatile boolean open;
        private volatile Thread waiter;

        void open() {
            open = true;
            Thread target = waiter;
            if (target != null) LockSupport.unpark(target);
        }

        String await(long budgetNanos) {
            if (budgetNanos <= 0 || budgetNanos > 1_000_000_000L)
                throw new IllegalArgumentException("budget");
            waiter = Thread.currentThread();
            long deadline = System.nanoTime() + budgetNanos;
            while (!open) {
                if (Thread.currentThread().isInterrupted()) return "interrupted";
                long remaining = deadline - System.nanoTime();
                if (remaining <= 0) return "timed-out";
                LockSupport.parkNanos(this, remaining);
            }
            return "opened";
        }
    }

    public static void main(String[] args) {
        Gate early = new Gate();
        early.open();
        System.out.println("early=" + early.await(50_000_000L));
        System.out.println("closed=" + new Gate().await(1_000_000L));
        Thread.currentThread().interrupt();
        System.out.println("cancelled=" + new Gate().await(50_000_000L));
        System.out.println("flag-kept=" + Thread.currentThread().isInterrupted());
    }
}

early=opened
closed=timed-out
cancelled=interrupted
flag-kept=true

다음 글

다음 글에서는 park와 대기 큐로 만든 락인 ReentrantLock을 봅니다. 이 글에서 본 interrupt 처리 방식이 lock()과 lockInterruptibly()의 차이로 그대로 이어지고, 같은 스레드가 락을 여러 번 얻을 때와 대기 순서를 정하는 공정성 설정도 함께 다룹니다.