KTOR Server 에서 delay

kokoxg2님 안녕하세요. 지식 공유자 조세영입니다.제가 ktor를 실제로 사용해본 적이 없어 코드 흐름만 보고 답변 드립니다.질문 주신 코드만으로는 delay 이후 코드의 동작을 제한하는 부분이 없는 것 같아 보이는데요. delay 이후 코드가 동작하지 않는 다는건 너무 다양한 문제가 있기 때문에(모든 스레드 블로킹, 예외 발생으로 취소돼 동작하지 않는 것처럼 보이는 것, delay 재개 이후 코드에서 일시중단 후 재개 하지 않음, delay 도중 코루틴이취소됨 등) 정확한 부분은 디버깅을 해봐야 알 수 있을 것 같습니다.도움이 되었으면 좋을 것 같습니다. 감사합니다.

CoroutineDispatcher(Default, IO)의 limitedParallelism 관련 질문

denia park님 안녕하세요. 지식 공유자 조세영입니다.상세한 질문을 남겨 주셔서 감사합니다. 아래는 답변입니다. Dispatchers.Default 관련// CPU 코어가 4개인 컴퓨터 fun main() = runBlocking { launch(Dispatchers.Default.limitedParallelism(8)) { superCpuIntensiveTask() } launch(Dispatchers.Default) { lightCpuIntensiveTask() } println("Done") }Dispatchers.Default의 스레드풀 수를 넘어서는 숫자 혹은 스레드풀 수에 딱 맞게 스레드 수를 지정하여 limitedParallelism 함수를 실행하는 경우,Dispatchers.Default의 모든 스레드들은 제가 지정한 해당 작업을 처리하기 위해 계속 작업을 하고, 해당 작업이 시작된 이후에 Dispatchers.Default로 지정하여 실행한 코루틴 작업들은 제가 지정한 작업이 끝나기 전까지는 모두 대기하게 되는 것인가요??예를 들어, CPU 코어가 4개인 컴퓨터라면 Dispatchers.Default의 스레드 풀에 들어있는 스레드 수는 4개가 될테고, 해당 상황에서 Dispatchers.Default.limitedParallelism(4) 혹은 스레드가 몇개 있는지 몰라 Dispatchers.Default.limitedParallelism(8) 이렇게 지정하는 경우에아래 코드를 기준으로 하면 제가 먼저 시킨 작업(superCpuIntensiveTask())이 끝나기 전에는 lightCpuIntensiveTask()는 실행되지 않는 것일까요?(※ 멀티 스레드 작업이기 때문에 아래의 lightCpuIntensiveTask()가 먼저 실행될 가능성도 있지만 아주 재수가 나쁘게 superCpuIntensiveTask()가 먼저 실행이 된다면 어떻게 되는지가 궁금합니다) // CPU 코어가 4개인 컴퓨터 fun main() = runBlocking { launch(Dispatchers.Default.limitedParallelism(3)) { superCpuIntensiveTask() } launch(Dispatchers.Default.limitedParallelism(3)) { superCpuIntensiveTask2() } launch(Dispatchers.Default.limitedParallelism(2)) { CpuIntensiveTask() } println("Done") }답변코루틴은 실행 순서가 보장되지 않습니다. 뒤의 launch로 생성된 코루틴이 먼저 스레드를 점유해 실행될 수도 있어 실행 순서를 보장하려면 join을 써주셔야 합니다. 이 부분은 CPU Intensive Task이더라도 마찬가지입니다. 1번과 비슷한 질문입니다. CPU 코어가 4개인 컴퓨터에서 Dispatchers.Default.limitedParallelism를 여러번 사용한 경우, 코드상으로 보면 사용해야 하는 스레드의 수가 전체 스레드풀 수를 넘어서는 숫자가 되는데 이 경우에는 어떻게 스레드를 나눠서 사용하는 걸까요 ?답변Dispatchers.Default.limitedParallelism은 특정 작업을 위해 사용할 스레드를 제한하는 역할을 하는 것입니다. 여러 번 사용하더라도 4개의 스레드 중 일부로 제한되는 과정을 거치게 됩니다. Dispatchers.IO 관련Dispatchers.IO.limitedParallelism를 사용하면 새로운 Thread 집합을 만든다고 말씀해주셨습니다.그림에서 표현해주신 것처럼 기존에는 개별로 존재하는 Thread들을 새로 그룹으로 묶어낸다고 이해를 하면 되는 것일까요 ??(사진) 답변더욱 정확히는 스레드를 새로 생성하는 것이라고 이해해주시면 좋을 것 같습니다. 스레드는 비싼 자원이기 때문에 미리 정의된 Dispatcher(Dispatchers.IO)는 처음부터 모든 스레드를 생성해 놓는 것이 아닌, 필요할 때 스레드를 생성하는 방식을 택합니다.Dispatchers.IO.limitedParallelism으로 묶여있던 Thread들은 해당 코루틴이 끝나면 다시 그룹이 풀리는 것일까요 ??답변Dispatchers.IO.limitedParallelism로 생성된 디스패처가 메모리에 있는 동안은 그룹이 유지됩니다. 스레드는 작업이 없다면 정리될 수 있습니다. 만약에 Dispatchers.IO.limitedParallelism를 많이 사용하여 이미 기존의 스레드들 모두가 집합으로 구성이 되어있는 경우에는 신규로 집합을 만들 수가 없는 경우에는 해당 Dispatchers.IO.limitedParallelism 요청이 어떻게 되는지 궁금합니다.답변Dispatchers.IO.limitedParallelism는 스레드를 무제한으로 생성할 수 있습니다. 다만 이렇게 무제한으로 생성할 경우 메모리에 문제가 생길 수 있습니다.limitedParallelism의 Thread 수 지정해당 코드와 같이 Dispatchers.Default.limitedParallelism(4) Thread 수를 지정해야 할때, 어떤 기준으로 어떻게 Thread 수를 지정해야 좋을까요 ?? 강사님만의 팁이 있으시면 공유가 가능하실까요?? 답변 먼저 개인적으로는 꼭 필요한 경우가 아니면 지정하지 않는 편입니다. 가끔 동영상 처리나 이미지 처리를 위해 사용할 스레드 수 제한이 꼭 필요한 경우가 있는데요. 그때는 작업의 중요도에 따라 다르게 설정하기 때문에 딱 몇개라고 말씀 드리기가 어렵습니다.1번과 관련된 질문입니다. Thread 수를 지정할 때 현재 Thread Pool에 존재하거나 남아있는 쓰레드가 몇개인지 충분히 고려를 하면서 코드를 짜야할까요 ??실수로 스레드 풀의 전체 Thread 수를 넘어선 요청을 하게 되면 어떻게 되는지 궁금합니다.답변JVM 스레드는 OS 레벨의 스레드에 별도로 스캐쥴링 되는 과정을 거칩니다. 이 때문에 스레드를 너무 많이 생성하는 것이 아닌 이상, Thread 수 지정 시 스레드의 개수가 문제가 될 가능성은 적을 것 같습니다. 답변이 도움이 되었으면 좋을 것 같습니다. 질문 주신 내용들 중 수업에서 다룬 범위를 넘어가는 내용이 있어 답변의 키워드를 바탕으로 추가로 학습이 필요하실 수 있습니다. 참고 부탁드립니다.감사합니다.

