[이팩티브자바] 아이템 78. 공유 중인 가변 데이터는 동기화해 사용하라 (1)

💬 이팩티브자바 아이템 78을 읽고 정리한 글입니다.

이번 정리는 책과는 다소 다른 내용입니다 :D 

개념 자체가 어려운 부분이어서 책을 읽으며 궁금한 부분에 대해 조사하는 식으로 작성하였습니다 🙇‍♀️

두 편으로 나누어서 포스팅 할 예정입니다! 

아직 미흡한 점이 많아서, 더 정확한 정보를 알게 되면 본 게시글을 수정할 예정입니다.

---

✔️ 동기화란 무엇일까?

현재 잔액이 10000원이고, 각각 1000원씩 입금하는 행위를 5000번, 1000원씩 출금하는 행위를 5000번 반복한다고 가정해보자. 동일한 금액에 대해 동일한 횟수로 5000번씩 진행했기 때문에, 우리의 잔액에는 변화가 없다고 생각할 수 있다.

 

[synchronized 키워드 붙이기 전]

public class Main {
    public static void main(String[] args) {
        Bank bank = new Bank();

        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) {
                bank.increment();
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) {
                bank.decrement();
            }
        });

        thread1.start();
        thread2.start();

        try {
            thread1.join();
            thread2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println(bank.getMoney());
    }

    public static class Bank {
        private int money = 10000;

        public void increment() {
            money += 1000;
        }

        public void decrement() {
            money -= 1000;
        }

        public int getMoney() {
            return money;
        }
    }
}

그러나, 우리의 예상과 다르게 이상한 값이 튀어나온 것을 볼 수 있다. 심지어, 실행할 때마다 값이 다르게 나온다.

 

여기서, 개인적으로 여러 가지 실험을 하면서 신기했던 점이 있었다.

반복문을 몇 번 도는지에 따라서도 결과가 갈리는 것이다.

반복문을 각각 1000번씩 돌게 되면 다음과 같이 결과가 나온다.

우리가 원하는대로 결과가 나오는 것이다. 왜지? (여러 번 돌렸는데도 계속 이렇게 나왔다 ㅠㅠ)

 

내 생각으로 루프의 횟수 자체는 thread-safe에 영향을 주지는 않을 것이다.

아마 반복문의 횟수가 적다 보니까 스레드가 우연의 일치로 순차적으로 잘 실행될 수 있도록 스케줄링이 되었을 것 같다. (이게 JVM ↔ OS 사이의 스케줄링은 환경마다 다르기 때문에 내 노트북이 아니라, 다른 노트북이었으면 1000번을 돌려도 thread-safe 하지 않게 결과가 나올 수도 있고, 5000번을 돌려도 thread-safe 한 것처럼 나올 수도 있다.

같이 스터디를 진행하는 그레이도 다르게 나왔다고 한 것을 보아, OS 환경에 따라 다른 것으로 보인다!

 

다시 돌아가서, 왜 저런 요상한 값이 튀어나왔는지 고민해보자.

 

money -= 1000;

 

이 코드는 어떻게 보면 단순히 1000씩 값이 감소하는 로직만 실행될 것 같지만, 실제로는 총 3가지의 연산이 실행된다.

1. ‘money’ 변수를 메모리에서 읽는다.
2. 읽은 ‘money’ 변수를 감소시킨다.
3. 업데이트된 ‘money’ 변수를 다시 메모리에 쓴다.

실제로 바이트코드의 일부를 보면 다음과 같이 동작한다.

GETFIELD로 선언된 변수를 가져오고, ISUB을 통해서 값을 빼고, 뺀 값을 다시 PUTFIELD으로 쓰는 것을 볼 수 있다.

 

위의 상황에 해당하는 그림을 간단하게 그려보았다. 두 스레드는 서로 독립적으로 실행된다.

우리는 스레드 1이 값을 뺀 다음에 스레드 2가 값을 읽기를 원했겠지만, 실제로는 스레드 1이 Money라는 변수에 읽고, 뺀 다음에 값을 다시 업데이트 하기 전에 스레드 2가 값을 읽게 되면 두 스레드 모두 '10000'이라는 값을 읽게 된다. 

서로 타이밍이 좋지 않게 값을 읽고, 쓰다 보니까 위와 같이 이상한 값이 도출되는 것이다.

 

그렇다면, 어떻게 순차적으로 실행할 수 있을까?

우리는 synchronized라는 키워드를 사용할 수 있다.

synchronized 키워드는 메서드나 블록을 한 번에 한 스레드씩만 수행하도록 보장한다.

 

[synchronized 키워드를 붙인 후]

public class Main {
    public static void main(String[] args) {
        Bank bank = new Bank();

        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                bank.increment();
            }
        });

        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 5000; i++) {
                bank.decrement();
            }
        });

        thread1.start();
        thread2.start();

        try {
            thread1.join();
            thread2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println(bank.getMoney());
    }

    public static class Bank {
        private int money = 10000;

        public synchronized void increment() {
            money += 1000;
        }

        public synchronized void decrement() {
            money -= 1000;
        }

        public int getMoney() {
            return money;
        }
    }
}

