개요

• 웹 서버를 개발할 때 병렬 프로그래밍에 대한 이해는 중요하다고 생각합니다.

• Thread Safety가 보장되지 않는 상황은 개발자의 골치를 아프게 합니다.

• 어느 때는 정상적으로 동작하는 것 같다가도, 타이밍에 따라 버그가 발생하게 됩니다.

• 이러한 버그는 상황에 따라 재현될 수도, 안될 수도 있어서 디버깅하기가 무척 까다롭습니다.

• 스스로도 인지하지 못한 버그를 만들지 않기 위해서 Thread Safety에 대해 조사해봅니다.

• 바쁘신 분들은 마지막 정리 부분을 보시면 되겠습니다.

목표

🚀 Thread Safety의 정의에 대해서 알아봅니다.
🚀 간단하게 JVM Runtime Data Aread와 공유 자원에 대해서 알아봅니다.
🚀 단일연산과 복합연산에 대해서 알아봅니다.
🚀 경쟁조건에 대해서 알아봅니다.
🚀 Thread Unsafety한 상황을 살펴보고 고쳐봅니다.

1. Thread Safety란?

• 자바는 Multi Thread Progamming Language입니다.

• Multi Threading를 간단하게 말하자면 “여러 Thread가 한 Process의 자원을 공유하며 동작하는 것” 으로 볼 수 있습니다.

• 즉, 한 프로세스가 동시에 여러 일을 할 수 있는 것을 의미합니다.

• 여기서 동시라는 의미는 파고들 수록 복잡해질 수 있습니다. Single Core Processor에서는 실제로 여러 일을 처리할 경우 동시에 그 일을 수행하는 것이 아니라, 사람이 느끼지 못할 정도로 빠르게 번갈아가면서 처리하는 것을 말합니다. 물론 Multi Core Processor에서는 실제로 동시에 Task를 수행할 수 있습니다. 이에 대한 자세한 내용은 👉 동시성과 병렬성의 차이 👈 를 참고하시면 이해하기 좋습니다.

• Process의 한 공유 자원에 여러 Thread에서 접근하면 동시성 문제가 발생할 수 있습니다.

• Thread Safety란 “Process의 한 공유 자원에 여러 Thread가 접근하여 연산을 할 때, 항상 그 연산결과의 기대값이 일관성을 가짐을 보장하는 것”을 의미합니다.

• 예시 코드로 살펴보겠습니다.

@ThreadSafe
public class Calculator{
	public int plus(int a, int b){
		return a + b;
	}
}

• Calculator의 plus 메소드는 두 인자를 받아 더한 후 반환합니다.
• Calculator의 Instance에 여러 Thread가 동시에 접근하더라도 항상 기대하는 결과 값을 얻을 수 있을 것입니다.
• int a와 int b는 Stack영역의 변수이므로 다른 Thread에서 간섭할 수 없습니다.
• 이렇게 Thread Safety는 일관성(혹은 정확성)의 개념과 깊은 관계를 가집니다.
• 일관성은 "여러 쓰레드에서 어떤 타이밍에 실행하더라도 기대하는 값이 정확히 나오는 것"이라 생각해볼 수 있습니다.

2. Multi Threading 환경에서의 Issue

• JVM의 Heap Area와 Method Area는 모든 Thread에서 접근할 수 있습니다.

• JVM의 Runtime Data Area에 대한 설명이 필요하신 경우 👉 해당 아티클 👈을 참고해주시기 바랍니다.

• 이렇게 모든 Thread에서 접근할 수 있는 공유 자원은 경쟁조건을 가지게 됩니다.

• 경쟁조건은 쉽게 말하자면 "타이밍이 좋지 않을 때 결과가 잘못될 가능성"이라 볼 수 있겠습니다.

• 역시 백문이불여일견 입니다.

public class ChattingRoom{
    private int count = 0;

    public void enter(){
        count++; // 채팅방에 들어오면 참가 인원을 증가시킨다.
    }

    public long getCount(){
        return count;
    }

    public static void main(String[] args) throws InterruptedException {
        System.out.println("start");
        final ChattingRoom chattingRoom = new ChattingRoom();
        UserEntrance entrance = new UserEntrance(chattingRoom);
        UserEntrance entrance2 = new UserEntrance(chattingRoom);
        UserEntrance entrance3 = new UserEntrance(chattingRoom);
        entrance.start();
        entrance2.start();
        entrance3.start();
        Thread.sleep(10000);
        System.out.println("채팅방 인원 수 = " + chattingRoom.getCount());
        System.out.println("end");
    }
}

public class UserEntrance extends Thread{
    private final ChattingRoom chattingRoom;

