인프런 커뮤니티 질문&답변

명쾌하게 알려주셔서 정말 감사합니다. ㅎㅎ 명절 잘 보내세요!!

태현님 공부하다가 또 의문점이 생겨서 찾아오게 되었습니다. ㅎㅎ
보통 코루틴을 사용하지 않고 기본적인 스레드 풀만 사용을 하게 되면 코루틴 처럼 IO 스레드, main 스레드, default 스레드라는 개념이 없이 사용을 하고 있는데 결국 코루틴도 기존 스레드 풀에서 위 세개의 스레드로 나눠지게 될텐데 이 나눠지는 방식이 좀 궁금합니다!
예상하는 동작 방식은 스레드 풀에 스레드가 16개가 있다면 코루틴을 사용하여 io 스레드 선언시에 16개의 스레드 중에 1개의 스레드가 io 스레드로 될테고. 만약 여러곳 (a class, b class)에서 io 스레드를 사용하게 된다면 생성됐던 스레드에 task가 들어갈 것 같다고 생각이 듭니다! (맞는지는 모르겠지만..) 그럼 여기서 의문점이 드는것이 있는데요.

io, main, default 블록으로 선언하여 생성된 스레드를 a 스레드라고 하고 코루틴으로 인하여 생성하지 않고 다른 연산에 의해 생성된 그냥 스레드를 b라고 할 경우 코루틴의 task가 b스레드에 참여가 될 수가 있나요? 아니면 혹은 io, main, default 선언으로 인하여 생성된 스레드에만 코루틴의 task가 들어갈 수 있다고 생각하면 될까요?

안녕하세요 나라바님! ☺ 언제든 의문점이 생기시면 질문 주세요~~!! 👍

답변을 드리기 앞서

결국 코루틴도 기존 스레드 풀에서 위 세개의 스레드로 나눠지게 될텐데

라고 말씀해주신 부분을 정확히 짚고 넘어가야 할 것 같습니다.

코루틴이 어떤 스레드에서 실행될지는 현재 사용하고 있는 Dispatcher 에 따라 다릅니다! 그리고 Dispatcher 마다 고유한 스레드 풀을 갖고 있어요.

제가 코루틴을 Dispathcers.IO 에서 실행시킨다면, io 스레드에 코루틴이 바인딩되어 돌아가는 것이고, Dispatchers.Default 에서 실행시킨다면, default 스레드에 코루틴이 바인딩 되어 돌아가는 것이죠! 🙂

또한 이런 Dispatchers는 진작 고유한 스레드 풀을 갖고 있습니다. 때문에 io, main, default 블록을 만든다고 하더라도 스레드가 생성되지는 않고, 진작 존재하는 스레드에 제가 생성한 코루틴이 배정되는 방식입니다.

따라서

io, main, default 블록으로 선언하여 생성된 스레드를 a 스레드라고 하고 코루틴으로 인하여 생성하지 않고 다른 연산에 의해 생성된 그냥 스레드를 b라고 할 경우 코루틴의 task가 b스레드에 참여가 될 수가 있나요? 아니면 혹은 io, main, default 선언으로 인하여 생성된 스레드에만 코루틴의 task가 들어갈 수 있다고 생각하면 될까요?

에 대해 답변을 드려보면, 코루틴의 task가 어떤 스레드 (a스레드 or b스레드)에 배정될지는 해당 코루틴을 어떤 Dispatchers를 이용해 동작시키질지에 따라 다르며, 따라서 "아니면 혹은 io, main, default 선언으로 인하여 생성된 스레드에만 코루틴의 task가 들어갈 수 있다"와 유사한 것 같습니다! 🙂 (io, main, default 선언을 한다고 해서 스레드가 생성되지 않음은 위에서 말씀드렸습니다!)

명절에도 공부하시다니~ 고생 많으십니다. 🙂 이런 개념 자체를 잘 알아두시면, 추후에 멀티스레드, 가상 스레드와 같은 개념을 찾아 보실 때도 비슷한 측면이 많아 도움이 많이 되실 거에요!

나라바님을 응원합니다. 🔥 감사합니다! 🙏