한 번에 하나의 스레드만 실행되도록 보장하기 때문에, 메서드의 실행 순서도 일관되고 공유 변수에 대해서도 원하는 대로 접근되는 것을 볼 수 있다. 덕분에 여러 번 실행을 거치더라도 계속 10000이라는 결과가 보장된다.

 

바이트 코드를 살펴보자.

아까와 다르게 synchronized라는 키워드가 붙은 것을 확인할 수 있다.

사실 그외 바이트 코드의 차이는 거의 나지 않는다. 내부적으로 synchronized 키워드를 붙여넣고 알아서 락을 관리하는 것으로 판단된다.

 

우리는 이렇게 순차적으로 스레드가 실행되는 것을 보장하는 것을 ‘동기화한다’라고 표현할 수 있다. 일종의 lock을 건다고 볼 수 있다.

자바의 Lock 인터페이스를 가면 다음과 같은 주석이 작성되어 있다. (synchronized가 자바의 Lock 인터페이스를 사용한다는 것은 아니다! 그저, 비슷한 개념이기 때문에 설명하고자 하는 것이다.)

Lock은 공유 리소스에 대해 여러 스레드에서 사용될 때 제어하는 도구이다.
이는 공유된 리소스에 대한 ‘독점적인 접근’을 제공한다.

 

여기서 중요한 것은 공유 리소스에 대한 독점적인 접근을 제공한다는 것이다.

동기화는 이런 식으로 여러 스레드가 같은 변수를 수정하더라도, 항상 정상적으로 저장된 값을 불러오도록 원자성을 보장하게 된다.

 

본 책에서는, 자바는 long, double을 제외한 변수를 읽고 쓰는 것이 원자적이라고 표현했다. 왜일까?

자바의 primitive type을 생각해보자.

https://ramj2ee.blogspot.com/2015/09/java-tutorial-java-primitive-data-types.html

JVM은 데이터를 4바이트 단위로 처리한다. (=32비트만큼 처리가 가능하다.)

그렇기 때문에 32비트 이하인 boolean, byte, short, char, int, float의 경우 한 번에 처리할 수 있게 된다. 하나의 명령어는 최소 단위의 작업이기 때문에, 작업 중간에 다른 스레드가 끼어들 수 없어서 원자성을 보장하게 된다.

 

그러나, long과 double의 경우 64비트이기 때문에 한 번에 처리할 수가 없어서 원자성을 보장하지 못한다.

이를 보장하기 위해서 ‘volatile’이라는 키워드를 제공한다. (혹은 AtomicLong, AtomicDouble 같은 클래스를 사용해도 된다.) 우선 이에 대해서는 덮어두자. (다음 포스팅에서 제대로 다루어보겠습니다!)

 

