🔥 TIL - Day 77 동시성 이슈 해결 - ThreadLocal

서비스가 흥행하여 사용자가 많아지는 경우 동일한 인스턴스의 동일한 필드에 서로 다른 쓰레드가 동시에 접근하는 빈도가 높아질 수 있다. 이렇게 동시에 접근됐을 때 발생하는 이슈를 동시성 이슈라 한다.

동시성 이슈가 발생하는 시나리오를 간단하게 그려보자.

• 쓰레드 A가 X인스턴스으 어떤 메서드에 접근해서 X인스턴스의 필드를 수정하고 수정 결과를 리턴한다.
• 쓰레드 A가 필드를 수정하는 동시에 쓰레드 B가 동일한 메서드를 호출한다.
• 쓰레드 A는 X인스턴스의 필드를 수정하고 쓰레드 B도 동일한 필드를 수정한다. 결과적으로 쓰레드 A와 B 모두 B가 수정한 결과를 리턴하게 된다.
• A의 수정결과를 B가 덮어쓴 것.

Spring에서 동시성 이슈를 더 신경써줘야 할 이유가 있다.
Spring은 Bean을 등록하고 주입받아 사용하는 것이 매우 일반적인데 보통의 경우 Bean은 Singleton으로 관리되기 때문에 동일한 인스턴스에 접근되는 경우가 많다.

---

📌 동시성 이슈 발생 코드

전달된 파라미터를 store 필드에 저장하고 저장된 결과를 반환하는 메서드이다.
저장하는데 1초가 소요된다고 가정하고, 1초 사이에 다른 쓰레드가 동일한 메서드를 호출하게 해서 동시성 이슈를 확인한다.

@Slf4j
public class FieldService {
    private String store;

    public String logic(String name) {
        log.info("저장 name={} -> store={}", name, store);
        this.store = name;
        sleep(1000); // 저장하는데 1초가 경과한다고 가정 (1초를 sleep 하는 동안 다른 쓰레드를 끼워넣어서 동시성 이슈가 발생하는지 확인하기 위함)

        log.info("조회 store={}", store);
        return store;
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

동시성 이슈 발생 테스트

@Slf4j
public class FieldServiceTest {

    private FieldService fieldService = new FieldService();

    @Test
    void field() {
        log.info("start");

        Runnable userA = () -> fieldService.logic("userA");
        Runnable userB = () -> fieldService.logic("userB");

        Thread threadA = new Thread(userA); 
        threadA.setName("Thread-A");
        Thread threadB = new Thread(userB);
        threadB.setName("Thread-B");

        threadA.start();
        sleep(100); // 1000ms가 되기 전에 B쓰레드를 시작시켜서 경합상태를 만든다.
        threadB.start();

        sleep(3000);
        log.info("exit");
    }

    private void sleep(int millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

조회결과 두 쓰레드 모두 userB를 리턴하고 있다.
A쓰레드가 변경한 필드를 B쓰레드가 덮어쓰고 두 쓰레드 모두 덮어쓴 결과를 읽었기 때문이다.

---

📌 ThreadLocal 을 이용한 동시성 이슈 해결

ThreadLocal은 쓰레드마다 고유한 Map 형태 저장소로 생각하면 된다.
인스턴스의 필드가 ThreadLocal 타입이라면 쓰레드마다 독립적으로 데이터가 관리되는 것이다.

@Slf4j
public class ThreadLocalFieldService {
    private ThreadLocal<String> nameStore = new ThreadLocal<>();

    public String logic(String name) {
        log.info("저장 name={} -> nameStore={}", name, nameStore.get());
        nameStore.set(name);
        sleep(1000);
        log.info("조회 nameStroe={}", nameStore.get());
        return nameStore.get();
    }
}

사용법은 생각보다 간단하다.
동시성 이슈가 우려되는 필드를 ThreadLocal로 선언하고 get, set 메서드를 통해 데이터를 조회하고 저장한다.

ThreadLocal을 적용한 테스트 결괴이다.
ThreadLocal을 사용하지 않았을 경우 쓰레드B가 필드에 접근했을 때 이미 쓰레드A에서 세팅한 값이 존재했었는데 ThreadLocal을 적용하니 쓰레드A가 필드에 값을 세팅한 후 쓰레드B가 필드에 접근했을 때 null인 것을 확인할 수 있다. 서로 다른 저장소를 사용한다는 것이다.

조회결과 또한 의도한 대로 각 쓰레드에서 저장한 결과가 조회되었다.

---

📌 ThreadLocal 사용시 주의사항

ThreadLocal 타입으로 선언한 필드를 제거할 때 반드시 remove를 해줘야 한다.

필드를 제거할 때 해당 필드에 null을 넣어주는 방식이 아니고 ThreadLocal의 remove 메서드로 필드를 제거해줘야 한다.

클라이언트는 쓰레드 풀에서 쓰레드를 할당받아 사용한다.
중요한 것은 작업이 완료되면 쓰레드를 다시 쓰레드 풀에 반납한다는 것이다. 해당 쓰레드듣 제거하고 사용할 때 다시 생성하는 방식이 아니다. (쓰레드 생성 비용이 비싸기 때문...)

동일한 쓰레드가 다시 사용되다는 것인데 이전에 사용한 쓰레드의 ThreadLocal에 데이터가 남아있다면..?

조회시 의도한 결과가 아닌 이전 클라이언트의 데이터가 조회될 수 있다.

요청에 대한 작업이 끝나면 필터나 인터셉터를 통하든 다른 방법이든 반드시 ThreadLocal의 remove를 통해 ThreadLocal저장소를 해제해줘야 한다.

ThreadLocal<Item> item = new ThreadLocal<>();

.... 작업 ....

item.remove();

---

📌 참고

인프런 - 스프링 핵심 원리 고급편 (김영한 님)