태현님 명절인데도 답변 감사합니다. 😀 답변 주신것을 보고 질문 몇 가지만 남깁니다!!
1. 디스패처 별로 고유한 풀을 가지고 있다고 했는데 프로젝트에 스레드 풀을 설정하면 이 스레드 풀 안에서 디스패처 별로 스레드 풀을 나눈다고 생각하면 될까요? 즉 프로젝트에 설정된 스레드 풀이 A라고 한다면 이 A라는 스레드 풀을 나눠가진 디스패처 스레드 풀이 별도로 있게 될 것이고 디스패처 block 안에서 실행된건 디스패처 스레드에서 실행되고 그렇지 않을 경우에는 A스레드에서 실행되는 것이 맞을까요?!
2. 디스패처 별로 각각의 스레드 풀을 가지고 있다면 프로젝트의 성향에 따라서 디스패치 풀 size를 조정하면 좋을 것 같은데요. 예를들어서 cpu 연산이 많은 프로젝트라면 default 디스패처의 풀 사이즈를 좀 더 늘린다거나 같이요! 혹시 이런것도 가능한가요?
3. 마지막으로 디스패처가 스레드 풀을 생성할 때 어떠한 기준으로 스레드 풀 생성이 되는지도 궁금합니다! 전체 스레드 풀에서 몇 개 정도 스레드를 가져와서 스레드 풀을 만드는지와 같은..

하나씩 답변 드려 보겠습니다! 🙂

[1] 이 질문에서는 "프로젝트에 스레드 풀을 설정하면" 이라고 말씀해주셨는데요! 어떤 프로젝트에 어떤 스레드 풀을 설정하는 것인지 구체적으로 제가 알 수 없지만 Spring의 tomcat을 설정한다고 생각하고 답변 드려볼게요! 🙂

"이 스레드 풀 안에서 디스패처 별로 스레드 풀을 나눈다고 생각하면 될까요?"라고 질문 주신 내용을 먼저 짚어보면, 아닙니다! 우리가 tomcat을 설정하건 아니면 새로운 스레드 풀을 직접 만들건 디스패처에 존재하는 스레드 풀과는 별개 입니다. 한 애플리케이션 내에 여러 스레드 풀이 있을 수 있는 거죠.

추가로 Java 내에서도 CompletableFuture 를 사용할 경우 default thread pool인 common pool 역시 별도의 스레드 풀을 갖고 있습니다.

[2] 디스패처 별로 각각의 스레드 풀을 가지고 있다면 프로젝트의 성향에 따라서 디스패치 풀 size를 조정하면 좋을 것 같은데요. 예를들어서 cpu 연산이 많은 프로젝트라면 default 디스패처의 풀 사이즈를 좀 더 늘린다거나 같이요! 혹시 이런것도 가능한가요?

네네 물론 가능합니다! 이 경우 기본적으로 제공되는 IO, default Dispatcher의 스레드 풀을 늘리기 보다는 스레드풀을 이용해 새로운 디스패처를 만들지 않을까 싶네요! 아래와 같은 코드를 보신적이 있을거에요! 🙂

Executors.newSingleThreadExecutor().asCoroutineDispatcher()

다만, CPU 연산이 많은 경우 스레드 풀을 늘린다고 해서 성능이 더 좋아지지는 않습니다. 결국 물리적으로 동작할 수 있는 CPU core에는 한계가 있을텐데, 진작 CPU core를 최대치로 사용하고 있는 상황에서 스레드 개수만 늘리면 오히려 스레드 간의 context switching 비용과 core 경쟁이 발생해 성능이 떨어질 수 있습니다.

[3] 마지막으로 디스패처가 스레드 풀을 생성할 때 어떠한 기준으로 스레드 풀 생성이 되는지도 궁금합니다! 전체 스레드 풀에서 몇 개 정도 스레드를 가져와서 스레드 풀을 만드는지와 같

말씀드린 것처럼 전체 스레드 풀에서 몇 개의 스레드를 가져온다는 개념은 아니에요! 스레드 풀을 만든다는 것은 말 그대로 기존의 스레드 풀 혹은 main 스레드와 달리 새로운 스레드 풀을 만드는 개념입니다!