---

✔️ 동기화를 어떻게 할 수 있을까? 

먼저, 단순하게 하나의 스레드가 일을 하는 동안 다른 스레드를 멈춘다고 생각해보자.

현재는 deprecated된 Thread.stop()이라는 메서드가 존재하기는 하지만, 이건 매우 위험한 방법이기 때문에 필드를 통해서 관리하는 방법이 있다.

import java.io.IOException;
        import java.util.concurrent.TimeUnit;

public class Main {
    private static boolean isStop = false;
    public static void main(String[] args) throws IOException, InterruptedException {
        Thread thread = new Thread(() -> {
            int count = 0;
            while (!isStop) {
                count++;
            }
        });
        thread.start();
        TimeUnit.SECONDS.sleep(1);
        isStop = true;
    }
}

1초 후에 true로 플래그가 변경되면서 종료될 것이라고 생각할 수 있다.

그러나, 이 친구는 종료되지 않는다. 계속 실행이 될뿐이다.

 

책에서는 아래의 코드가 JVM이 호이스팅을 통해 최적화한 코드라고 소개했다.

//before
while (!isStop) {
    count++;
}

// after
if (!isStop) {
    while (true) {
        count++;
    }
}

개인적으로, 왜 이를 호이스팅이라고 하는지 잘 이해가 되지 않았다. 호이스팅은 기본적으로 자바스크립트에서 많이 사용되는 개념이다.

 

💬 이를 왜 호이스팅이라고 설명하는 것일까?

호이스팅은, 변수나 함수를 선언하기 전에 사용할 수 있도록 만드는 최적화 기술이다.

자바에서 변수는 호이스팅이 안 되지만, 함수의 경우 선언하기 전에 호출할 수 있기 때문에 호이스팅이 가능하다.

 

그러나 책에서 설명하는 호이스팅은, 루프 내에서 행할 필요가 없는 연산들은 루프 내부가 아닌 외부에서 실행하자는 것이다.

JIT 컴파일러가 저렇게 루프 밖으로 꺼낸 덕분에 끝나지 않게 되는 것이다.

여기서 사용한 -Djava.compiler는 JVM에서 사용되는 컴파일러의 옵션을 선택한다.

 

java -Djava.compiler=<compiler-name> <class-name>

 

NONE으로 하게 되면, JIT 컴파일러를 비활성화하게 된다.

 

💬 JIT 컴파일러란?

자바의 컴파일 과정은 다음과 같이 이루어진다.

1) 자바 소스코드 (.java) 파일을 자바 컴파일러가 .class 파일로 컴파일 [여기까지 컴파일 타임에 실행]

2) 이때, 이는 바이트 코드 형식이며 컴파일된 바이트 코드를 JVM의 클래스 로더에게 전달한다. [런타임에 실행]

3) 클래스 로더는 다이나믹 로딩을 통해 필요한 클래스들을 로딩 및 링크하여, JVM의 메모리에 올린다.

4) JVM 메모리에 올라온 바이트 코드를 명령어 단위로 나누어 실행되는데, 이때 2가지의 실행 엔진을 사용한다.

 

첫 번째로, 인터프리터를 통해서 바이트 코드를 한 줄씩 읽는다. 만약 해당 메서드가 일정 횟수 이상 호출이 된다면, JIT 컴파일러를 사용하게 되는데 이때 최적화된 기계어 코드를 변환해주게 된다. 한 줄씩 읽는 인터프리터와 달리, JIT 컴파일러를 사용하게 되면 바이트 코드를 함수나 파일 단위로 컴파일한다. 이때, 반복되는 메서드에 대해서는 내부적으로 캐싱을 진행하기 때문에 최적화가 가능하다.

 