    public UserEntrance(ChattingRoom chattingRoom) {
        this.chattingRoom = chattingRoom;
    }

    @Override
    public void run() {
        for (int i = 0; i < 10000; i++) {
            chattingRoom.enter(); // 증가!
        }
    }
}

/*
start
채팅방 인원 수 = 20891 
end
*/

• 채팅방에 유저가 들어오면 참여자 수를 증가시키는 클래스입니다.

• 큰 문제가 없어 보일 수도 있지만(...) 위 코드는 타이밍에 따라서 버그를 일으킬 가능성이 있습니다. 😈 😈 😈

• 10,000번 씩 3개의 Thread에서 ChattingRoom객체의 count를 증가시켰으니 결과는 30,000이 나올 것이라 기대할 것입니다. 하지만 엉뚱한 결과가 나왔습니다.

• 이런 결과가 나온 이유는 count를 증가시키는 연산의 타이밍이 좋지 않았기 때문입니다.

• [count++] 연산은 단일연산으로 보이겠지만 사실 복합연산입니다.

- [count++]은 아래 연산들의 조합이다.
- 연산 1 : count로부터 값을 읽어온다.
- 연산 2 : 읽어온 값에 1을 더한다
- 연산 3 : 더한 값을 count에 저장한다. 

• 이러한 복합연산에 대해서 Thread-1, 2, 3은 아래와 같이 연산을 하게됩니다.

- 최초에 count는 0이다. 
- Thread-1이 연산 1, 연산 2를 수행한다. 그리고 Context Switching 일어난다.
  그 때문에 연산 3을 수행하지 못했고 아직 count는 0이다.
- Thread-2가 연산 1을 수행한다 이 때까지 count의 값은 0이다. 
  그리고 연산 2~3을 수행한다. count의 값은 1이 된다.
- 다시 Context Switching 일어난다.
  이제 Thread-1이 연산 3을 수행한다. 연산 2까지의 결과는 1이였고, 그 값을 count에 넣는다.
- 결국 두 번의 증가 연산이 있었지만 결과적으로 count의 값은 1이된다.
  우리의 기대값은 2였으나 좋지 않은 타이밍 즉, 경쟁조건에 의해서 결과 값이 1일 수도, 2일수도 있는 상황이 발생한다.

• 위와 같은 상황이 여러 번 일어날 수록 기대했던 결과는 얻을 수 없습니다
• 또한 이러한 상황이 몇 번 일어날 지 예상도 할 수 없습니다. 운이 좋다면 정상 결과를 얻을 수도 있고, 개발자는 테스트를 통과시킬 것입니다...! 🤯 🥵

3. Thread Safety가 보장되지 않는 원인

• 위의 예로부터 보면 무엇이 Thread Safety를 위협하는지 알 수 있습니다.
• 그 원인을 큰 틀에서 나누면 아래와 같을 것입니다.

원인 1. 공유자원과 복합연산(Race Condition)

• 여기서 공유 자원이란 모든 Thread에서 접근 가능한 자원을 의미합니다.
• 이는 Heap Area에 존재하는 객체의 Instance Variable과 Method Area에 존재하는 Class Variable입니다.
• 두 객체는 모든 JVM의 모든 Thread에서 공유 되기에 어떤 연산을 수행할 시 동시에 해당 변수에 접근이 가능하게 됩니다.
• 결국 수정가능한 객체의 상태 값을 가지고, 동기화를 하지 않는다면 이는 동시성 이슈를 가져오게 됩니다.
• 우리가 하고자 하는 연산이 원자성을 가지게 되면 여러 쓰레드의 Context Switching이 일어나더라도 기대하는 값을 얻을 수 있습니다.
• 즉, 어떤 복합연산이 있더라도 그 연산을 하기 전과 한 후로만 나눠질 수 있다면 이는 단일연산으로 보아도 무방할 것입니다.
• 이는 암묵적 락이나, 명시적 락을 통해서 보장할 수 있습니다.
• 하지만 동기화가 되어있지 않은 복합연산은 경쟁조건을 가지게 되고 위의 예시코드와 같이 도대체 어떤 결과가 나올지 알 수 없는 상황이 펼쳐집니다.

원인 2. 메모리 가시성(Memory Visibility)

• 메모리 가시성은 "한 Thread가 공유 자원을 변경했을 때 다른 Thread에서도 변경된 최신값을 읽어올 수 있느냐"를 의미합니다.

• 이 또한 코드로 살펴보겠습니다.

public class NoVisibility {
    private static boolean ready;
    private static int number;

    private static class ReaderThread extends Thread{
        @Override
        public void run() {
            while (!ready) {
                Thread.yield();
            }
            System.out.println("number = " + number);
        }
    }