그리고 기본적으로 제공되는 default, IO dispatcher가 갖고 있는 스레드 풀 size는 다음과 같습니다.

• default : CPU 코어 수의 2배

• IO : max(64개, 코어 수)

답변 보시고 또 궁금한 것 있으시면 편하게 질문 남겨주세요~ 감사합니다! 😊

정말 이제 완벽하게 이해했습니다 ㅠㅠㅠ 진짜 감사합니다! 좋은 강의도 감사한데 이렇게 질문에 대한 답변까지 하나하나 친절히 알려주셔서 정말 감사해요!!

태현님 질문이 몇가지 또 있어서 찾아오게 되었습니다!

1. 스레드의 경우에는 컨텍스트 스위칭을 할 때 커널모드에서 실행이 될텐데요. 마찬가지로 코루틴도 스레드 기반에서 TASK가 실행이 될테고 단일 스레드에서 여러개의 TASK가 실행되면 컨텍스트 스위칭이 필요하지 않지만 만약 비동기처리나 동시성 처리를 할 때 같은 단일 스레드에서 실행이 되지 않은 경우에 결국 코루틴도 커널 모드에서 컨텍스트 스위칭이 일어나는 것으로 공부를 하면서 이해를 했는데 제가 이해한게 맞을까요?

2. 코루틴이 경량스레드로 불리는 이유가 스레드처럼 생성될때 스레드별로 스택을 가지지 않고 코루틴의 코루틴의 경우는 현재 함수의 실행상태, 로컬 변수등만 저장한다고 이해를 했는데요. 이 때 이 실행상태와 로컬 변수가 힙 메모리에 저장된다는 글과 스레드의 스택에 저장된다는 글을 봤는데 둘 중에 어떤게 맞는지도 궁금합니다! 코루틴이 컨텍스트 스위칭이 필요한거면 각각의 스레드 스택에 해당 정보들이 맞다고 생각되기는 하지만 정확하게 뭐가 맞는지 모르겠어서 질문드려요!

아이고~ 언제든 환영입니다~ 🙂

[1] 단일 스레드에서 실행이 된다고 하더라도 coroutine이 non blocking으로 동작하면 1번 코루틴 실행 하다가 yield -> 2번 코루틴으로 실행하다가 yield 처럼 처리 될 텐데, 그 과정에서 어쨌거나 코루틴이 바뀌긴 하니 아주 작은 context switch가 있다고 할 수 있을 것 같아요! (물론 2강에서 설명 드린 것처럼 process의 context switch나 thread의 context switch에 비하면 매우 미약하겠지만요~)

또한 단일 스레드에서 실행되지 않는 경우 결국 스레드가 CPU core에 binding 되어야 하므로 context switching이 일어나는 것이 맞습니다! 다만, 이 역시 일반적인 Thread-per-Request 구조의 200개, 500개 스레드 만큼 다수의 스레드를 사용하지는 않다보니 그 보다 적은 context switch로 볼 수 있을 것 같아요!

[2] 매우 흥미로운 질문인데요! 제 생각에는 heap에 저장될 것 같습니다 🙂 잘 아시겠지만 stack은 지역 변수처럼 특정 scope에서만 임시로 존재하는 값이고, (thread의 stack은 해당 thread라는 scope에서만 존재) heap은 해당 프로세스의 모든 단위에서 접근할 수 있는 값이죠! 코루틴의 경우는 10강에서 살펴봤던 것처럼 코루틴의 임시 상태를 수시로 저장할 수 있어야 하고, 그 코루틴을 수많은 스레드에 매핑해 실행시킬 수 있기 때문에.. (즉 여러 스레드를 넘나들며 접근할 수 있어야 하기에) heap이 맞을 것 같습니다!

감사합니다! 🙇

태현님 안녕하세요. 오랜만에 질문하러 왔습니다.ㅎㅎ.. 강의를 보고 회사에 코루틴을 적용해보고 있는데요. 이 과정에서 또 추가적인 궁금증이 생겨났습니다.

