Project Loom 새로운 패러다임일까?

recordsbeat·2020년 11월 5일

Java

1. What is Project Loom ?

기존 Java 스레드 처리방식의 비효율성을 탈피하고자 나온 JDK

countinuation 과 scheduler를 사용한 fiber 경량 스레드를 제공.

가장최근에는 virtual thread의 제공하여 기존에 쓰던 thread 와 크게 다르지 않게 사용하나

내부적으로는 경량스레드의 장점을 취할수 있다.

2. 등장배경

2.1 중량스레드의 단점

웹 어플리케이션들은 요청당 1개의 스레드를 배정하여 처리.

블로킹 처리방식으로 요청이 완료될 때 까지 스레드는 재할당이 불가하다.

자바가 사용하는 스레드는 OS 로부터 할당받은 커널레벨의 스레드다.

OS 레벨의 스레드는 무겁기 때문에 스레드 풀을 만들어 사용하는 방식을 택해왔다. → 퍼포먼스의 한계가 분명하다.

또한 커널이 스케줄링을 담당하기 때문에 예측이 불가하며 값비싼 문맥교환이 일어난다.

(기존 자바는 OS 독립적인 프로그래밍을 위하여 스레드 스케줄링은 concurrent 패키지등에 위임하는 것을 권장했다.)

http://guruma.github.io/posts/2018-09-27-Project-Loom-Fiber-And-Continuation/

이미 나와있는 비동기 개발방식 중 Reactive 프로그래밍(Spring WebFlux와 같은)을 통해 이의를 제기할 수 있지만

Project Loom 은 이에 대해서도 문제점을 시사한다.

https://gunsdevlog.blogspot.com/2020/09/reactive-streams-reactor-webflux.html

(비동기 프로그래밍에 대하여..)

2.2 비동기 프로그래밍의 문제점

2.2.1 제어흐름의 상실

위와 같이 연산에 조건, 반복이 필요한 경우 비동기 프로그래밍에서는 필요이상의 복잡한 구현이 필요하다.

2.2.2 스택트레이싱의 불편함(문맥 상실)

스레드를 넘나드는 문맥, I/O 처리에 할당된 스레드가 전무하므로 컨텍스트가 유지되지 않는다.

exception 을 핸들링하는 블록이 전혀 다른 스레드에서 동작될 수 있다.

(exception을 제외한 각 구문들도 전혀 다른 스레드에서 동작할 가능성이 농후하다.)

2.2.3 전염성

return 타입이 future 등으로 정의되어 있을 경우 비동기처리와 관련된 메소드들은 모두 같은 형태의 타입을 취해야한다.

과도한 래퍼로 인해 Actor의 모호함 . 비지니스 가독을 해친다

3. 어떻게 문제를 해결할까?

근본적인 문제는 스레드가 무겁다는 것이다.

OS에서 제공하는 스레드는 Java주체적으로 컨트롤하기 매우 어려우며

값 비싼 자원소모가 일어나기 때문에 사용에 제한이 생긴다.

→ 스레드를 가볍게. 원하는 만큼 쓸 수 있게 만들자!

스레드는 두 가지 기능을 합친 것이다

제어의 양도와 복귀 , 실행 스케줄링

Proejct Loom는 위의 두가지 스레드 요소를 continuation과 scheduler로 정의하여

fiber(경량스레드) 구현하였다.

Continuations

스레드와 비슷한 형태를 띈다.

위는 단순 싱글 프로세싱을 지원하는 구조로 run을 하다 yield를 통해 cpu 점유를 해제한다.

위를 복제가능한 형태로 하면 어떤 이점이 생길까?

복제를 하는 순간 작업의 위치를 캡처할 수 있다. 즉 Resume 할 때에 코드가 진행되었던 곳으로 다시 복귀 가능하다는 이야기다.

이를 활용한 MultiShotContinuation은 run()을 할 때 this의 Continuation 복제본을 리턴한다.

블로킹 구간에서는..?

concurrent 패키지에 구현되어있는 LockSupport 클래스는

블로킹이 일어나는 구간에서 실제 블로킹이 아닌 park를 하여 cpu 점유를 해제한다.

I/O 작업이 반환되면 스케줄러를 통해 작업의 복귀 시점부터 다시 cpu를 점유하는 unpark을 호출한다.

*Project Loom 초기에 Thread와 Fiber가 Strand(실가닥)의 자식 타입이 될 것인지 아니면
Thread 타입에 통합할 것인지에 대해 다양한 논의가 있었는데 현재 버전에서는 Thread에 통합(VirtualThread) 되었으며 이를 통하여 기존 코드를 거의 변경하지 않고 Fiber의 장점을 취할 수 있게 되었다.
이 추상화에 대해 RPC 추상화 문제와 동일한 실수를 반복할 수 있다는 반대 의견들도 있었으나 결국 Thread에 통합하는 걸로 결정 되었고 가장 Java 다운 결정이라고 생각된다.
또한 개인적으로 이 추상화가 RPC 문제만큼 심각한 문제를 야기할 것이라고 생각 되지도 않는다.
http://gunsdevlog.blogspot.com/2020/09/java-project-loom-reactive-streams.html