В чем разница между runBlocking и coroutineScope в Kotlin Coroutines?

Ключевое различие: блокировка потока vs приостановка корутины

Разница между runBlocking и coroutineScope фундаментальна и связана с тем, как они взаимодействуют с потоком выполнения.

1. runBlocking — блокирует поток

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

Пример с ошибкой:

fun main() {
    runBlocking {
        delay(1000L) // Блокирует main поток на 1 секунду
        println("Inside blocking")
    }
    println("After runBlocking") // Выполнится только после завершения runBlocking
}

Когда использовать:

• В main() функции, чтобы дождаться завершения корутин.
• В тестах, где нужно проверить асинхронный код синхронно.
• В библиотеках, где вы не можете использовать suspend функции, но должны вызвать корутину из блокирующего кода (например, в Java-коде или в колбэках).

Никогда не используйте runBlocking в продакшене Android или серверных приложениях — это заблокирует UI-поток или поток обработки запроса, что приведет к зависанию.

2. coroutineScope — приостанавливает корутину

coroutineScope — это suspend-функция. Она не блокирует поток, а приостанавливает текущую корутину до завершения всех дочерних корутин. Поток, на котором выполняется корутина, освобождается для других задач.

Пример:

suspend fun doWork() = coroutineScope {
    launch {
        delay(1000L)
        println("Child coroutine finished")
    }
    println("Scope started")
} // Здесь корутина приостановится, но поток не заблокирован

Когда использовать:

• Внутри suspend функций, чтобы выполнить несколько параллельных задач и дождаться их всех.
• Для структурированной конкурентности — все дочерние корутины автоматически отменяются, если родительская корутина отменяется.
• В Android (ViewModel, Activity) и серверных приложениях (Ktor, Spring WebFlux) — это основной способ работы с корутинами.

3. Практический пример: разница в поведении

Рассмотрим код, который показывает разницу:

fun main() = runBlocking {
    println("Before coroutineScope")

    coroutineScope {
        launch {
            delay(1000L)
            println("Task 1 done")
        }
        launch {
            delay(500L)
            println("Task 2 done")
        }
        println("Inside coroutineScope")
    }

    println("After coroutineScope") // Выполнится только после завершения всех дочерних корутин

    // А теперь runBlocking без coroutineScope:
    runBlocking {
        launch {
            delay(1000L)
            println("Task 3 done")
        }
        launch {
            delay(500L)
            println("Task 4 done")
        }
        println("Inside runBlocking")
    }
    println("After runBlocking")
}

Вывод будет:

Before coroutineScope
Inside coroutineScope
Task 2 done
Task 1 done
After coroutineScope
Inside runBlocking
Task 4 done
Task 3 done
After runBlocking

Обратите внимание: coroutineScope ведет себя как обычная suspend-функция — она приостанавливает выполнение дочерней корутины runBlocking, но не блокирует поток. runBlocking же блокирует поток, и второй вызов runBlocking не может начаться, пока первый не завершится.

4. Итоговая таблица

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

@Test
fun testMySuspendFunction() = runBlocking {
    val result = mySuspendFunction()
    assertEquals(expected, result)
}

suspend fun fetchData(): Data = coroutineScope {
    val deferred1 = async { api1.fetch() }
    val deferred2 = async { api2.fetch() }
    Data(deferred1.await(), deferred2.await())
}

// ПЛОХО
suspend fun bad() = coroutineScope {
    runBlocking { // Блокирует поток! Не делайте так
        delay(1000)
    }
}

// ХОРОШО
suspend fun good() = coroutineScope {
    delay(1000) // Просто используем delay
}