1. 현재 저는 mvc + corutine + jpa를 사용하고 있고 jpa 데이터를 가져오는 부분을 async로 감싼뒤에 awaitall을 통해 동시처리를 하려고 하고 있습니다. 근데 jpa와 mvc에서 스레드가 생성되는 부분이 블로킹으로 동작할텐데요. 이 과정에서 아래 코드의 실행 흐름이 궁금합니다. 요청이 들어오면 기본적으로 1개의 스레드가 생성될테고 아래 코드가 corutine scope으로 감싸져있다면 async 코드에서 dispatcher 스레드 풀에서 새로운 스레드가 실행되게 될 것 같습니다. 만약 a와 b가 서로다른 스레드에서 실행이 되면 블로킹이 안되지만 만약 같은 스레드에 코루틴 task가 할당되면 결국 블로킹이 발생해 저희가 원하는 동시성 처리가 안되는거 아닌지?

    // a 데이터베이스에서 특정 테이블의 데이터를 가져오는 jpa 코드
   val a = async { a.getA() }
    // b 데이터베이스에서 특정 테이블의 데이터를 가져오는 jpa 코드
   val b = async { b.getB() }
   
   await_all(a, b)

   2.그리고 코루틴에 대한 블로그 글들을 찾아보면 코루틴이 병렬성인지 동시성인지 의견이 분분한데 정확히 어떤게 맞을까요? 제가 이해한 바로는 작업의 상태를 저장하고 실행을 하고 비동기 처리가 완료되면 다시 작업을 재개하는 것이기 때문에 동시성이라고 생각을 했는데 만약 서로다른 디스패처들이 실행되면 병렬성이라고 보면 되는지..? 이것도 궁금합니다!
   3.마지막 질문인데 코루틴은 내부적으로 비동기 작업이 완료되면 어떤식으로 알 수 있는 걸까요? 제가 찾아본 결과는 코루틴의 작업은 이벤트루프에 들어가 작업이 완료되면 폴링을 통해서 작업의 완료시점을 알고 재개를 하는 것으로 알고 있는데 이 부분도 혹시 아시다면 궁금증을 해결해주시면 감사하겠습니다!

안녕하세요 나라바님! 🙂 오랜만에 뵙습니다. 하나씩 답변 드려 볼게요!

[1] mvc + coroutine + JPA

아래 코드가 corutine scope으로 감싸져있다면 async 코드에서 dispatcher 스레드 풀에서 새로운 스레드가 실행되게 될 것 같습니다. 만약 a와 b가 서로다른 스레드에서 실행이 되면 블로킹이 안되지만 만약 같은 스레드에 코루틴 task가 할당되면 결국 블로킹이 발생해 저희가 원하는 동시성 처리가 안되는거 아닌지?

이 부분이 핵심인 것 같은데요, 네 맞습니다. async 를 통해 특정 Dispatcher에서 코루틴을 실행시킬 수 있다고 하더라도 결국 요청이 동시에 100개가 들어와 async() 함수가 동시에 100번 실행되면, Dispatcher 안의 스레드는 한정되어 있기 때문에 어떤 요청은 앞 요청을 대기하게 됩니다. 그럼 동시성 처리가 되지 않는다고 생각할 수 있겠죠!

(물론 DB 접근이 0.05s 정도로 끝나고 Dispatcher 안의 스레드가 20~30개 정도 있으면 전체 처리는 0.2~0.25s 정도라서 눈 깜짝할새에 끝나긴 합니다 🙂)

다만 이런 동작은 webflux에서도 다른 의미로 비슷합니다. webflux에서 CPU-intensive한 작업이 계속 특정한 thread를 점유하고 있다면, 결국 network I/O를 처리해줄 수 있는 thread가 없고 그럼 요청이 밀릴 수 있어요

[2] 코루틴이 병렬성인가 동시성인가

먼저 용어에 대한 정의를 짚고 넘어가자면

• 병렬성 : 두 작업을 여러 CPU core에 분배하여 함께 실행시키는 것

• 동시성 : 한 CPU core에 두 작업을 할당하더라도 core를 시분할하여 (1번 작업 20% -> 2번 작업 20% -> 1번 작업 40% -> 2번 작업 40% -> ...) 마치 두 작업이 함께 실행되는 것처럼 보이는 것

