[스터디] 자바 ScopedValue에 대해서

ScopedValue 와! 이거 좋구나!! 스터디 잘해서, ThreadLocal의 찝찝함을 없애야겠다..

 

자바 26릴리즈 노트를 최근에 봤는데, 쭉 내용을 보던중에 눈에 띄는게 있었다. 그게 ScopedValue와 StructuredTaskScope였다.

 

우선 ScopedValue가 가장 맘에 들었다 ㅋ

ThreadLocal를 대체할수있는 개념이였기에 큰 흥미가 생겼다.

평상시, 나도 ThreadLocal의 사용성이나 사용법이 개발자의 실수를 만들어내기에 쉬운 구조라고 생각을 자주했기 때문이다.

(ThreadLocal사용할때, 아..쓰기싫다 이러면서 쓴적도 많긴하다 ㅋㅋ)

 

음,, 뭐가 맘에 들지않았냐하면 ..ㅋ

 

1) ThreadLocal의 실행 라이프사이클이 Thread를 따른다는것이다.

- Thread의 라이프사이클은 사실 런타임에서 돌아가는 개념이기에,

ThreadLocal이 Thread의 라이프사이클과 동일하다는 개념은 코드상으로는 개발자가 쉽게 판단/유추하기가 매우 어렵다.

특히 스레드풀을 사용하는 로직에서는 더더욱 어렵다.

해당 코드블록이 어떤 스레드에서 동작하는것인지를 매번 머리속에서 상상하고, 쓰레드가 섞이거나 하는 경우를

매번 주의해야하기때문이다.

 

- Thread의 라이프사이클은 명시적으로 코드로 확인가능한 코드블록이여야 한다고 생각했는데,

(마치 Try-catch-finally처럼 명시적 코드 블록) 이게 이번에 ScopedValue이 그 개념과 같았다.

얼마나 기뻤는지...(나랑 같은 생각을 했구나, 자바SDK 개발자분들 ㅠㅠ 같은 생각을 하는 동지를 만나면 기쁘지않은가!)

 

2) ThreadLocal에서 명시적으로 Remove호출하는 부분이다.

- 이것또한 위 1번내용과 비슷한데, Thread의 라이프사이클을 주의깊게 사용해야함과 동시에,

ThreadLocal의 주기의종료 또한 개발자가 직접 관리를 해야하는 것이다.

개발자가 코드로 관리한다는 부분은 좋은 방법이라고 생각하지만,

그 호출시점이 Thread의 런타임의 상태(어떤 Thread를 사용하는지의 판단)에 따라,

개발자가 직적 remove 호출을 해야하는 부분은 너무 많은 실수를 양산할수있는 위험한 방법이라고 생각했다.

 

- 이부분이 이제 ScopedValue를 통해 라이프사이클이 해당 코드블록에서 생성되고, 소멸되는 방법으로 제공하기에,

명시적으로 Remove를 할필요가 없어졌다!! (마치 코드블록에서 로컬변수를 사용하는것처럼)

 

 

 

가장 맘에 드는것이 ScopedValue개념이 Thread의 라이프사이클과 이제는 영영 안녕했다는것이다.

Thread의 라이프사이클과 주기를 같이하는 기존 ThreadLocal은 ThreadPool을 사용하는 구조에서는 그사용이 정말 헬이라고 생각하기때문이다. Thread풀처럼 Thread를 얻어서 다른 로직을 수행하고 반납하고를 반복하는 구조에서는 자칫 잘못하면, 엉뚱한 ThreadLocal로컬값을 사용할수있기때문에, 정말 위험한 개념이긴하다.

 

이게 아마..다음 커뮤니케이션에 일할때, 메일에 다른 사람메일이 막 뒤죽박죽 보였던 큰 사건이 있었는데...

(그당시 해당 회사에 다니고있었는데.. 말그대로 회사가 기자들로 쑥대밭이였다...)

그때 기억에 원인이  ThreadLocal + ThreadPool조합에서 해당 ThreadLocal에 개인정보를 저장해서 사용하면서, ThreadPool에 Thread반환시 Remove로 해당 데이터를 명시적으로 삭제를 하지않고 반환하여, 다른 사용자가 해당 Thread를 획득해서 사용시, 삭제되지 않은 다른 유저의 데이터를 사용하게 됨에 따라 문제가 발생했던것으로 기억을 한다... 어마무시하지않나..ㅠㅠㅠㅠㅠ 무섭다..

 

앞으로 개발할때,

ThreadLocal을 사용해야하는 경우가 발생한다면, ScopedValue을 이용하도록 해야겠다.