아무튼, JIT 컴파일러는 내부적으로 자바 프로그램의 실행 성능을 향상시키기 위해서 루프 안에서 반복되는 연산은 루프 밖으로 꺼내 최적화를 진행한다. 루프 안에서 연산을 반복할 때마다 해당 연산을 재수행하는 것이 비효율적이기 때문에 루프 밖에서 미리 계산하고 최적화하는 것이다. 이러한 최적화 방법을 호이스팅이라고 한다.

 

코드로 간단하게 살펴보자.

for (int i = 0; i < 1000000; i++) {
    int a = 10;
    int b = 20;
    int c = a + b;
    result += c;
}

다음과 같이 루프 내부에서 a, b라는 변수를 계속 선언한다고 생각해보자. 이 코드를 호이스팅을 통해 다음과 같이 변경할 수 있다.

int a = 10;
int b = 20;
for (int i = 0; i < 1000000; i++) {
    int c = a + b;
    result += c;
}

이렇게 루프 내에서 굳이 행할 필요가 없는 연산에 대해서 바깥으로 빼버리는 것이다.

 

우리가 앞에서 봤던 코드를 생각해보자.

while (!isStop) {
    count++;
}

JIT 컴파일러는 루프 내부에서 계속 isStop 변수에 대해 체크하는 것을 비효율적이라고 판단한다. 왜냐하면, 싱글 스레드 환경이라면 제어가 저 코드까지 내려왔을 때 외부 요인으로 인해 isStop이라는 변수가 변경될 일이 없기 때문이다.

if (!isStop) {
    while (true) {
        count++;
    }
}

그래서 JIT 컴파일러는 루프 내부에서 값을 체크하지 않고, 외부에서 1번만 체크한 다음에 하위에서 while문으로 계속 반복하게 된다.

그렇기 때문에 우리의 코드에서 메인 스레드가 isStop이라는 변수를 true로 변경하더라도, 이미 if문의 조건은 끝났기 때문에 무한루프에 빠져버리고 마는 것이다.

 

이렇기 때문에 멀티 스레드 환경에서는 컴파일러 전략을 잘 선택해야 한다...!

성능 향상에 유용하지만, 이런 식으로 버그가 발생할 수 있기 때문이다.

 

자, 다시 돌아가서 위의 그림을 다시 보자.

한 번 더 첨부함

JIT 컴파일러 옵션을 껐기 때문에 첫 번째 실행에서는 바로 종료가 되는 것을 볼 수 있지만, 그냥 단순히 Main.java를 실행했을 때는 강제 종료 (^C)를 한 것을 볼 수 있다. 

 

그렇다면, 우리는 어떻게 이 문제를 해결해야 할까?

import java.io.IOException;
        import java.util.concurrent.TimeUnit;

public class Main {
    private static boolean isStop = false;

    private static synchronized void requestStop() {
        isStop = true;
    }

    private static synchronized boolean isStop() {
        return isStop;
    }

    public static void main(String[] args) throws IOException, InterruptedException {
        Thread thread = new Thread(() -> {
            int count = 0;
            while (!isStop()) {
                count++;
            }
        });
        thread.start();
        TimeUnit.SECONDS.sleep(1);
        requestStop();
    }
}

 

synchronized 키워드를 사용하여 다음과 같이 수정하였다.

현재 isStop의 필드를 업데이트하는 메서드 (requestStop)와 필드를 읽어오는 메서드 (isStop) 모두를 동기화하였다.

흔히들 쓰기 동기화만 진행하면 되는 게 아니냐고 생각할 수 있겠지만, 두 가지 모두 동기화가 되어야 한다. (라고 책에서 말했다.)

 

🤔 그런데, 실제로 실험해보았을 때 쓰기 동기화만 했을 경우는 실행이 종료되지 않았지만, 읽기 동기화만 했을 때는 실행이 종료되었다. 이유에 대해서 생각해보았다. 아래는 필자의 생각이기 때문에 읽지 않아도 된다.