입니다. 현대적인 CPU는 대부분 core가 둘 이상이기에 코루틴을 멀티 스레드에서 돌리면 병렬성과 동시성을 둘 다 만족한다고 할 수 있겠네요! 🙂

코루틴을 단일 스레드에서 돌리면, 동시성만 만족하게 될거고요!

[3] 코루틴이 내부적으로 비동기 작업이 완료되는 걸 아는 방식

결론부터 말씀드리면 저도 이 부분을 100% 파악하고 있지는 않습니다. 🥲

다만 말씀해주신 것처럼 event loop + 폴링 방식과 비동기적인 작업이 queue에 들어가 있고 실행중이던 다른 코루틴이 끝나면 queue에서 완료된 비동기적인 작업을 찾아 다시 실행하는 (= 마치 비동기 작업이 끝난걸 인식한 것 같은) 방식을 함께 사용하지 않을까 싶네요 🙂

감사합니다. 🙇

태현님 항상 빠른 답변 정말 감사합니다. ㅎㅎ

1. 제가 1번에 대해서 잘 이해를 못했는데 그럼 corutine과 mvc + jpa를 사용하면 사실상 성능개선의 효과를 못본다고 이해하면 될까요? (물론 DB 접근이 0.05s 정도로 끝나고 Dispatcher 안의 스레드가 20~30개 정도 있으면 전체 처리는 0.2~0.25s 정도라서 눈 깜짝할새에 끝나긴 합니다 🙂) 이 부분을 잘 이해 못했는데 결국 db에 대한 요청은 성능개선을 못하지만 디비를 접근하고 데이터를 가공하는 코드가 있다면 그 부분에 대한건 빠르게 처리가 된다는 말씀인지 잘 이해가 안된 것 같습니다! 만약 제가 한 말이 맞다면 결국 코루틴은 io에 대한 처리를 블록킹 하지 않고 병렬/동시성으로 돌리는게 장점인데 mvc + jpa에서는 성능이점이 없는 걸까요?

2. 결국 mvc는 스레드 풀을 이용하기 때문에 그럼 동시성과 병렬성을 다 만족한다고 이해하면 되겠네요. ㅎㅎ 감사합니다!

아유 아닙니다 ㅎㅎㅎ

[1]

제가 1번에 대해서 잘 이해를 못했는데 그럼 corutine과 mvc + jpa를 사용하면 사실상 성능개선의 효과를 못본다고 이해하면 될까요?

상황에 따라 다릅니다! 이렇게 이해해주시면 될 것 같아요. 코루틴을 적절한 Dispatcher와 함께 사용하면 스레드를 늘리는 효과가 나죠. 따라서 MVC, JPA를 사용하더라도 병목 지점에서 적절히 스레드를 늘릴 수 있다면 성능 효과를 얻을 수 있습니다.

다소 극단적인 예시를 들어보죠. MVC + JPA tomcat thread를 2개로 설정했습니다. 그리고 이 서버에 존재하는 유일한 API의 DB query가 1초 걸린다고 생각해보죠. 이 서버가 처리할 수 있는 TPS는 2가 됩니다. 그런데 만약 우리의 DB query를 coroutine안에서 돌리게 하고, 해당 coroutine은 30개의 스레드가 들어 있는 dispatcher 안에서 수행한다고 생각해봅시다. 그럼 우리의 TPS는 30이되고 기존보다 15배 늘어난 효과를 얻게 됩니다.

결론적으로 코루틴을 사용한다고 해서 무조건 성능이 좋아지는 것도 아니고, 성능 개선이 아예 없는 것도 아닙니다. 🙂 적절한 곳에 적절한 방식으로 사용하는 것이 중요하죠!

[2]

네네 맞습니다! 😊 감사합니다!! 🙇

