Сопрограммы: runBlocking vs coroutineScope

runBlocking просто блоки текущий поток, пока внутренние сопрограммы не будут завершены. Здесь поток, выполняющий runBlocking, будет заблокирован до тех пор, пока, сопрограмма из coroutineScope будет завершена.

Первый launch просто не позволит потоку выполнять инструкции, которые идут после runBlocking, но позволит перейти к инструкциям, которые идут сразу после этого блока launch - поэтому Task from coroutine scope печатается раньше, чем Task from runBlocking.

Но вложенный coroutineScope в контексте runBlocking не позволяет потоку выполнять инструкции, которые идут после этого блока coroutineScope, потому что runBlocking блокирует поток до тех пор, пока сопрограмма из coroutineScope не будет завершена полностью. Вот почему Coroutine scope is over всегда будет следовать за Task from nested launch.

I don't understand how coroutineScope and runBlocking are different here? coroutineScope looks like its blocking since it only gets to the last line when it is done.

С точки зрения кода в блоке ваше понимание правильное. Разница между runBlocking и coroutineScope происходит на более низком уровне: что происходит с потоком, когда сопрограмма заблокирована?

• runBlocking не является suspend fun. Вызвавший его поток остается внутри него до завершения сопрограммы.

• coroutineScope - это suspend fun. Если ваша сопрограмма приостанавливается, функция coroutineScope также приостанавливается. Это позволяет функции верхнего уровня, функции без приостановки, создавшей сопрограмму, продолжать выполнение в том же потоке. Поток «экранировал» блок coroutineScope и готов выполнить другую работу.

В вашем конкретном примере: когда ваш coroutineScope приостанавливается, управление возвращается коду реализации внутри runBlocking. Этот код представляет собой цикл событий, который запускает все сопрограммы, которые вы запустили в нем. В вашем случае некоторые сопрограммы будут запускаться после задержки. Когда придет время, он возобновит соответствующую сопрограмму, которая будет работать на короткое время, приостановится, а затем управление снова будет внутри runBlocking.

Хотя приведенное выше описывает концептуальное сходство, оно также должно показать вам, что runBlocking - это инструмент полностью отличается от coroutineScope.

• runBlocking - это низкоуровневая конструкция, которая должна использоваться только в коде фреймворка или автономных примерах, подобных вашему. Он превращает существующий поток в цикл событий и создает свою сопрограмму с Dispatcher, которая отправляет возобновляющие сопрограммы в очередь цикла событий.

• coroutineScope - это обращенная к пользователю конструкция, используемая для определения границ задачи, которая распараллеливается внутри нее. Вы используете его для удобного ожидания всей работы async, происходящей внутри него, получения окончательного результата и обработки всех сбоев в одном центре.

Из этой замечательной статьи https://jivimberg.io/blog/2018/05/04/parallel-map-in-kotlin/

suspend fun <A, B> Iterable<A>.pmap(f: suspend (A) -> B): List<B> = coroutineScope {
    map { async { f(it) } }.awaitAll()
}

With runBlocking, we were not using Structured Concurrency, so an invocation of f could fail and all other executions would continue unfazed. And also we were not playing nice with the rest of the code. By using runBlocking we were forcefully blocking the thread until the whole execution of pmap finishes, instead of letting the caller decide how the execution should go.

Выбранный ответ хорош, но не затрагивает некоторые другие важные аспекты предоставленного примера кода. Например, запуск не блокируется и должен выполняться немедленно. Это просто не соответствует действительности. Сам запуск немедленно возвращается, НО код внутри запуска кажется помещенным в очередь и выполняется только тогда, когда все другие запуски, которые ранее были помещены в очередь, завершены.

Вот аналогичный пример кода со всеми удаленными задержками и включенным дополнительным запуском. Не глядя на результат ниже, посмотрите, сможете ли вы предсказать порядок, в котором будут напечатаны числа. Скорее всего, у вас ничего не получится:

import kotlinx.coroutines.*

fun main() = runBlocking {
    launch { 
        println("1")
    }

    coroutineScope {
        launch {
            println("2")
        }

        println("3") 
    }

    coroutineScope {
        launch {
            println("4")
        }

        println("5")
    }

    launch { 
        println("6")
    }

    for (i in 7..100) {
        println(i.toString())
    }

    println("101")
}

Результат:

3
1
2
5
4
7
8
9
10
...
99
100
101
6

Тот факт, что номер 6 печатается последним, даже после того, как было выполнено почти 100 println, указывает на то, что код внутри последнего запуска никогда не выполняется, пока не будет выполнен весь неблокирующий код после запуска. Но это тоже не совсем так, потому что, если бы это было так, первый запуск не должен был бы выполняться до тех пор, пока не будут выполнены номера с 7 по 101. Нижняя линия? Смешивание запуска и coroutineScope в высшей степени непредсказуемо, и его следует избегать, если вы ожидаете определенного порядка в том, как все должно выполняться.

Чтобы доказать, что код внутри запусков помещается в очередь и выполняется ТОЛЬКО после того, как ВСЕ неблокирующий код завершен, запустите это (никакие сопрограммы не используются):

import kotlinx.coroutines.*

fun main() = runBlocking {
    launch { 
        println("1")
    }

    launch { 
        println("2")
    }

    launch { 
        println("3")
    }

    for (i in 4..100) {
        println(i.toString())
    }

    println("101")
}

Вот результат, который вы получите:

4
5
6
...
101
1
2
3

Добавление CoroutineScope нарушит это поведение. Это приведет к тому, что весь неблокирующий код, следующий за CoroutineScope, не будет выполняться до тех пор, пока ВСЕ код до CoroutineScope не будет завершен.

Следует также отметить, что в этом примере кода каждый запуск в очереди выполняется последовательно в том порядке, в котором они добавляются в очередь, и каждый запуск будет выполняться только ПОСЛЕ выполнения предыдущего запуска. Это может создать впечатление, что все запуски имеют общую нить. Это неправда. Каждому из них дается собственная ветка. Однако, если какой-либо код внутри запуска вызывает функцию приостановки, следующий запуск в очереди запускается немедленно, пока выполняется функция приостановки. Если честно, это очень странное поведение. Почему бы просто не запускать все запуски в очереди асинхронно? Хотя я не знаю, что происходит в этой очереди, я предполагаю, что каждый запуск в очереди не имеет собственного потока, но все они используют общий поток. Только когда встречается функция приостановки, кажется, что создается новый поток для следующего запуска в очереди. Это можно сделать так, чтобы сэкономить ресурсы.

Подводя итог, выполнение выполняется в следующем порядке:

1. Код внутри запуска помещается в очередь и выполняется в порядке добавления.
2. Неблокирующий код после запуска выполняется непосредственно перед выполнением чего-либо в очереди.
3. CoroutineScope блокирует ВЕСЬ код, следующий за ним, НО выполнит все запускающие сопрограммы в очереди перед возобновлением к коду, следующему за CoroutineScope.

runBlocking предназначен для блокировки основного потока.

coroutineScope предназначен для блокировки runBlocking.

Итак, прочитав здесь все ответы, я не обнаружил, что ни один из них не ответил на вопрос, кроме повторения формулировок фрагментов документации.

Итак, я продолжил поиск ответа в другом месте и нашел его здесь. Практически показывает разницу в поведении coroutineScope и runBlocking (то есть разницу между приостановкой и блокировкой).