읽기만 동기화를 했을 경우 변수를 읽는 도중에는 락을 걸었기 때문에, Main 스레드가 종료되며 값을 변경한 뒤, 해당 값이 true인 상태로 계속 받아올 수밖에 없으니까 (외부에서 변경할 수가 없음) 종료되는 게 아닐까 싶다. (=항상 최신값을 반환한다)

반면에 쓰기만 동기화를 했다면, Main 스레드가 종료하기 전에 값을 변경하는 것까지는 원자적이지만, 값을 읽어오는 스레드는 락이 없이 그냥 실행된다. 이러면 메서드를 호출하는 Main 스레드와, isStop()을 호출하는 스레드에 대해서 메모리 사이의 일관성이 맞지 않게 될 수 있다. 일관성이 깨지기 때문에 제대로 된 결과값을 읽어오지 못하고 어떠한 쓰레기값을 읽어오면서 종료가 안 되는 것이 아닐까... 라는 게 나의 생각이다.

어떠한 이유든, 두 메서드 모두에 synchronized 키워드를 붙여야 더욱 안전하게 실행되는 것은 확실하다.

웬만하면 읽기와 쓰기 모두 키워드를 붙여서 원자성을 보장하도록 하자.

 

---

💬  synchronized 키워드의 원리

우선, 자바에서 모든 객체들은 ‘Monitor’라는 것을 가지며, 여러 스레드가 해당 객체로 동시에 접근하는 것을 막게 한다. 왜냐하면, 객체는 Heap 영역에 저장되기 때문에 모든 스레드가 공통적으로 사용할 수 있기 때문이다.

 

여기서 monitor란, 스레드 동기화를 위한 여러 방법 중 'critical section (임계 영역)'에 대해 동기화를 제공하는 일종의 매커니즘이다. 임계 영역은 공유된 자원에 대해서 단 하나의 스레드만 접근하도록 하는 것이며, 이때 하나의 프로세스에 속한 스레드만 접근이 가능하게 된다. (다중 프로세스에 속한 스레드는 X)

 

Each object in Java is associated with a monitor, which a thread can lock or unlock. Only one thread at a time may hold a lock on a monitor. Any other threads attempting to lock that monitor are blocked until they can obtain a lock on that monitor. A thread t may lock a particular monitor multiple times; each unlock reverses the effect of one lock operation.

그리고, synchronized는 이러한 critical section에 대해서 설정해주는 것이다! 

synchronized를 통해 임계 영역에 대해 선언을 해주고, 해당 임계 영역에 대해 모니터 락을 얻을 수 있으며,

이렇게 얻은 모니터 락은 해당 임계 영역을 사용하는 동안 다른 스레드에서 접근하지 못하도록 막게 된다!

 

monitor를 가지는 것을 monitorenter, 놓는 것을 monitorexit이라고 한다.

monitorenter를 통해 객체에 대한 락을 획득하고, 다른 스레드에서 해당 객체의 모니터를 획득하기 전까지는 스레드를 block 상태로 유지한다. 동작 과정을 간단하게 살펴보자면 아래와 같다.

 

1. synchronized 블록이 시작되면, JVM은 해당 객체에 대한 락을 획득한다. (monitorenter)
2. synchronized 블록에서 실행되는 모든 코드는, 해당 객체의 락을 가지고 실행된다.
3. 다른 스레드에서 해당 객체의 락을 획득하려고 할 때, 해당 스레드는 락을 획득하기 전까지 block 상태로 유지된다.
4. synchronized 블록이 실행 완료되면, JVM은 해당 객체에 대한 락을 해제한다. (monitorexit)

 

결과적으로 락을 활용하여 한 번에 하나의 스레드만 접근하도록 만든다고 이해하면 된다!

---

 

아직 개념이 완벽하게 습득된 느낌은 아니지만... 추가적으로 관련해서 또 글을 작성해보도록 하겠습니다...! 🙇‍♀️