태현님 답변 감사합니다! 그럼 제가 이해한게 맞는지 한 번 확인 부탁드립니다!
결국에 그러면 사실상 MVC + JPA를 사용하는 경우에는 비동기 처리 + 병렬성을 해주는 것이 큰 장점을 이룬다고 생각하고 위에 예시에서 코루틴을 사용하지 않으면은 A데이터 베이스에서 데이터를 가져오고 BLOCKING으로 대기했다가 B데이터를 가져오지만 코루틴을 사용하면 결국에 디스패처라는 별도의 스레드 풀을 처리하기 때문에 A와 B가 서로 다른 스레드에 배정될 경우 NON-BLOCKING 방식으로 처리 되는 효과가 있는 것이지 않나 싶습니다! 만약 단일 스레드에서 배정이 된다면 BLOCKING 방식으로 되기 때문에 동시성처리의 효과도 못보는 것이구요. 정리하면 코루틴은 동시성과 병렬성을 제공해주지만 MVC와 JPA같은 BLOCKING 방식과 같이 사용할 경우는 동시성에 대한 이점은 하나도 못보는 것이고 각각 다른 스레드에 배정이 될 경우는 비동기 + 병렬성의 이점을 본다고 생각합니다.

2. 사실 이런거라면 SPRING에서 제공하는 ASYNC를 사용해도 되지 않을까 싶은데 ASYNC의 경우는 별도의 스레드 풀을 만들어줘야 한다는 점과 함수 단위로 ASYNC 어노테이션을 붙여줘야 되고 각각의 함수들은 순차실행이 되기 때문에 위의 예시에 A와 B의 데이터를 가져오는 부분들을 별도의 함수로 또 만들어줘야하는 번거로움이 있지 않을까 싶네요

3. 그리고 혹시 코루틴이 내부에서 어떤 기준으로 단일 스레드에 TASK가 할당되는지 아니면 다른 스레드에 할당되는지 아시고 계실까요?! 찾아보는데 정보가 잘 없는 것 같네요 ㅠㅠ

거의 맞습니다! 🙂 다만

A와 B가 서로 다른 스레드에 배정될 경우 NON-BLOCKING 방식으로 처리 되는 효과가 있는 것이지 않나

라고 표현해주신 부분이 다른데요! 다른 스레드에 배정이 되더라도 결국 BLOCKING 방식인 것은 동일하나 스레드가 분산되며 전체 처리량이 빨라질 수도 있는 효과입니다.

또한

정리하면 코루틴은 동시성과 병렬성을 제공해주지만 MVC와 JPA같은 BLOCKING 방식과 같이 사용할 경우는 동시성에 대한 이점은 하나도 못보는 것

라고 표현해주신 부분 역시 결국 서로 다른 스레드로 blocking task가 분할되면 "동시성"에 대한 효과를 보는 것입니다! 🙂

물론 어쨌거나 핵심적으로

다른 스레드에 배정이 될 경우는 이점을 본다

는 부분은 맞습니다.

또한 @Async 에 대한 이야기도 해주셨는데요, 느끼신 것처럼. 본질적으로 비슷합니다. 말씀해주신 번거로움도 개인의 성향에 따라서는 충분히 느낄 수 있을 것 같네요.

마지막으로 질문 주신 코루틴 내부에서 어떤 기준으로 Task를 스레드에 할당하는지는 저도 잘 모르겠습니다. 🥲 추측해보자면 가장 작업을 넓게 펼칠 수 있는 형태로 할당하지 않을까 싶네요 🙂 감사합니다. 🙇

태현님 정말 감사합니다...항상 많은 질문을 해도 친절하게 답변해주시고 자세하게 알려주셔서 정말 감사합니다. 나중에 코루틴 전문가시니깐 webflux와 같이 사용하는 강의도 나중에 여신다면 나오자마자 구매하겠습니다. ㅋㅋㅋ 거의 이제 코루틴에 대해 감을 많이 잡은 느낌이지만 더 추가적인 궁금증이 생기면 찾아오겠습니다!! 남은 주말 잘 보내세요!!

아유 ㅎㅎㅎ 전문가라뇨~ 저도 배워야할게 많습니다. 🙂 안타깝게도 webflux 강의는 4~5년 동안은 나오기 힘들 것 같긴 합니다. 🥲 (사용처가 정해져 있는 기술이라서요..) 남은 주말 잘 마무리 하시기 바래요! 감사합니다. 🙇