자바에서 Deterministic Execution을 보장하는 방법

자바는 가비지 컬렉션(GC), 멀티스레딩, JIT(Just-In-Time) 컴파일러 최적화 등의 요소로 인해 실행 결과가 비결정적(Non-Deterministic)일 가능성이 있습니다. 그러나 금융 시스템, 실시간 애플리케이션, 블록체인 노드, 자동화된 테스트 환경에서는 같은 입력에 대해 항상 동일한 결과를 보장해야 합니다. 이를 Deterministic Execution(결정론적 실행)이라고 하며, 자바에서 이를 보장하는 것은 쉽지 않은 과제입니다.

이번 글에서는 자바에서 Deterministic Execution을 보장하기 위해 고려해야 할 요소들을 살펴보고, 이를 해결하는 방법을 알아보겠습니다.

1. 가비지 컬렉션(GC)과 결정론적 실행

가비지 컬렉션이 비결정성을 유발하는 이유

자바의 GC는 자동으로 메모리를 관리하는 장점이 있지만, 언제 GC가 실행될지는 JVM 내부 정책에 따라 달라집니다. 이로 인해 애플리케이션 실행 타이밍이 변동될 수 있고, 특정한 조건에서 예상하지 못한 지연이 발생할 수도 있습니다.

예를 들어, 다음과 같은 코드가 있다고 가정해 봅시다.

public class GCTest {
    public static void main(String[] args) {
        long startTime = System.nanoTime();
        for (int i = 0; i < 1000000; i++) {
            String s = new String("Test" + i); // 새로운 객체 생성
        }
        long endTime = System.nanoTime();
        System.out.println("Execution Time: " + (endTime - startTime) + " ns");
    }
}

위 코드는 여러 번 실행할 때마다 서로 다른 실행 시간을 가질 가능성이 큽니다. 이는 GC가 언제 실행되는지에 따라 성능이 달라지기 때문입니다.

해결 방법: 가비지 컬렉션 튜닝 및 관리

GC 로그 분석 및 튜닝
- JVM 옵션을 활용해 GC 로그를 활성화하고 분석할 수 있습니다.
```
java -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -jar myapp.jar
```
- 특정 GC 알고리즘을 선택하여 영향을 줄일 수도 있습니다.
```
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar myapp.jar
```
GC 발생을 최소화하는 프로그래밍 기법
- 객체 풀링(Object Pooling)을 사용해 객체 생성을 줄이기
- StringBuilder와 같은 불변 객체 대신 변경 가능한 객체 활용
- -XX:+UseShenandoahGC와 같은 낮은 레이턴시 GC 선택

2. 멀티스레딩과 동기화 문제

비결정성을 유발하는 멀티스레딩 문제

자바에서 멀티스레딩을 사용할 경우, 스레드 스케줄링과 실행 순서는 운영체제와 JVM의 상태에 따라 달라질 수 있습니다. 같은 입력을 주더라도 실행 결과가 달라질 가능성이 있습니다.

다음 예제를 보겠습니다.

public class ThreadTest {
    private static int counter = 0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) counter++;
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) counter++;
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println("Counter: " + counter);
    }
}

위 코드를 실행하면 매번 다른 값이 출력될 수 있습니다. counter++는 원자적 연산이 아니므로, 스레드 간 경합(Race Condition)이 발생하기 때문입니다.

해결 방법: 동기화 및 Lock-Free 프로그래밍

synchronized 블록 사용
```
synchronized(this) {
    counter++;
}
```

Atomic 변수를 활용

private static AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();

ReentrantLock 활용

private static final ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    counter++;
} finally {
    lock.unlock();
}

3. JIT 컴파일러와 실행 순서 변동

JIT 컴파일러 최적화로 인한 실행 순서 변경

JVM의 JIT 컴파일러는 실행 성능을 최적화하기 위해 코드의 실행 순서를 변경할 수 있습니다. 이는 실행 결과가 예상과 다르게 나올 가능성을 높입니다.

예를 들어, 자바 메모리 모델(Java Memory Model, JMM)에서는 변수 값이 예상보다 먼저 읽히거나 늦게 쓰일 수 있습니다.

class ReorderingExample {
    static int a = 0, b = 0;
    static int x = 0, y = 0;

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            a = 1;
            x = b;
        });
        Thread t2 = new Thread(() -> {
            b = 1;
            y = a;
        });
        t1.start(); t2.start();
        t1.join(); t2.join();
        System.out.println("x: " + x + ", y: " + y);
    }
}

이 코드는 특정 상황에서 (x, y) = (0, 0)이 출력될 수도 있습니다. 이는 CPU와 JIT 최적화가 실행 순서를 변경할 수 있기 때문입니다.

해결 방법: volatile 및 메모리 배리어

volatile 키워드 사용
- volatile을 사용하면 변수의 변경이 즉시 반영되어 실행 순서 변경을 방지할 수 있습니다.
private volatile int sharedVar;
Memory Barrier 사용 (Unsafe API 활용)
- JDK 9 이상에서는 VarHandle API를 활용하여 메모리 배리어를 적용할 수 있습니다.
Unsafe.getUnsafe().storeFence();

정리

자바에서 Deterministic Execution(결정론적 실행)을 보장하는 것은 쉽지 않지만, 다음과 같은 전략을 통해 해결할 수 있습니다.

GC 영향 최소화: 객체 생성을 줄이고, GC 튜닝을 통해 예측 가능성을 높인다.
멀티스레딩 동기화: synchronized, Atomic 클래스, ReentrantLock을 사용해 실행 순서를 일정하게 유지한다.
JIT 및 실행 순서 관리: volatile, 메모리 배리어를 사용해 실행 순서 변경을 방지한다.

이러한 기법을 적절히 활용하면, 금융 시스템, 블록체인, 실시간 애플리케이션에서 더욱 안정적인 결과를 얻을 수 있습니다.

명이나물의 기술 & IT