    public static void main(String[] args) {
        new ReaderThread().start();
        new ReaderThread().start();
        new ReaderThread().start();
        new ReaderThread().start();
        number = 45;
        ready = true;
    }
}

• 위 코드에서 Main Thread가 number와 ready의 값을 변경하고 있습니다.
• 이때 ReaderThread1~4에서는 Main Thtread가 값을 바꾸냐에 따라서 동작하게 됩니다.
• 보통 각 ReaderThread가 while문을 반복하고 있다가, Main Thread에서 ready를 ture로 바꾸면 while 루프를 탈출할 것이라 생각합니다.
• 안타깝게고 이 코드는 루프를 탈출하지 못하는 Thread도 있고, 탈출하더라도 number의 값을 0으로 출력하는 Thread도 있을 것입니다.
• number와 ready같은 데이터터 스테일 데이터(Stale Data)라고 위와 같은 현상을 스테일 현상 이라고도 합니다.
• 스테일 현상은 Multi Core Processor(혹은 다중 CPU)의 구조로부터 시작됩니다..

Multi Core Processor와 Visibility

• 위 그림에서보면 각 core는 1개 이상의 cache level을 가지고 있습니다.
• 각 core는 연산을 위해 매번 Main Memory에 직접 접근하지 않고 cache에 저장하여 사용할 것입니다.
• 그러면 각 core를 사용하는 Thread cache에 있는 데이터를 통해서 연산을 할 것입니다.
• 그러면 실제로 Main Memory에 있는 데이터와 각 Thread가 사용하는 데이터가 달라지게 됩니다.
• 이를 가시성 문제라고 합니다. 🤢 🤢 🤢
• 위의 코드를 다시 살펴보면 각 ReaderThread와 Main Thread가 다른 core에서 연산될 수도 있을 것입니다.
• 이때 동기화가 이뤄지지 않는다면, Main Thread가 number나 ready의 값을 바꾸더라도, 각 ReaderTrehad의 연산을 수행하는 core는 자신의 cache에 있는 값을 보게 될 것입니다.
• 그러면 상황에 따라서 무한 루프에 빠질수도 있고 number에 입력한 값이 0으로 나올 수도 있을 것입니다.

정리

Instance Variable

• JVM Runtime Data Area의 Heap에 생성된 Instance는 모든 Thread에서 접근이 가능한 공유 자원원입니다.
• Instance가 메소드만 지니고 있다면 그 메소드 내부는 각 Thread만 사용하는 Stack영역이니 문제가 없을 테지만, 상태를(Instance Variable)을 가지게 되면 이 상태에는 모든 Thread가 접근할 수 있습니다.
• 동기화 되지 않는 객체의 상태에 여러 Thread가 접근하면 경쟁조건(race condition)을 가지게 됩니다.
• 이때 해당 자원을 통한 연산이 원자성을 띄지 않는다면 일관적인 연산의 기대값을 얻을 수 없습니다.

Class Variable

• VM Runtime Data Area의 Method Area에 할당된 Class Variable은 모든 Thread에서 접근 가능한 공유 자원입니다.
• 만약 동기화가 되지 않은 상태에서 해당 자원에 여러 Thread가 접근하게 된다면 Instance Variable에서 일어났던 동시성 이슈를 겪게 됩니다.
• Class Variable이나 Instance Variable에서 나타났던 동시성 이슈는 Synchronized 키워드나 Lock을 사용한 동기화를 통해 Thread Safety를 보장할 수 있습니다.
• 또한 상태를 가지지 않는 함수형 프로그래밍을 사용하는 것도 방법이 될 것입니다.
• Synchronization에 대해서는 다른 아티클을 통해 살펴보겠습니다.

Visibility

• Multi Core Processor, Multi Threading 환경에서는 각 core는 자신의 cache에 Main Memory에서 읽은 데이터를 저장합니다.
• 각 Thread에서 변경한 값이 Main Memory에 즉시 반영되는 것이 아니기 때문에 스테일(stale)현상이 발생합니다.
• 즉, 각 core에서는 다른 core의 cache에 어떤 값이 있는지 알 수 없는 상태가 됩니다.
• volatile 키워드를 변수에 붙여주면 각 core의 연산결과를 main memory에 flush 하므로 해당 문제를 해결 할 수 있습니다.(volatile 키워드에 대한 내용은 다른 아티클에서 자세히 다룰 예정입니다)
• 다만 이때 원자성이 지켜지지 않는 경우 race condition을 가지게 되어 연산 결과를 예측할 수 없게 됩니다.

👉 참조
멀티코어를 100% 활용하는 자바 병렬프로그래밍
Java Performance Fundamental
Guide to the Volatile Keyword in Java