suspend 문의 드려요

아무도_모를_아이디 님 안녕하세요. 지식 공유자 조세영입니다.말씀해주신대로 suspend 는 코루틴을 일시 중단하고 재개하는 키워드가 아니라, 일시 중단 지점이 있을 수 있음을 알려주는 키워드일 뿐입니다. 함수 내부에 일시 중단 지점이 있을 경우에만 스레드가 점유 해제됩니다.감사합니다.

스레드 양보 예제 + 코루틴/멀티스레드 사용 예시 질문

보키님 안녕하세요. 지식 공유자 조세영입니다. section10의 code4/Code10-4에서 보면코드가 아래와 같이 되는데package section10.code4 import kotlinx.coroutines.* fun main() = runBlocking { val startTime = System.currentTimeMillis() repeat(10) { repeatTime -> launch { Thread.sleep(1000L) // 1초 동안 스레드 블로킹(코루틴의 스레드 점유 유지) println("[${Thread.currentThread().name}] 작업 실행 ") println("[${getElapsedTime(startTime)}] 코루틴${repeatTime} 실행 완료") } } } fun getElapsedTime(startTime: Long): String = "지난 시간: ${System.currentTimeMillis() - startTime}ms"보통 이런 코드는 이렇게 멀티스레드로 처리하지 않나요..?네 맞습니다. 이런 코드는 보통 멀티 스레드로 처리합니다. 이 예제에서는 코루틴이 스레드 양보를 하지 않고 스레드를 블로킹 시키면, 일반적인 스레드를 사용하는 것과 다름이 없음을 보여줍니다.import java.util.concurrent.Callable import java.util.concurrent.Executors fun main() { val startTime = System.currentTimeMillis() val es = Executors.newFixedThreadPool(10) val callTasks = mutableListOf>() repeat(10) { repeatTime -> val callTask = Callable { println("[${Thread.currentThread().name}] 작업 실행 ") return@Callable repeatTime } callTasks.add(callTask) } val results = es.invokeAll(callTasks) // 결과 출력 results.forEach { future -> println("Result: ${future.get()}") } println("[${getElapsedTime(startTime)}] 실행 완료") es.close() } fun getElapsedTime(startTime: Long): String = "지난 시간: ${System.currentTimeMillis() - startTime}ms"음.. 그리고 스레드 1개를 만들어서 run을 시키면 1MB정도의 메모리 비용이 발생하고 context switch도 일어나지만, 코루틴은 훨씬 더 값싸다고 알고있습니다맞습니다. 스레드가 만들어지고 스캐쥴링 된 후, OS 레벨의 스레드에 의해 실행된 경우 sleep 함수가 호출되면 시에는 해당 시간만큼 cpu를 사용하지 않게 되고, 그 동안 스캐쥴링된 다른 스레드가 실행됩니다. 이런 경우 혹은 실행되는 스레드가 바뀔 때마다 context switch가 일어나는데요. Context Switching 비용은 말씀 해주신 것 처럼 비쌉니다.하지만, 코루틴은 힙 영역의 메모리에 저장되는 객체이고, 하나의 스레드를 서로 양보하면서 사용할 때 Continuation이라 불리는 실행 정보 객체를 사용해 실행 정보를 저장하고 복구하기 때문에 스레드에 비해 훨씬 메모리를 덜 차지하고 가볍습니다.추가로 아직 r2dbc처럼 비동기 트랜잭션 처리 등.. 이게 지원이 좀 미약하다고 알고있습니다. 서버의 작업은 대체로 CPU를 사용하는 부분이 그렇게 많이 없고 DB에 쓰고 값을 가져오는 동기화 코드, 순차처리 작업이 많은걸로 알고 있습니다.그럼 언제 멀티스레드를 사용하는게 좋고, 언제 코루틴을 사용하는게 좋을까요?먼저 코루틴도 멀티 스레드를 사용합니다. 다만, 코루틴 이전의 멀티 스레드 프로그래밍 API들은 비동기를 구현하기 위해 콜백을 사용해 코드가 코드의 유지 보수 비용이 늘어나는 문제가 있었는데요. 코루틴은 기존의 동기 방식의 코드처럼 짜는데 내부적으로는 비동기적으로 동작하게 만들 수 있다는 것이 가장 큰 장점입니다.따라서 만약 CPU를 계속해서 사용하는(연산이 계속해서 일어나는) 작업이 기존의 멀티 스레드 방식으로 만들어져 있다면 바꿀 필요가 없고, DB에 값을 쓰고 가져오는 코드 같이 I/O 작업이 주로 일어나는 코드는 코루틴을 사용하는 것이 좋습니다. 다만, 말씀 주신 것처럼 현재 사용하시는 프레임웍에 따라 코루틴에 대한 지원이 충분하지 않을 수 있기 때문에 이런 부분을 잘 고려해야 합니다. 또한 어떤 라이브러리들은 외부에 노출된 API를 보면 코루틴을 사용하는 것처럼 보이지만, 내부에서는 blocking call을 하는 경우도 있어서, 이런 경우에는 코루틴으로 전환하시는 이점이 없을 수 있기 때문에 잘 확인하시고 결정 하셔야 할 것 같습니다.

coroutineScope 관련 질문 및 실제 사용 사례에 대한 질문

denia park님 안녕하세요. 지식 공유자 조세영입니다.질문하신 부분 날리는달님께서 잘 답변해주신것 같습니다. 깊은 부분까지 모두 답변해주셔서 답변을 참고해주시면 감사할 것 같습니다.날리는달님 감사합니다!

Coroutine 취소 시점 체크

111sym님 안녕하세요. 지식 공유자 조세영입니다.일반적인 경우에는 코루틴 내에 로직들이 길게 적혀 있다면, IO 작업 등에서 코루틴이 일시 중단되면 취소가 체크되기 때문에 한 줄 한 줄 마다 isActive를 확인할 필요가 없습니다.이런 체크가 필요한 경우는 일반적으로 취소를 체크할 수 있는 시점이 없는 CPU 집약적인 작업 혹은 완료되기 전 다시 한 번 취소를 체크해야 하는 코루틴의 경우 등 입니다.정리하면 모든 줄에서 취소를 확인할 필요는 없으며, 다음 작업 전에 취소 체크가 명시적으로 필요한 부분에 한해 한정적으로 사용하는 것이 좋습니다. 좋은 질문 남겨 주셔서 감사합니다.

spring web mvc 환경에서 coroutine을 사용해보신 경험이 있으신지 궁금합니다.

영빈님 안녕하세요. 지식 공유자 조세영입니다.제 강의가 도움이 되어서 정말 기쁘네요! 좋은 말씀 남겨주셔서 감사하고, 강의도 열심히 들어주셔서 감사합니다. 질문에 답변을 드리면사내에서 사용하는 기술스택이 spring web mvc + JPA + feignClient인데 혹시 이와 유사한 환경에서 코루틴을 적용해보신 경험이 있으실까요?특히 제가 기대했던 부분은 IO작업에 관해 요청을 보내고 스레드를 점유하지 않음으로써 리소스를 효율적으로 사용하는 것(즉 처리량을 증가시키는 것)을 기대했었는데 아무래도 JPA나 feignClient나 응답이 올때까지 대기하는 구조로 되어 있더라구요ㅠㅠ.. 드라마틱한 성과를 기대하기는 조금 힘들어보이긴하네요 혹시 관련해서 유사한 경험이 있으신지 싶어서 의견을 묻고자 여쭤봅니다.답변Spring MVC를 사용하시면, 요청 당 스레드가 한 개가 생성되고, JPA를 사용하면 요청이 동기적으로 처리되는 것으로 알고 있는데요. 이런 경우는 코루틴을 사용하실 경우, 큰 이점을 기대하기는 힘들 것 같습니다. 만약 이점이 있다면, 요청을 받아서 처리할 때 내부에서 여러 서버에 요청을 하고 응답을 받을 때 등 요청 처리를 위해 여러 비동기 작업을 병렬로 실행해야 하는 경우 정도에서 이점이 있지 않을까 합니다.제가 생각하기에는 WebFlux + Spring Data 모듈에서 코루틴 지원 두 개를 함께 사용 했을 때 rps가 급증할 경우 성능적으로 유의미한 이점이 생기지 않을까 싶습니다. 코루틴을 사용중인 환경에서 rps가 급증하면 어떤식으로 흘러갈지 궁금합니다. 스레드가 고갈될 것 같은데, 자연스럽게 dispatcherIO등의 스레드가 새로 생성되나요?- 그렇다고 하면 메모리가 고갈될 것 같은데, 코루틴을 사용할때는 결과적으로 메모리 기준으로 스케일아웃을 걸어야할지? 등이 궁금하네요.답변Dispatchers.IO는 최대 생성할 수 있는 스레드의 개수가 특정 개수로 제한되어 있습니다. rps가 급증하고 요청을 처리할 때 Dispatchers.IO가 사용될 경우 최대 스레드 개수(일반적으로 64개) 만큼 생성되고 이 내부에서 코루틴이 서로 스레드 사용 권한을 양보하면서 동작할 것 같습니다. 즉, 코루틴을 사용해도 스레드가 무한정 생성되는게 아니고 64개의 스레드면 메모리도 상대적으로 많이 차지하지 않을 것으로 보입니다. 제가 안드로이드 실무 경력만 있고, Spring은 실무 경험이 없고 개인적으로 공부를 계속 하고 있다 보니 답변이 부족할 수 있는 점 참고 부탁드립니다. 좋은 질문 남겨주셔서 감사합니다. 좋은 하루 되세요!

코루틴이 멀티스레드의 단점을 해결했다는 부분에 대해 질문드립니다.

1. 우선 아래의 정리가 맞는지 여쭤보고 싶습니다.코루틴은 스레드를 점유하는 형태로 동작하므로, 반대로 코루틴이 blocking될때 스레드를 점유하지 않음으로써 다른 코루틴이 해당 스레드를 점유하게 되고 결과적으로 스레드가 blocking되는 일이 없어진다.답변: 코루틴은 스레드를 사용하지 않을 때 blocking 될 수도 있지만, 일반적으로 스레드를 사용하지 않을 때는 양보하는 방식으로 동작합니다. 이와 관련된 부분은 강의 섹션 11. 코루틴의 이해 에서 조금 더 자세한 설명을 확인하실 수 있습니다.2. 그런데 blocking이 되는 현상이 언제발생하나요?강의에서 말씀해주신 내용에 따르면, 다른 스레드 혹은 코루틴의 결과가 필요할 때 blocking되는 상황에 놓여지는 것 같은데 맞을까요?답변: blocking이라기 보다는 "스레드를 양보하고 결과가 올 때까지 대기하는 상황에 놓여진다"라고 표현하는 것이 좋을 것 같습니다. blocking은 일반적으로 스레드를 사용하지 못하게 만들 때 사용하는 경우가 많아서요.결국 그렇다고하면 이전 코드의 완료를 보장하는, 그러니까 sync한 방식으로 코딩을 해야할 때 스레드가 놀지 않으면서 & completableFuture처럼 콜백지옥이나 예외처리가 어렵지 않게 하는 것이 코루틴의 장점이 맞을까요?답변: 넵 비동기 코드를 동기 코드 처럼 작성할 수 있는 것도 코루틴의 장점 중 하나입니다. 3. 일반적인 IO상황도 위에서 얘기한 blocking이 맞을까요?다르게 말하면, Dispatcher IO에서 [요청을 보내고 기다려야만 하는 상황]에서도 코루틴은 스레드의 점유권을 내려놓음으로써 해당 스레드가 다른 작업을 처리할 수 있게 되는걸까요?예를 들면, A스레드가 코루틴의 DIspatcher IO에 의해 관리되는 IO전용 스레드고 IO스레드는 해당스레드하나만 존재할때(가용가능한 다른 스레드가 없는 상황)c코루틴은 서버에 호출을 보내서 4초가 걸리고, d코루틴은 서버에 호출을 보내서 5초가 걸리면 A스레드에서 c코루틴과 d코루틴을 병렬적으로 처리할 수 있는건가요?답변: 병렬성은 일반적으로 여러 스레드에서 동시에 작업이 처리되는 경우를 뜻하기 때문에 이런 경우는 스레드가 하나이기 때문에 병렬적으로 처리한다고 하기보다. 비동기적으로 처리한다고 표현하는 것이 맞을 것 같습니다. 일반적인 IO 를 처리할 때 코루틴은 스레드를 양보하는 방식으로 비동기적으로 처리하기 때문에 blocking이 일어나지 않습니다. 단순히 다른 스레드를 하나 생성해서 두가지 작업을 다 맡겼더라면 해당 스레드에서 4초 + 5초해서 9초가 걸렸을텐데, 코루틴기반의 A스레드에서는 약 5초정도밖에(조금 더 길수는 있겠지만) 안걸리는 게 맞을까요?답변: 일반적인 작업(루틴)은 해당 작업이 끝날 때까지 스레드를 점유(스레드 블로킹) 하는 방식으로 동작하기 때문에 9초가 걸리는 것이 맞습니다. 하지만, 작업을 코루틴으로 만들면 스레드를 사용하지 않을 때는 양보하기 때문에 5초가 걸릴 수도 있습니다. 더욱 자세히 말씀드리면 이 경우는 상황이 두가지로 나뉠 수 있는데요. 만약 각 작업이 CPU 집약적인 작업이라면 스레드 양보가 일어나지 않기 때문에 작업을 코루틴으로 만들더라도 4+5 = 9 초가 걸리게 됩니다. 하지만 각 작업이 I/O 작업이라면 코루틴으로 만들게 되면 스레드 양보가 일어나기 때문에 5초만 걸리는 것이 맞습니다. 4. 3번에 이어지는 질문인데요, 만약 3번이 맞다고 하면 IO작업의 응답이 왔을 때 콜백같은 게 적용이 되어서 Dispatcher에 새로운 작업으로 추가되는걸까요?그러면, IO요청을 보낸 스레드와 IO응답을 처리하게 되는 스레드가 왠지 다를 수도 있을 것 같은데 맞을까요?답변: 넵 정확합니다. 코루틴이 일시 중단될 때는 Continuation이라는 실행 정보가 저장되고 코루틴 작업이 재개될 때 이 Continuation을 사용해 작업을 복구하는 상황을 거칩니다. 이 때문에 IO 요청이 시작된 스레드와 처리하는 스레드가 다를 수 있습니다. 좋은 질문 남겨주셔서 감사합니다. 궁금한점이 해결되셨으면 좋을 것 같습니다! 저도 코루틴을 처음 접했을 때 정말 아릅답다고 느꼈는데요ㅎㅎ 코루틴의 세계로 오신 것을 환영하고, 이 강의에서 필요하신 모든 지식을 가져가실 수 있으시길 바라겠습니다!

Dispatcher.IO의 동작원리

chhong님 안녕하세요. 지식 공유자 조세영입니다.먼저 강의를 재밌게 봐주셔서 감사하다는 말씀 드립니다.질문에 답변을 드리면 Dispatchers.Default나 Dispatchers.IO의 스레드는 성능에 차이가 없습니다. 그럼에도 이 둘을 나눠놓은 이유는 각 디스패처는 작업의 특성에 맞게 스레드풀의 크기가 다르고 특정 작업을 위해 다른 작업이 방해받는 상황을 방지하기 위함이 큽니다. Dispatchers.IO는 IO 작업의 특성에 맞게 최대한 많은 작업을 병렬로 실행할 수 있어야 되면서, 각 스레드는 실행되지 않는 상태에 놓이는 시간이 길기 때문에 64개의 스레드를 사용할 수 있게 하고, Dispatchers.Default는 스레드가 아무리 많아도 실제로 CPU에서 동시에 처리할 수 있는 작업의 개수는 제한이 있기 때문에 프로세서의 수만큼으로 스레드를 제한한다고 이해해주시면 좋을 것 같습니다.답변이 도움이 되었다면 좋을 것 같습니다. 감사합니다.

실무에서 runBlocking 와 CoroutineScope 실무 사용에 대해

아무도_모를_아이디님 안녕하세요. 지식 공유자 조세영입니다.해당 부분 안드로이드의 CoroutineScope 경우 인프런 AI인턴이 잘 답변해준거 같습니다. Activity의 경우 lifecycleScope에서, ViewModel에서 코루틴을 실행하는 경우 viewModelScope에서 코루틴을 실행해 생명주기별로 관리를 할 때 사용되고, runBlocking은 동기 코드와 코루틴의 연결점 역할이 필요할 때 사용됩니다.서버에서도 runBlocking은 마찬가지이고, CoroutineScope의 경우 별도로 구조화되어야하는 작업이 있는 경우, 혹은 작업이 특정 생명주기 별로 관리되어야 하는 경우 사용하면 될 것 같습니다. 스프링을 예로 들자면 특정 Bean이 파괴될때 취소돼야 하는 작업이 CoroutineScope 있는 경우 @PreDestroy와 함께 사용하면 되지 않을까 합니다.서버의 경우는 제가 개인적으로 공부했던 부분이고 실무를 경험해보지 않았다보니 답변이 부족할 수 있는점 양해 부탁드립니다.