ThreadLocal

Java ThreadLocal은 Java 1.2부터 도입되었다. Key, Value로 구성되어 있음

• Key : Current Thread

• Value : Any Object

ThreadLocal은 각 스레드마다 독립적인 값을 저장할 수 있게 해주는 클래스이다. 다시 말해, 동일한 ThreadLocal 객체를 여러 스레드가 공유하더라도 각 스레드는 자신만의 고유한 값을 가질 수 있다.

스레드 로컬은 스프링과 같은 프레임워크에서 많이 사용된다. 메소드의 매개변수로 전달하지 않고도 값에 access가 가능하다. 아래와 같이 여러 Service를 거치는 요청이 있다.

1. 가장 먼저 요청이 들어오면 사용자 인증을 시도한다.

   • 토큰이 생성될 수 있고, 현재 스레드는 스레드 로컬에 토큰과 사용자 권한을 저장할 수 있다.

2. 마지막 서비스 계층까지 왔다. 메소드가 실행되기 전에 권한을 확인한다.

   • 모든 서비스에 사용자 권한을 매개변수를 통해 전달할 필요는 없다.

     • 스레드는 스레드 로컬에 access하여 권한을 물어볼 수 있다.

   • 이것이 가장 일반적인 사례 중 하나이다.

멀티코어 프로세서 시스템에서 Synchronized를 사용하면 스레드가 Lock을 얻기 위해 대기해야 한다.

이는 성능에 영향을 줄 수 있다.

따라서 이 문제를 해결하기 위해서는 “스레드 로컬”을 사용할 수 있다.

• 각각의 스레드는 객체를 생성하여 스레드 로컬에 넣을 수 있다.

• 동기화 및 스레드 안전성에 대해 걱정할 필요가 없다.

하지만 스레드 로컬에도 몇 가지 결함이 존재한다.

• 변경이 가능하다.

• GC에 의해 수거되지 않기 때문에 계속 메모리에 남을 수 있다.

  • 수동으로 제거해야 함.

  • 이를 제거하려면 스레드 자체가 죽거나 API를 설계해야 한다.

  • 이것은 메모리 누수로 이어질 수 있다.

• 스레드 로컬은 정적 파일과 함께 사용되어야 한다. (static final)

ThreadLocal<String> token = new ThreadLocal<>();
// key는 현재 스레드가 되고
// value는 String type이 된다.

// method
1. set
2. get
   - 값이 없으면 null을 반환
3. remove

• remove를 하는것을 잊으면 안된다.

  • 요청이 처리되면 꼭 제거 해야한다. → 이것이 스레드 로컬의 하나의 문제

스레드 로컬의 주요 특징에는 스레드가 종료되면 해당 스레드 로컬의 값도 자동으로 정리되는데, 그렇다면 remove 할 필요가 없는것이 아닌가?

스레드 객체가 더 이상 참조되지 않으면 ThreadLocal 값도 GC의 대상이 된다고 한다.

여기서 주의해여 할 점은 스레드 풀을 사용하는 경우인데, 스레드 풀에서는 스레드가 완전히 종료되지 않고 재사용되기 때문에 ThreadLocal 값이 그대로 남아있을 수 있기 때문에 이러한 환경이라면 remove()의 사용이 권장된다.

키 조회 메커니즘

ThreadLocal<String> threadLocal = new ThreadLocal<>();

// 스레드 1
new Thread(() -> {
    threadLocal.set("스레드 1의 데이터");
    // 이 시점에 스레드 1의 ThreadLocalMap에 
    // (threadLocal 객체, "스레드 1의 데이터") 저장
}).start();

// 스레드 2
new Thread(() -> {
    threadLocal.set("스레드 2의 데이터");
    // 이 시점에 스레드 2의 ThreadLocalMap에 
    // (threadLocal 객체, "스레드 2의 데이터") 저장
}).start();


ThreadLocalMap:
- key: ThreadLocal 객체
- value: "스레드 1의 데이터"
- key: ThreadLocal 객체
- value: "스레드 2의 데이터"

실제로 같은 ThreadLocal의 객체를 사용하지만, 각 스레드의 고유한 맵에 저장된다.

따라서 get()을 호출하면 현재 실행 중인 스레드의 맵에서 값을 찾는다.

스레드 로컬 상속

1. 스레드 로컬은 상속될 수 없다.

ThreadLocal<String> token = new ThreadLocal<>();
token.set(newToken);

public void call() {
	Thread.ofPlatform().start(() -> anyMethod());
}

public void andMethod() {
	Systme.out.println(token.get());
}

// 상속이 가능하게 하고싶으면 IngeritableThreadLocal<>()으로 선언
ThreadLocal<String> token = IngeritableThreadLocal<>();

call 이 시작될 때 새로운 스레드를 생성해서 메소드를 호출하는데, token 값을 확인해보면 null이 들어가있다.

• 하위 스레드가 상위 스레드 값에 access 할 수 없다.

만약 접근하고 싶다면 IngeritableThreadLocal<>()로 생성한다.

1. 하위 스레드가 다른 값을 설정하면? 상위 스레드가 영향을 받을까?

ThreadLocal<String> token = InheritableThreadLocal<>();
token.set(newToken);

public void call() {
	Thread.ofPlatform().start(() -> anyMethod());
}

public void andMethod() {
	Systme.out.println(token.get());
}

상위 스레드는 영향을 받지 않는다. 새로 복사하기 떄문이다.

• 하위 스레드에서 무언가를 수정하거나 제거하면 바뀌긴 하지만 하위 스레드에서만 영향을 준다.

하나의 가상 스레드는 또 다른 가상 스레드를 무수히 생성할 수 있다.

이 과정에서 ThreadLocal의 모든 복제, 참조 복제, 하위 스레드와의 공유를 계속 수행한다면 문제가 발생한다.

Scoped Value

ScopedValue<String> token = ScopedValue.newInstance();

token.isBound() // 값이 있는지 확인 -> true/false

• comiler-plugin:21:—enable-preview를 활성화 해야한다.

• 프로덕션 환경에서 사용하면 안됨

스레드 로컬에서는 값이 없는데 get()을 하면 null을 반환한다.

하지만 여기서는 NoSuchElementException이 발생한다. 따라서 값이 먼저 있는지 확인해야 한다.

• 값이 없더라도 orElseThrow를 사용하지 마라.