Ray`s Tech Lab

https://youtu.be/pt7cNy7KlpE?si=OUiwPpv_nywXW7ko

들어가며

최근 사내에서 Virtual Thread에 대한 기술 세미나를 열었는데요. 사내 세미나 한 번으로 해당 내용을 묵혀두기는 아까워서 유튜브 영상으로도 공유하고.. 블로그에도 남겨볼려고 합니다. 다만 사내 세미나와 영상에서는 비IT 직무 인원들도 이해할 수 있게끔 최대한 비유를 들며 쉽게 설명하려고 했던 것과 다르게 블로그에는 최대한 기술적으로(?) 작성해보고자 합니다. 

Virtual Thread는 JDK21버전부터 공식 Feature로 포함된 기술로, 블록체인이나 AI같이 산업의 변화를 이끌고 있는 기술보다는 성능 최적화를 위해 쓰이는 뒷단의 기술에 가깝습니다. Java를 기반으로 하는 플랫폼이 기존에 어떤 컨셉의 모델을 사용해왔고, 이게 어떤 한계가 있었고, 이를 바탕으로 Virtual Thread가 어떤 목적으로 나온 기술인지 이번 포스트에서 살펴보겠습니다. 그리고 Virtual Thread의 Context Switching, Throughput에 대한 테스트 내용과 사용 시 주의사항에 대해 소개하겠습니다.

목차는 다음과 같습니다.

1. Thread per Request & Thread Pool (Java가 전통적으로 사용해 온 방식)
2. Reactive Programming의 등장 및 한계
3. Virtua Thread의 개념과 장점
4. Virtual Thread의 동작 방식 및 원리
5. Virtual Thread 테스트 - Context Switching
6. Virtual Thread 테스트 - Throughput
7. Virtual Thread 주의사항 - Pinning
8. 정리

1. Thread per Request & Thread Pool

Spring으로 대표되는 Java 기반 플랫폼은 사용자로부터 하나의 Request가 들어오면 하나의 스레드로 이를 처리하는 Thread per Request라는 방식을 옛날부터 사용해왔습니다. 그러나 매 Request마다 새로운 스레드를 생성하는 것은 비용 부담이 크기 때문에, 미리 일정량의 스레드를 만들어두고 Request가 들어올 때마다 만들어둔 스레드에게 해당 Request의 처리를 맡기는 Thread Pool이란 개념을 사용해왔습니다.

그러나 시간이 흐르며 서비스의 규모가 커지고 Request의 양이 늘어남에 따라, 서비스의 처리량을 늘려야 하는 미션이 생기게 됩니다. 가장 심플한 방법은 스레드풀의 사이즈, 즉 스레드의 개수를 늘리는 것이지만 공간적인 한계 때문에 스레드의 개수가 제한될 수밖에 없었고, 이는 서비스의 처리량이 일정 수준으로 한정되는 결과로 이어졌습니다. 그리고 Java는 자바 스레드(유저 스레드)와 커널 스레드가 1 : 1로 매핑되는 스레딩 모델을 사용하기 때문에, 스레드 간 전환은 곧 커널 스레드간의 전환을 의미하고 이는 Context Switching 비용 부담이 점점 부각되는 문제점을 보이게 됐습니다. 또한 자바 스레드가 I/O 작업 등으로 인해 Blocking되면 매핑된 커널 스레드까지 함께 Blocking됐기 때문에, 만들어둔 스레드들이 실질적으로 task를 수행하는 시간보다 대기하는 시간 즉 idle time이 훨씬 더 많아지는 문제점도 부각되기 시작했습니다.

이런 상황에서 어쨌거나 처리량을 올려야 했고, 가장 단순한 방법인 "스레드 늘리기"는 공간적 제약으로 할 수 없는 상황입니다. 전통적으로 사용해 온 Thread per Request는 하나의 스레드가 하나의 요청을 처리하는 방식인데, "하나의 스레드가 두 개 이상의 요청을 동시에 처리하게 한다면 처리량이 올라가지 않는가?"라는 아이디어가 나오게 됩니다.

※ 이 때의 "동시"는 시간적으로 동시에 한다는 개념이 아니라, 스레드가 대기할 동안 다른 일을 시킨다는 개념입니다.

이 아이디어를 바탕으로 Reactive Programming이 등장하게 됩니다.

2. Reactive Programming의 등장 및 한계

"하나의 스레드가 동시에 두 개 이상의 Request를 처리하게 한다"라는 생각을 바탕으로 등장한 비동기 + Non-Blocking 방식의 프로그래밍 패러다임입니다.

컴퓨터 자원을 좀 더 효율적으로 사용할 수 있었기 때문에, Reactive Programming을 통해 더 적은 스레드로 더 많은 Request를 처리할 수 있었습니다. 즉 주어진 미션대로 처리량을 높일 수 있었습니다.

그러나.. Reactive Programming은 다음과 같은 단점들이 있었습니다.

1. 높은 진입장벽

"하나의 스레드가 동시에 두 개 이상의 Request를 처리하게 한다"라는 것은 기존의 동기적인 관점에서 벗어나 비동기라는 관점에서 프로그래밍을 해야 했습니다. 그렇다보니 러닝커브가 높아지게 됐고, 이는 기존에 사용하던 동기적인 방식의 코드와 로직을 전환하는 것에도 부담이 되는 요소로 작용하게 됐습니다. 여러 로직이 맞물릴 때, 하나만 비동기로 바꾸면 되는 게 아니라 전체를 비동기로 바꿔야 하기 때문인 것도 있습니다.

2. 직관적인 코드 이해의 어려움

기존의 동기적인 관점에서 코드를 작성할 땐, 주어진 비즈니스 요구사항 즉 비즈니스 프로세스가 이 코드에 잘 반영됐는지 파악하는 것이 상대적으로 쉬웠습니다. 또한 새로운 기능을 추가해야 할 때, 기존 코드의 어느 부분에 추가해야 할지 판단하는 것도 어렵지 않았습니다. 하지만 Reactive Programming에서는 우리의 비즈니스 프로세스가 이 코드에 잘 반영됐는지, 새로운 기능을 추가한다면 어느 부분에 추가해야 하는지를 판단하는 것이 상대적으로 어려웠습니다. 1번과 이어지는 얘기지만, 결국 Reactive Programming은 프로그래밍 패러다임, 즉 프로그래밍을 하는 관점 자체를 달리 하는 것이 원인인 것이죠.

3. 어려워진 디버깅, 예외처리

기존에는 Thread per Request, 하나의 스레드가 하나의 Request을 처리하는 컨셉이었기 때문에, 문제가 발생하면 콜스택 등을 통해 디버깅하거나 예외처리를 해주는 것이 상대적으로 쉬웠습니다. 그러나 Reactive Programming은 Request(다른 말로는 task)를 여러 스텝으로 쪼개고 각 스텝들을 파이프라인(다른 말로는 스트림) 형태로 엮어서 여러 스레드에서 처리하게 됩니다. 그렇다보니 콜스택을 통해 디버깅하거나 예외처리하는 것이 상대적으로 어려워지게 됐습니다.

정리하면, Reactive Programming을 통해 분명 처리량을 높일 수 있었습니다. 하지만 그에 반비례해서 개발 생산성이 떨어진다는 리스크가 있었죠. "Reactive Programming 이거 분명 잘 쓰면 좋아. 근데 잘 쓰기가 너무 어려워!"라는 문제점이 점점 부각되기 시작했습니다.

그래서 다시 Thread per Request & Thread Pool 이라는 원점으로 돌아옵니다. 주어진 미션은 여전히 "처리량을 높이는 것"입니다. 하지만 여기에 한 스푼 더 얹어서 "기존의 동기적인 코드 흐름을 유지할 순 없을까?" 라는 욕심이 들기 시작합니다. 이를 충족시키는 가장 간단한 방법은 역시나 "스레드 개수 늘리기"이지만, 공간적인 제약 때문에 그렇게 할 수 없었죠. (스레드는 메모리에서 2MB정도까지 공간을 차지할 수 있다고 합니다) 근데 여기서, "그러면 스레드를 가볍게 만들면 엄청 많이 만들 수 있는 거 아냐?" 라는 관점이 나오기 시작합니다.

이 아이디어를 바탕으로, 스레드를 가볍게, "경량"으로 만들어서

1. 서비스의 처리량 향상
2. 기존의 동기적인 코드 흐름 유지

라는 2개의 목표를 달성하기 위해 본 포스트의 메인 주제인 Virtual Thread가 등장하게 됩니다.

3. Virtual Thread의 개념과 장점

앞서 말씀드렸듯이 Java가 사용하는 스레딩 모델은 자바 스레드와 커널 스레드의 1 : 1로 매핑 모델입니다. CPU의 실질적인 스케쥴링 대상은 커널 스레드로, 커널 스레드가 CPU를 점유하면 그에 매핑된 자바 스레드가 수행되는 구조로 이해할 수 있습니다. Virtual Thread는 기존의 자바 스레드보다 더 가벼운 스레드를 만들어 하나의 자바 스레드에 다수의 Virtual Thread가 매핑시키는 구조로,  커널 스레드가 CPU를 점유하면 매핑된 자바 스레드에 mount된 Virtual Thread가 실행되는 개념입니다.

동작 과정도 간단히 살펴보면, 기존에는 자바 스레드가 Blocking되면 매핑된 커널 스레드까지 Blocking되는 구조였습니다. 그러나 Virtual Thread는 실행 중 Blocking된다면 mount되어 있던 자바 스레드에서 unmount되고, 다른 Virtual Thread가 자바 스레드에 mount되어 실행되는 구조입니다. 따라서 실질적으로 CPU를 점유하고 있는 커널 스레드는 Blocking되지 않게 됩니다.

이러한 특징 덕분에, Virtual Thread 사용 시 기존에 사용하던 동기적인 코드 흐름을 그대로 유지할 수 있으면서도, 내부적으론 비동기 방식과 비슷하게 동작하게 되어 Non-Blocking 처리가 가능해져 처리량을 높일 수 있게 됩니다. 또한 기존 스레드 간의 Context Switching은 커널 레벨에서 발생하지만 Virtual Thread간의 Context Switching은 유저 레벨에서 발생한다는 특징이 있는데요, 이를 통해 Context Switching 비용을 좀 더 아낄 수 있게 된다는 장점도 있습니다. 

구체적인 동작 방식을 통해 좀 더 살펴보겠습니다.

4. Virtual Thread의 동작 방식 및 원리

0. Virtual Thread 주요 구성 요소

동작 방식 설명 전 Virtual Thread의 주요 구성 요소들을 살펴보면 다음과 같습니다.

1) ForkJoinPool

Virtual Thread들의 static 멤버(즉 모든 Virtual Thread가 공유)로, Virtual Thread들을 스케쥴링하는 스케쥴러 역할을 합니다.

2) Carrier Thread

Virtual Thread이 mount되어 실행되는 실질적인 자바 스레드이며,  Carrier Thread들은 저마다 하나씩 WorkQueue라 불리는 work-stealing 방식으로 동작하는 큐를 가집니다. 논리적인 관점에서 Carrier Thread는 Virtual Thread와 1 : N의 매핑 관계를 가지며, Carrier Thread와 커널 스레드는 1 : 1의 매핑 관계를 가집니다.

※ work-stealing : Carrier Thread들이 자신의 workQueue에 아무 것도 없으면 다른 Carrier Thread의 workQueue에 있는 걸 훔쳐와서 사용하는데, 이를 work-stealing이라고 표현합니다.

3) Continuation

Virtual Thread가 실행해야 하는 작업과 그 작업에 대한 정보(어디까지 실행했는지 등)을 가지는 객체입니다.

4) runContinuation

Continuation을 실질적으로 실행시키는 일종의 람다식입니다.

1. 동작 방식 - Virtual Thread가 Carrier Thread에 mount되는 과정

기존 자바 스레드는 start 메서드를 호출하면 start0라는 native 메서드를 거쳐 JNI를 통해 해당 자바 스레드와 매핑될 새로운 커널 스레드를 생성하게 됩니다. 반면 Virtual Thread는 start메서드 호출 시 submitRunContinuation 메서드가 호출되고, 스케쥴러(ForkJoinPool)의 execute 메서드가 호출됩니다. 그러면 스케쥴러가 적당한 Carrier Thread를 하나 골라 runContinuation을 해당 Carrier Thread의 WorkQueue에 넣어주게 됩니다. 이후 Carrier Thread가 본인의 WorkrQueue에 들어있는 runContiation을 뽑아 실행시키면 Virtual Thread와 Carrier Thread가 mount되고 Virtual Thread가 실행됩니다.

2. 동작 방식 - Virtual Thread가 실행 중 Blocking될 때 unmount되는 과정

Virtual Thread가 실행되다가 I/O 요청 등으로 인해 Blocking되면 내부적으로 park메서드가 호출됩니다. park메서드는 doYield라는 native 메서드를 거쳐 JNI를 통해 jvm단에서 memcpy라는 표준 C 라이브러리 함수를 호출하게 됩니다. Virtual Thread가 사용 중이던 스택 프레임을 Heap에다가 복사해두는 기능을 수행하는 것이며, 이를 통해 나중에 Blocking이 끝나고 Virtual Thread가 재개될 때 중단 지점부터 재개하는 것이 가능해집니다. 참고로 CPU에서 사용되던 PC 레지스터 값 등도 함께 Heap에 복사되는 과정도 코드를 분석해보면 보실 수 있습니다. (저는 GitHub에 있는 openjdk를 뜯어봤습니다)

이런 과정을 거치며 unmount가 진행되고, Carrier Thread는 다른 Virtual Thread와 mount되게 됩니다.

3. 동작 방식 - Blocking됐던 Virtual Thread가 다시 재개되는 과정

Blocking상태가 끝나면 내부적으로 unpark() 메서드가 호출되며, 다시 submitRunContinuation이 호출되면서 Carrier Thread의 WorkQueue에 runContinuation필드가 들어갑니다. 이후 Carrier Thread가 이를 뽑아내서 mount할 때 아까 Heap에 복사해뒀던 스택 프레임을 다시 복구시켜서 중단 지점부터 작업을 재개합니다.

4. Virtual Thread 동작 방식 최종 정리

1. Virtual Thread는 Carrier Thread의 WorkQueue에서 work-strealing 방식으로 mount되어 실행됩니다.
2. mount된 Virtual Thread는 실행이 끝나면 다른 Virtual Thread로 갈아끼워집니다. (Context Switching)
3. mount된 Virtual Thread는 실행 중 Blocking되면 현재까지의 실행 정보(스택 프레임)를 Heap에 저장하고 다른 Virtual Thread로 갈아끼워집니다. (Context Switching)
4. Blocking이 끝난 Virtual Thread는 mount될 때 Heap에 저장해둔 스택 프레임을 불러와 중단 지점부터 다시 작업을 재개합니다.

5. Virtual Thread 테스트 - Context Switching

앞서 살펴본 것처럼 Virtual Thread 간의 Context Switching은 Virtual Thread의 실행이 끝났을 때 또는 Virtual Thread가 실행되다가 Blocking됐을 때 발생합니다. 그리고 이 과정은 코드 레벨에서 살펴봤듯 스택 프레임을 Heap에 저장하는 과정 등을 거치며 유저 레벨에서 발생됩니다. (참고 : 스택 프레임을 Heap에 복사할 때 사용되는 memcpy는 표준 C 라이브러리 함수로 시스템콜이 아닙니다) 

코드 상에선 그렇게 확인했지만, 실제로 Virtual Thread간의 Context Switching이 유저 레벨에서 발생하는지를 직접 검증하고 싶었습니다. 그래서 다음과 같은 코드를 준비했습니다. 코드 상에서 회사명이 나오는 부분들은 가렸습니다.

총 200개(THREAD_COUNT)의 자바 스레드를 만들고, 각각의 스레드가 10ms 동안 대기하는 과정을 100번(ITERATIONS)만큼 반복하여, 프로그램 실행 중 최소 20,000번(THREAD_COUNT X ITERATIONS) 이상의 Context Switching이 발생하도록 합니다. 동일한 코드를 Virtual Thread를 활용한 방식으로도 작성해줍니다.

이 각각의 프로그램들을 컴파일한 뒤, Linux에서 제공하는 커널 퍼포먼스 측정 도구인 perf를 활용해 각 프로그램을 실행하는 과정에서 Context Switching이 몇 번 발생했는지 측정해줍니다. 이때 커널 레벨에서 발생한 Context Switching이 측정되는 것이므로, 정말 Virtual Thread가 Context Switching이 유저 레벨에서 발생한다면 기존 스레드를 사용했을 때가 Context Switching 횟수가 더 높게 측정될 것임을 예측할 수 있습니다.

총 3번씩 측정했으며, 결과는 다음과 같습니다.

물론 이 테스트에서 기존 스레드는 커널 스레드가 생성되는 과정이 함께 측정되는 부분도 감안해야 합니다. 그러나 Virtual Thread를 사용한 프로그램이 기존 스레드를 사용한 프로그램보다 3배 이상 커널 레벨에서 Context Switching이 덜 발생했고, 유저 모드와 커널 머드에서의 실행 시간 비율을 볼 때도 Virtual Thread를 사용했을 때가 유저 레벨에서 실행된 비율이 더 높음을 쉽게 파악할 수 있습니다. 이를 통해 Virtual Thread간의 Context Switching이 유저 레벨에서 발생한다는 것을 실질적으로 확인할 수 있었고, 따라서 Virtual Thread를 통해 Context Switching 비용을 줄일 수 있음을 도출할 수 있습니다.

6. Virtual Thread 테스트 - Throughput

이번에는 Virtual Thread 사용시 정말 처리량을 높일 수 있는지를 테스트해봤습니다. 실제 업무에서 쓰이는 API에 테스트해보면 좋겠지만 그럴 수 없던 관계로.. 다음과 같이 Spring Boot를 활용해 간단히 2개의 API를 만들어줬습니다.

첫 번째로는 500ms씩 2번 Sleep하게 하는 API를 만들어주고, 두 번째로는 1부터 1억까지의 연산을 2번 반복하는 API를 만들어줘서 각각 I/O 작업 위주로 비즈니스 로직을 처리하는 상황과 CPU 연산 위주로 비즈니스 로직을 처리하는 상황을 가정해줍니다. 이를 토대로 I/O Bound 상황과 CPU Bound 상황에 대해, 기존 스레드 사용 시와 Virtual Thread의 사용 시의 처리량을 측정해봅니다.

테스트 환경은 다음과 같습니다.

1. Ubuntu 24.04
2. 2 core CPU / 4GB RAM
3. Spring Boot 3.3.4 / OpenJDK21
4. K6로 VU를 2,000까지 늘리며 진행, 각 3회씩 측정

먼저 I/O Bound 상황에 대한 결과입니다.

물론 간단한 코드를 기반으로 테스트한 것이므로 해당 결과가 실제 운영 환경을 대변하진 않습니다. 그래도 결과를 해석해보면, I/O Bound 상황에서 Virtual Thread는 Non-Blocking 처리가 가능하기 때문에 기존 스레드보다 더 높은 처리량을 보이고 있음을 눈으로 확인해볼 수 있습니다. 또한 Spring Boot에 내장된 톰캣의 스레드풀 사이즈를 별도로 설정해주지 않아 스레드풀 사이즈가 디폴트값인 200으로 만들어졌었는데요. 500ms씩 2번, 총 1초 정도를 대기하도록 API를 구성했기 때문에 기존 스레드를 사용한 결과가 TPS가 200 가까이는 올라가지만 200을 넘지 못하고 있는 것도 확인해볼 수 있었습니다.

다음으론 CPU Bound 상황에 대한 결과입니다.

마찬가지로 이 결과가 운영 환경을 대변하진 않지만, 결과를 보면 CPU Bound 상황에서는 Virtual Thread 사용시 오히려 처리량이 낮아지는 걸 볼 수 있습니다. Virtual Thread는 앞서 살펴본 것처럼 실행 시 Carrier Thread의 WorkQueue에 들어갔다가 mount되고, 다 끝난 뒤엔 unmount를 하는 과정 등을 거칩니다. 따라서 작업을 실행하는 데 드는 비용 자체는 기존 스레드가 Virtual Thread보다 더 저렴합니다. Blocking을 처리하는 비용이 Virtual Thread가 기존 스레드보다 훨씬 더 저렴한 것이죠. 따라서 작업을 실행하는 도중에 Blocking이 발생하지 않는 경우라면 오히려 Virtual Thread를 사용하는 것이 안티 패턴이 될 수도 있음을 도출할 수 있습니다. 이 테스트에서 사용된 CPU Bound 상황에 대한 것을 그 예로 볼 수 있습니다.

7.Virtual Thread 주의사항 - Pinning

Virtual Thread는 Carrier Thread에 mount되어 수행되다가, Blocking되면 Carrier Thread로부터 unmount된다고 소개했습니다. 근데 Virtual Thread가 Carrier Thread에 mount된 상태로 고정되어, Blocking이 발생해도 unmount가 되지 않는 상황이 발생할 수 있습니다. 이를 Pinning현상(Pinned 현상이라고도 부릅니다)이라고 부르며, 다음 상황에서 발생합니다.

1. Virtual Thread에서 synchronized 블록 사용 시
2. Virtual Thread에서 native method 사용 시

synchronized 블록은 모니터 락을 사용하여 동시 접근을 제어하는데, Virtual Thread가 아닌 Carrier Thread 수준(jvm 단)에서 이 락을 잡다보니 락을 획득한 Carrier Thread가 연관된 작업을 처리하는 동안 다른 작업을 처리할 수 없도록 고정되는 것이 원인입니다. Native method 역시 비슷한 이유로 고정됩니다. 이렇게 Pinning 현상이 발생하면 Virtual Thread의 장점이자 존재 이유(?)인 "Blocking 시 갈아끼우기"를 시전할 수 없게 되므로 성능 저하의 직접적인 원인이 될 수 있습니다.

Pinning 현상을 직접 테스트하기 위해 다음과 같은 코드를 준비했습니다.

2개의 Virtual Thread를 만들어 실행하는데, 각 Virtual Thread는 현재 스레드의 정보를 로그로 남기고, 2초 대기하다가 다시 스레드의 정보를 로그로 남기는 메서드를 실행하도록 합니다. 이 때 run이란 메서드를 synchronized로 묶지 않았을 때와 묶을 때 각각 어떻게 결과가 나오는지를 테스트합니다.

참고로 Carrier Thread는 여러 개가 만들어질 수 있는데, 제가 만든 2개의 Virtual Thread가 서로 다른 Carrier Thread에 mount되어 실행된다면 이 테스트는 의미가 없습니다. 따라서 다음과 같이 옵션을 줘서 Carrier Thread가 하나만 만들어지게 하고 테스트를 진행했습니다.

-Djdk.virtualThreadScheduler.parallelism=1 
-Djdk.virtualThreadScheduler.maxPoolSize=1 
-Djdk.virtualThreadScheduler.minRunnable=1

 테스트 결과는 다음과 같습니다.

우선 로그에 남아있는 스레드 정보가 ForkJoinPool-1-worker-1로 동일하기 때문에, 하나의 Carrier Thread에서 Virtual Thread들이 실행됐음을 볼 수 있습니다. Pinning이 발생하지 않은 경우 VT1이 먼저 로그를 찍고 sleep에 들어가면서 VT2로 갈아끼워지게 되고, VT2도 로그를 찍은 뒤 sleep에 들어가게 된 것을 볼 수가 있습니다. 2초 뒤에 VT1, VT2 둘 다 깨어나면서 로그를 찍게 되므로 전체 실행 시간이 약 2초임을 볼 수 있습니다. 반면 Pinning이 발생한 경우 VT1이 먼저 로그를 찍고 sleep에 들어가지만 VT2로 갈아끼워지지 못하게 되고, 2초 뒤에야 VT2로 갈아끼워지면서 전체 실행 시간이 4초 정도로 나오는 것을 볼 수 있습니다.

이를 통해 실질적으로 Virtual Thread 사용 중 Pinning이 발생한다면 성능 저하의 원인이 될 수 있음을 도출했습니다. Pinning이 발생된 구간에서 Blocking이 발생하지 않는다고 해도, 앞서 말씀드린 것처럼 작업을 실행하는 비용 자체는 기존 스레드가 더 저렴하기 때문에 Virtual Thread 사용 시 Pinning이 발생하지 않도록 주의할 필요가 있습니다.

글을 작성하는 시점인 24년 10월 9일 현재, Pinning에 대해 다음과 같이 조치할 수 있습니다.

1. synchronized block은 ReentrantLock으로 대체
2. native method 사용은 최애한 지양

참고로 현재 여러 Java Library들이 Virtual Thread와의 호환을 위해 내부적으로 사용하던 synchronized를 ReentrantLock으로 바꾸는 작업을 진행하고 있습니다.

8. 정리

1) 그래서 언제 쓰면 좋을까?

우선 다시 한 번 상기할 점은 작업을 실행하는 데 드는 비용 자체는 기존 스레드가 더 저렴하나, Blocking 처리 비용이 Virtual Thread가 훨씬 저렴하다는 것입니다. 또한 Virtual Thread는 지연시간이 아닌 처리량을 높이는 기술이므로, API 응답 시간을 줄이는 것 등이 주어진 미션일 때는 Virtual Thread 도입을 권장하지 않습니다.

현재 시스템이 Thread per Request를 기반으로 하는 Spring mvc 등을 사용 중일 때 Virtual Thread를 도입을 고려할 수 있습니다. 만약 현재 시스템이 Reactive Programming의 대표 격인 Spring Webflux 등을 사용 중이라면, Virtual Thread와는 패러다임 자체가 다르므로(Reactive Programming인 비동기, Virtual Thread는 동기) Virtual Thread 도입은 안티 패턴이 될 수 있습니다.

또한 현재 시스템이 받는 워크로드가 I/O 작업 위주이며, 시스템의 주 병목 원인이 이 I/O 작업들 위주인 것이 분명하다면 Virtual Thread 도입 시 처리량 향상을 꾀할 수 있습니다. 만약 워크로드가 CPU 연산 위주라면, 아까 살펴본 것처럼 Virtual Thread의 도입은 안티 패턴이 될 수 있습니다.

2) Virtual Thread 도입 시 검토해볼 것들

Pinning 발생을 방지하기 위해, 사용 중인 코드나 사용 중인 라이브러리 또는 프레임워크 내부에 synchronized 등을 사용하는 곳이 있는지 검토해야 합니다. -Djdk.tracePinnedThreads 옵션을 통해 Pinning을 trace할 수 있으며, 특히 Pinning이 발생한 구간에서 Blocking되는 부분이 있는지도 검토해야 합니다. 

그리고 Virtual Thread 사용 시, 시스템과 연동되는 타 시스템으로 폭발적인 트래픽 전파가 발생할 수 있음을 주의해야 합니다. 처리량이 올라가게 되면, 평소에 다른 시스템으로 10개의 요청을 보내다가 갑자기 100개 1,000개 10,000개 이상의 트래픽을 보내게 될 수 있습니다. Virtual Thread에는 배압을 조절하는 기능이 아직 없다보니, 상대 시스템도 이러한 트래픽을 처리할 수 있는 능력(?)이 되는지를 검토해볼 필요가 있습니다. 특히 DB connection같은 한정된 개수의 자원에 접근하는 경우, 내가 보낸 요청들이 되려 timeout이 나면서 떨어질 수 있는 가능성도 있습니다. 현재는 세마포어를 통해 배압을 조절하는 것이 권장되고 있으나, 결국 개발자 본인들이 Virtual Thread를 통해 해당 내용에 대해 인지하고 있을 필요가 있습니다.

이 외에도, Virtual Thread는 기존 스레드와 달리 매우 많은 수가 생성될 수 있으므로 ThreadLocal 등을 사용하는 곳이 있는지 검토할 필요가 있습니다.

정리하면, Virtual Thread를 실질적으로 도입하게 될 경우

1. 우리가 사용 중인 라이브러리 등의 대응이 가능한가?
2. 우리 서비스가 놓여진 인프라가 뒷밤침될 수 있는가?

를 검토해야겠습니다.

참고한 레퍼런스

https://junhkang.tistory.com/37

https://velog.io/@kimyj1234/Java-가상-스레드-Virtual-Thread

https://kkyu0718.tistory.com/126

https://findstar.pe.kr/2023/04/17/java-virtual-threads-1/

https://tech.kakaopay.com/post/ro-spring-virtual-thread/

https://0soo.tistory.com/259

https://spring.io/blog/2022/10/11/embracing-virtual-threads

https://dev.java/learn/new-features/virtual-threads/

https://dzone.com/articles/the-long-road-to-java-virtual-threads

https://d2.naver.com/helloworld/1203723

https://notypie.dev/java-virtual-thread-와-platform-thread/

https://dev.to/elayachiabdelmajid/java-21-virtual-threads-1h5b

https://nomoresanta.tistory.com/4

https://velog.io/@appti/Virtual-Thread

https://blog.honeybomb.kr/9

JNI란?

Java Native Interface의 약자로, 자바 코드에서 네이티브 코드(하드웨어와 운영체제가 직접 실행할 수 있는 기계어 또는 바이너리 코드를 의미)를 호출하거나, 반대로 네이티브 코드에서 Java 코드를 호출할 수 있게 해주는 프레임워크를 말합니다. C언어 또는 C++언어로 작성된 코드는 컴파일 시 해당 하드웨어에서 직접 구동될 수 있는 기계어로 컴파일되기 때문에 네이티브 코드에 해당되는데요(자바는 플랫폼에 독립적인 바이트코드로 컴파일된다는 점을 참고하면 좋습니다). 따라서 자바 코드에서 JNI를 통해 C언어 또는 C++언어로 작성된 코드를 실행할 수 있게 됩니다.

주로 다음과 같은 상황들에 JNI를 활용할 수 있습니다.

• 성능 최적화 : 성능이 중요한 부분을 C/C++로 구현하고, 이를 자바 코드에서 호출할 때 사용합니다.
• 기존 라이브러리 사용 : 이미 C/C++로 작성된 기존 라이브러리나 API를 자바 애플리케이션에서 활용하고자 할 때 사용
• 플랫폼 종속 기능 : 플랫폼에 특화된 기능(시스템콜 호출, 하드웨어 제어 등)이 필요한 경우 사용

사용 방법

메서드 앞에 native를 붙임으로써 네이티브 메서드임을 명시할 수 있습니다.

public class Jofe {
    public native void nativeMethod();

    static {
        System.loadLibrary("jofe");
    }

    public static void main(String[] args) {
        new Jofe().nativeMethod();
    }
}

native로 선언된 nativeMethod는 해당 메서드가 네이티브 라이브러리에서 구현됨을 의미합니다. Jofe클래스가 처음 로드될 때 네이티브 라이브러리인 jofe를 로드하는 것도 확인 가능합니다. main 메서드에서 Jofe 객체를 생성하고 nativeMethod를 호출하면, JVM은 네이티브 코드로 연결되어 해당 네이티브 메서드가 실행되게 됩니다.

다음 명령어의 실행을 통해 JNI를 사용하기 위한 헤더 파일을 만들 수 있습니다.

javac -h {헤더파일을 둘 위치} {Jofe.java의 경로}
# ex : javac -h . Jofe.java

그러면 다음과 같이 헤더파일이 만들어집니다.

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class Jofe */

#ifndef _Included_Jofe
#define _Included_Jofe
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     Jofe
 * Method:    nativeMethod
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_Jofe_nativeMethod
  (JNIEnv *, jobject);

#ifdef __cplusplus
}
#endif
#endif

이 헤더파일을 기반으로, c언어로 해당 네이티브 메서드를 다음과 같이 구현할 수 있습니다.

#include <jni.h>
#include "Jofe.h"

JNIEXPORT void JNICALL Java_Jofe_nativeMethod(JNIEnv *env, jobject obj) {
       printf("이거 하나 출력할라고 개고생중입니다");
}

이 c파일을 컴파일하여 다음과 같이 라이브러리를 만들 수 있습니다. 저는 macos여서 다음 커맨드를 사용했습니다.

gcc -I$JAVA_HOME/include -I$JAVA_HOME/include/darwin -shared -m64 -o {생성할 라이브러리 이름} {c파일 경로}
# ex : gcc -I$JAVA_HOME/include -I$JAVA_HOME/include/darwin -shared -m64 -o libjofe.dylib Jofe.c

그리고 컴파일된 Jofe.class를 다음과 같이 네이티브 라이브러리의 경로를 지정해서 실행해줍니다.

java -Djava.library.path={생성한 라이브러리 위치} -classpath {컴파일된 클래스파일위치} {실행할 클래스명}
# java -Djava.library.path=/Users/jofejofe/Development/JNI/src/main/java/org/example -classpath . Jofe

그러면 c파일에서 구현된 메서드가 실행되는 걸 확인할 수 있습니다.

실제로 자바에선 JNI가 어떻게 활용되고 있을까?

대표적으로 스레드의 생성 등에 활용하고 있습니다. 다음과 같이 Thread의 start()메서드를 까보면, 내부적으로 start0()이란 네이티브 메서드를 호출하고 있음을 볼 수 있습니다.

    // Thread.java
    
    public void start() {
        synchronized (this) {
            // zero status corresponds to state "NEW".
            if (holder.threadStatus != 0)
                throw new IllegalThreadStateException();
            start0();
        }
    }
    
    private native void start0();

해당 메서드의 구현체는 다음과 같습니다.

https://github.com/openjdk/jdk/blob/221e1a426070088b819ddc37b7ca77d9d8626eb4/src/java.base/share/native/libjava/Thread.c

#include "jni.h"
#include "jvm.h"

#include "java_lang_Thread.h"

#define THD "Ljava/lang/Thread;"
#define OBJ "Ljava/lang/Object;"
#define STE "Ljava/lang/StackTraceElement;"
#define STR "Ljava/lang/String;"

#define ARRAY_LENGTH(a) (sizeof(a)/sizeof(a[0]))

static JNINativeMethod methods[] = {
    {"start0",           "()V",        (void *)&JVM_StartThread},
    {"isAlive0",         "()Z",        (void *)&JVM_IsThreadAlive},
    {"setPriority0",     "(I)V",       (void *)&JVM_SetThreadPriority},
    {"yield0",           "()V",        (void *)&JVM_Yield},
    {"sleep0",           "(J)V",       (void *)&JVM_Sleep},
    {"currentCarrierThread", "()" THD, (void *)&JVM_CurrentCarrierThread},
    {"currentThread",    "()" THD,     (void *)&JVM_CurrentThread},
    // ...생략

네이티브 메서드의 이름과 c로 작성된 함수의 포인터를 매핑하고 있는 걸 볼 수 있습니다.

JVM_StartThread는 다음과 같이 구현되어 있습니다.

// jobject : 여기선 Java 스레드 객체(java.lang.Thread)를 나타냄. 이를 통해 스레드를 시작
JVM_ENTRY(void, JVM_StartThread(JNIEnv* env, jobject jthread))
#if INCLUDE_CDS
  // .. 생략
#endif
  // JVM 내에서 자바스레드(유저스레드)를 표현하고 관리하는 핵심 클래스
  // 자바스레드(유저스레드)와 커널 스레드를 연결하는 역할
  JavaThread *native_thread = NULL;

  // 이미 시작된 스레드를 다시 시작하려고 하는 경우 예외를 던지는지 여부를 결정하는 플래그
  bool throw_illegal_thread_state = false;

  {
    // 뮤텍스 잠그고 시작
    MutexLocker mu(Threads_lock);

    // 해당 Java 스레드 객체가 이미 시작된 스레드라면 => 플래그를 설정
    if (java_lang_Thread::thread(JNIHandles::resolve_non_null(jthread)) != NULL) {
      throw_illegal_thread_state = true;
    } else {
      // 스레드가 이미 시작되지 않은 경우, 스택 크기를 가져와서 새로운 JavaThread 객체 생성
      jlong size =
             java_lang_Thread::stackSize(JNIHandles::resolve_non_null(jthread));
      // 
      NOT_LP64(if (size > SIZE_MAX) size = SIZE_MAX;)
      size_t sz = size > 0 ? (size_t) size : 0;
      // 여기서 커널스레드가 새로 만들어짐
      native_thread = new JavaThread(&thread_entry, sz);

      // 커널스레드가 만들어졌다면, 자바스레드(유저스레드)를 매핑
      if (native_thread->osthread() != NULL) {
        native_thread->prepare(jthread);
      }
    }
  }
  
  // 플래그 설정에 따른 예외 던지기
  if (throw_illegal_thread_state) {
    THROW(vmSymbols::java_lang_IllegalThreadStateException());
  }

  assert(native_thread != NULL, "Starting null thread?");
   
  // 일종의 예외 처리
  if (native_thread->osthread() == NULL) {
    ResourceMark rm(thread);
    log_warning(os, thread)("Failed to start the native thread for java.lang.Thread \"%s\"",
                            JavaThread::name_for(JNIHandles::resolve_non_null(jthread)));
 
    native_thread->smr_delete();
    if (JvmtiExport::should_post_resource_exhausted()) {
      JvmtiExport::post_resource_exhausted(
        JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_THREADS,
        os::native_thread_creation_failed_msg());
    }
    THROW_MSG(vmSymbols::java_lang_OutOfMemoryError(),
              os::native_thread_creation_failed_msg());
  }

  JFR_ONLY(Jfr::on_java_thread_start(thread, native_thread);)
  
  // 스레드 시작
  Thread::start(native_thread);

JVM_END

주석에도 명시했지만, new JavaThread()에서 다음과 같이 커널스레드가 생성되는 과정도 볼 수 있습니다.

JavaThread::JavaThread(ThreadFunction entry_point, size_t stack_sz) : JavaThread() {
  _jni_attach_state = _not_attaching_via_jni;
  set_entry_point(entry_point);
  os::ThreadType thr_type = os::java_thread;
  thr_type = entry_point == &CompilerThread::thread_entry ? os::compiler_thread :
                                                            os::java_thread;
  os::create_thread(this, thr_type, stack_sz);
}

이와 같이.. 자바 코드에서 시스템콜이 필요해지는 경우, 개발자가 직접 사용하든 안 하든 JNI를 활용해 네이티브 코드를 호출하여 시스템콜을 수행하게 됩니다. System.out.println도 다음과 같이 JNI를 사용합니다.

private native void write(int b, boolean append) throws IOException;

저번에 등록(create) 기능까지 만들었고, 이번엔 조회(Read), 수정(Update), 삭제(Delete) 기능을 만들어보려 한다. 우선 조회부터 시작쓰.

게시글의 상세내용을 보기 위해서 클라쪽에서 서버 쪽으로 게시글id를 넘기도록 할 건데, 이 때 url변수로 넘기든가(ex : /board/1) 아님 쿼리스트링 형태로 넘기든가(ex : /board?id=1) 해야 한다. (body에 적는 방법 등도 있지만..패쓰) 아무래도 대중적인 방법은 url변수로 하는 방법이라 어떻게 하는지 알아봤다.

방법은 간단했다. @PathVariable이라는 어노테이션을 사용하면 됐다! 방법은

• GetMapping(Post든 뭐든 상관 X)의 url입력하는 부분에 {받을 변수명}
• 메서드의 파라미터로 @PathVariable("받을 변수명")

이다. 다음과 같이 활용해줬다.

@GetMapping("/{id}")
    public BoardResponseDTO getBoard(@PathVariable("id") Long id) {
        Board board = boardService.findBoard(id).get();
        // ... 생략
    }

그리고 다음과 같이 BoardResponseDTO를 만들어줬다.

@Getter
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class BoardResponseDTO {
    private Long boardId;
    private String writerNickname;
    private String title;
    private String content;
    private Long hits;
    private Long like;
    private LocalDateTime createdDate;
    private LocalDateTime updatedDate;
    private int categoryId;

    public static BoardResponseDTO from(Member writer, Board board) {
        return new BoardResponseDTO(
                board.getBoardId(),
                writer.getNickname(),
                board.getTitle(),
                board.getContent(),
                board.getHits(),
                board.getLike(),
                board.getCreatedDate(),
                board.getUpdatedDate(),
                board.getCategoryId()
        );
    }
}

요즘 이 토이플젝을 하면서 참고하는 분이 있는데, 그 분은 이런 식으로 from메서드를 만들어 활용하는 식으로 하는 것 같아 참고해봤다. AccessLevel지정해주는 건 Lombok으로 만들어주는 생성자의 접근지정자를 설정하는거다. private로 한 것은 외부에서 요 놈의 인스턴스를 만드는 것을 막아주므로, BoardResponseDTO를 만들려면 from메서드를 사용하는 수밖에 없다!

암튼! 그래서 결과는..

성공~! 저번에 인터셉터 통해서 응답값들을 통일시켜준 방식 그대로 뱉어지는 모습도 곁들여 볼 수 있었다.

그 다음으론 삭제기능을 만들어보기로 했다. 삭제 기능에서의 고민은 바로 "삭제 권한". 글의 작성자만이 본인의 글을 삭제할 수 있도록 해야 할 것이다. 저번 학기에 프론트를 했을 때는 따로 프론트 쪽에서 현재 로그인한 유저의 정보를 가지고 있었기 때문에, 내가 지금 보고 있는 글의 작성자와 내가 가진 유저의 정보가 같으면 그 글에 삭제버튼을 보이게 하는 식으로 이를 만들었다. 그러나 지금 드는 생각은 어차피 contextHolder?거기에 현재 로그인한 유저의 정보를 가진다 하니 걔를 통해서 비교해줄 수 있을 것 같다!

그래서 다음과 같이 일단 delete에 해당하는 메서드를 만들어줬다.

@DeleteMapping("/{id}")
public String deleteBoard(@AuthenticationPrincipal Member member, @PathVariable("id") Long id) {
    Board board = boardService.findBoard(id).get();
    Member writer = board.getWriter();
    if (writer.getEmail().equals(member.getEmail())) {
        return "same";
    }
    return "diff";
}

현재 유저와 게시글의 작성자 이메일이 같다면 same을 뱉고, 다르면 diff를 뱉을 거다. 우선 작성자로 로그인하고 request를 보내봤다! 결과는..

같다고 잘 나왔다. 이번엔 다른 사용자로 로그인하고 (즉 포스트맨 상에서는 헤더에 담는 토큰을 다른 걸로 설정) 보내봤다. 결과는..

다르다고 잘 나온다! 삭제코드 자체는 BoardRepository에 deleteById메서드를 만들어 다음과 같이 구현해줬다.

@Override
public void deleteById(Long id) {
    Board board = em.find(Board.class, id);
    em.remove(board);
}

암튼 그렇게 해서 만든 삭제기능은..

27번 게시물이 잘 삭제된 것을 볼 수 있었다.

마지막으로 수정 기능을 만들 차례. 제목이나 본문의 내용이 잘 바뀌는지도 중요하겠지만, 아무래도 관건은 

1. 수정일이 알아서 업데이트되는지, 생성일자는 변함없는지
2. 게시물의 id가 그대로 유지되는지

정도가 될 것 같다. 

컨트롤러에서 다음과 같이 코드를 작성했다.

@PutMapping("/{id}")
public BoardResponseDTO updateBoard(
        @AuthenticationPrincipal Member member,
        @PathVariable Long id,
        @RequestBody BoardDTO boardDTO) {
    Board oldBoard = boardService.findBoard(id).get();
    Member writer = oldBoard.getWriter();

    if (writer.getEmail().equals(member.getEmail())) {
        Board updatedBoard = boardService.updateBoard(id, boardDTO);
        return BoardResponseDTO.from(writer, updatedBoard);
    }
    
    return null;
}

역시나 요청을 보낸 사람의 정보와 게시글 작성자가 같을 때에만 수정이 이뤄지게 했다. 그리고 게시글 작성 때 사용했던 BoardDTO를 수정할 때도 그대로 재탕해줬다. 어차피 게시글 작성할 때 작성하는 부분이 수정할 때 작성하는 부분이랑 같으니까..

BoardRepository에서 다음과 같이 코드를 짜 수정이 이루어지게끔 했다.

@Override
public Board updateBoard(Long id, BoardDTO boardDTO) {
    Board board = em.find(Board.class, id);
    board.setTitle(boardDTO.getTitle());
    board.setContent(boardDTO.getContent());
    board.setCategoryId(boardDTO.getCategoryId());
    em.persist(board);
    return board;
}

세터 메서드들을 사용해 Board엔티티의 내용물들을 바꿔치기해주고 저장해주는 식. entitymanager의 save라는 메서드가 인자로 받는 entity의 id값이 있냐없냐에 따라 insert를 할지 update를 할지 결정해준다고 한다. 이 경우에선 이미 board는 id가 있는 상태이니 update가 될 것이다.

이제 한 번 시험해볼 차례! 우선 수정 전 db상황은 다음과 같았다. 여기서 28번 게시물을 바꿀 거다.

포스트맨을 사용해 수정 테스트하기. 결과는..!

우선 응답값 자체는 문제가 없어보인다! 과연 db에서는..?

수정한 부분들이 잘 바뀌었음을 확인했다. title, content, category_id 컬럼값이 바뀌었으며 board_id나 writer는 변함없는 걸 볼 수 있다. 또한 created_date는 변화가 없고 updated_date에만 변화가 생겼음을 잘 확인할 수 있었다.

스프링 공부하면서 많이 마주치는 키워드들이 있었다. DI, Ioc, 서블릿.. 등등

이런 것들을 짚고 넘어가야 할 것 같다는 생각이 들었다. 야생으로 학습 중인 만큼 지금 당장 이해 안 돼도 넘어가야 하는 부분들이 있겠지만, 그렇다고 다 넘기는 건 아닌 것 같다... 일단 한 번 짚어보고, 지금 당장 다 짚일 것 같지 않으면 넘기고 오 좀 된다 싶으면 짚고 가는게 좋을 듯 함.

그래서 서블릿이란 놈을 한 번 패보기로 했다.

배경

초창기 웹 프로그램은 정적 데이터만 전달 가능했다. 클라이언트가 어떤 걸 요청하면 웹서버가 정적데이터를 응답하는 식. 이게 끝

근데 이제 사용자 요청에 따라 다른 처리, 즉 동적인 처리를 해주고 싶었던 거다. 그걸 위해서 '웹 어플리케이션 프로그램'을 만들어 기존에 존재하던 웹 서버에 붙이고 싶은 거라고 보면 된다.

이걸 위해서 CGI가 등장했다. Common Gateway Interface약자로, 웹서버와 앞서 말한 웹 어플리케이션 프로그램 사이의 규약(인터풰이스)이다. C, PHP등으로 요놈의 구현체를 만든다. 이 구현체들은 결국 쉽게 말해서 동적 데이터를 처리해주는 놈, 즉 웹 어플리케이션 프로그램이다.

그래서 예전과 달리 '동적인 처리'를 해줄 수 있게 됐다. 사람들이 CGI를 많이 활용하게 됐으니까.

근데 문제가 많았던 거다. CGI가 많은 사용자를 처리하기엔 힘들었던 것.

• 클라이언트로부터 request가 들어올 때마다 그 놈들 하나하나마다 웹서버에서 프로세스를 만들어 처리. 프로세스니까 당연히 비용이 비쌌음
• request들에 대해 같은 CGI 구현체를 써도 프로세스들이 다르면 여러 개의 구현체를 사용해야 됐음. 당연히 비효율적이었음

이를 해결하기 위해서 프로세스가 아니라 쓰레드를 만들었다. 그리고 같은 종류의 여러 CGI구현체를 만드는 몹쓸 상황을 막기 위해 CGI구현체를 싱글턴으로 만들었고.

이 싱글턴이 바로 서블릿!! 클라이언트로부터 request가 들어올 때마다 쓰레드가 생기고, 이 쓰레드를 통해 싱글턴 CGI구현체에게 동적인 처리를 해달라하는데 이걸 해주는 그 놈을 서블릿이라 부르는 것. 즉 서블릿은 자바로 구현된 CGI기도 한 거다.

결국 서블릿은

= 클라이언트의 요청을 동적으로 처리할 때 쓰이는 자바 기반의 웹 애플리케이션 프로그래밍 기술(인터페이스임)

= 동적 컨텐츠를 만드는데 사용되는 놈!

이라고 말할 수 있다

좀 더 뜯어보기 - 동작 방식

서블릿이 그래 동적인 컨텐츠를 만드는 데 쓰이는 놈이란 건 알겠다. 웹서버가 이 놈한테 말을 건네서 이 서블릿이란 놈이 동적인 처리를 해주는 거구나. 

그 과정을 좀 더 뜯어본다.

HTTP request, response를 서블릿(얘 자체는 역시나 인터페이스)의 메서드들을 통해 편하게 다룰 수 있다고 한다.

httpServletRequest = 서블릿 컨테이너가 서블릿에게 전달하는 때 담는 봉투

httpServletResponse = 서블릿이 서블릿 컨테이너에게 돌려줄 때 담아보내라고 지정하는 봉투

1. 사용자가 url입력 
2. HTTP request가 웹서버로 전달됨
3. 웹서버는 이 요청이 정적 자원을 요청하는지 판단(정적 자원이면 그대로 정적 자원 주면 됨)
4. 동적인 처리가 필요하면 그 요청을 그대로 was한테 짬때림. 
5. was의 웹 컨테이너(= 서블릿 컨테이너)가 이를 받고, 처리하기 위한 쓰레드를 만듦
6. 그리고 컨테이너가 HttpServletRequest, HttpServletResponse객체를 만듦. HttpServletRequest객체로는 사용자가 요청한 내용을 편하게 다루고, HttpServletResponse객체에는 응답할 내용을 편하게 작성 가능
7. 컨테이너가 사용자가 입력했던 url이 어느 서블릿에 대한 요청인지 찾고(by web.xml ), 걔를 호출. 이 때 아까만든 두 객체를 서블릿에게 선물로 줌
8. 그 서블릿의 service메서드를 통해 요청이 처리됨! 즉 service메서드에 작성한 코드들이 실행되는 것.
9. 이 때 아까 받은 request객체를 사용하고, 응답할 내용은 아까 받은 response객체에 저장하는 것.
10. 또한 service메서드를 호출한 후 클라이언트가 보낸 요청이 GET인지 POST인지에 따라 doGet() 또는 doPost() 호출
11. 이를 다시 클라이언트에게 최종 결과 응답 후, HttpServletRequest, HttpServletResponse는 삭제

※ service메서드를 호출할 때 HttpServletRequest, HttpServletResponse객체를 넘기는 것임! 즉 서블릿이 만들어질때 이 두 놈을 넘기는게 아니라 service메서드를 호출할 때 두 놈을 선물로 주는 것임에 유의

※ 톰캣은 was면서 서블릿 컨테이너의 기능도 제공한다고 함!

나아가기 - 스프링 web MVC와 서블릿

그러나..서블릿 역시 문제가 있었던 것이었다. 

앞서 설명했듯 사용자가 입력한 url별로 서블릿이 매핑된다. 10개의 각기 다른 url들이 들어오면 10개의 서블릿들이 매핑되는 것! 그럴 때마다 서블릿들이 가지는 "공통된 로직"이 반복돼서 실행된다는 문제점이 있었다. 즉 개발 측면에서 상당히 비효율적이었음.

이런 점을 해결하기 위해, 클라이언트로부터의 요청을 받는 서버의 앞쪽에 모든 요청을 받는 하나의 서블릿을 두기로 했다. 그 컨트롤러가 "공통된 로직"을 수행하게 하고, 핵심 비즈니스 로직을 다른 핸들러들에게 위임하는 구조로 바꾼 거다!

이런 방식을 Front Controller Pattern이라고 한다. 하나의 서블릿(Dispatcher Servlet)으로 모든 요청을 받게 했으니, 요청의 진입점이 같아져 관리가 보다 더 수월해진다는 장점이 있다. 또한 각 서블릿마다 가지는 공통로직을 한 곳에서만 처리함으로써 중복되는 로직의 작성도 방지하게 된다.

(디테일하게 디스패처 서블릿이 요청을 처리하는 과정은 본 글에선 다루지 않음)

결국엔 이런 방식(디스패처 서블릿이 모든 요청을 받고 공통로직들을 처리하고..)을 스프링이 사용하는 덕분에, 개발자는 핸들러(즉 컨트롤러)에만 집중하면 되도록 발전해왔다..라고 이해하면 될 듯 하다. 

스터디를 진행하던 중 멘토님이 Lombok라이브러리를 사용해서 스터디를 진행하셨다. 하지만 스프링에 막 발을 들인 나는 롬복이 뭔지 모른다. 그래서 정리해봤다.

롬복?

어노테이션 기반으로 코드를 자동완성해주는 라이브러리라고 한다. 개발자 편의를 위해 쓰는 라이브러리인 듯 하다. 다른 언어도 마찬가지지만 자바 언어 역시 기계적으로 작성해야 하는 코드들이 상당히 많이 생기는데 그런 부분들을 자동화해주는 라이브러뤼. 사용한다면 귀찮은 부분들을 작성해주는 걸 편하게 할 수 있을 뿐더러 코드의 길이 자체가 줄어드는 효과를 얻는다는 이점이 있다.

활용예시 - Getter, Setter

클래스를 만들었다. 이 놈이 갖는 필드 하나하나에 대해 getter, setter를 하나하나 만들어줘야 하는데 여간 귀찮은 게 아니다. 이럴 때 롬복을 이용해 Getter, Setter어노테이션을 주면 지가 알아서 필드들에 대한 getter, setter들을 만들어준다.

@Getter
@Setter
public class Member {
    private Long id;
    private String name;
}

참고로 클래스 이름 위에 이 어노테이션을 작성하면 모든 필드들에 대해 적용되고, 필드 이름 위에 작성하면 해당 필드에만 적용된다.

활용예시 - NoArgsConstructor

빈 기본 생성자를 만들어준다.

@NoArgsConstructor
public class Member {
    private Long id;
    private String name;
    
   /* 이걸 자동으로 만들어준다
   public Member() {
   }
   */
}

활용예시 - AllArgsConstructor

모든 필드에 대한 생성자를 만들어준다. (DI(Dependency Injection)를 해주는 식으로)

@AllArgsConstructor
public class Member {
    private Long id;
    private String name;
    
   /* 이걸 자동으로 만들어준다
   public Member(Long id, String name) {
        this.id = id;
        this.name = name;
   }
   */
}

활용예시 - RequiredArgsConstructor

특정 필드들에 대한 생성자를 만들어준다. 도대체 어떤 필드들에 대해 해주냐? final이 붙은 필드들, 그리고 @NonNull 어노테이션이 붙은 필드들에 대해서 자동으로 생성자를 만들어준다. AllArgsConstructor와 마찬가지로 DI(Dependency Injection)을 해주는 생성자를 만들어준다. 

※ NonNull 어노테이션 : 롬복에서 쓰는 어노테이션으로, 얘가 멕여진 필드가 null이 되면 NullPointerException을 일으킨다.

@RequiredArgsConstructor
public class Member {
    private final Long id;
    @NonNull
    private String name;
    private int age;
    
   /* 이걸 자동으로 만들어준다
   public Member(Long id, String name) {
        this.id = id;
        this.name = name;
   }
   */
}

이 외에도 어노테이션들이 많다. 클래스에 대한 equals함수와 hashCode함수를 자동으로 만들어주는 @EqualsAndHashCode, 필드들을 기반으로 ToString메서드를 자동으로 만들어주는 @ToString, 객체 생성에 Builder패턴을 적용해주는 @Builder.. 암튼 다양하다. 그때그때 찾아가며 공부하면 될 듯.

스프링에서 @RequiredArgsConstructor를 사용한 생성자 주입

기존에 내가 알고 있던(물론 스프링 공부 시작한지 별로 안됨) 생성자 주입 방식은 이거였다.

@Service
public class MemberService {
    private final MemberRepository memberRepository;

    @Autowired
    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

(참고로 memberRepository같은 빈들은 스프링 컨테이너가 관리해준다고 하는데 얘네가 싱글톤 객체라..변하지 않기 때문에 final키워드를 붙이는 게 좋다고 한다)

여기서 잠깐 살펴볼 것이, 스프링은 생성자가 1개뿐이라면 @Autowired를 생략해도 된다. 이 경우 @Autowired를 자동으로 인식해 처리하기 때문. 즉 위 코드에서 @Autowired를 빼도 문제가 없다. 

그리고 @RequiredArgsConstructor는 final이 붙은 필드들에 대한 생성자를 알아서 만들어준다! 따라서 위 코드를 다음과 같이 아주 편하게 간소화시킬 수 있다.

@Service
@RequiredArgsConstructor
public class MemberService {
    private final MemberRepository memberRepository;
}

원리는 간단하다.

• RequiredArgsConstructor가 생성자를 만들어줌
• 그 생성자에 대한 Autowired를 자동으로 인식해 처리함