runBlocking — какво е това, блокиращ мост и как работи

Какво е runBlocking?

runBlocking — е функция на Kotlin, която създава нов CoroutineScope и стартира подадената корутина, блокирайки текущата нишка до нейното пълно завършване. За разлика от всички други Coroutine Builder, runBlocking не е suspend-функция и може да бъде извикан от обикновен синхронен код. Сигнатурата на runBlocking приема CoroutineContext и suspend-блок, връщайки резултат от тип T.

public fun <T> runBlocking(
    context: CoroutineContext = EmptyCoroutineContext,
    block: suspend CoroutineScope.() -> T
): T

runBlocking стартира нов event-loop в текущата нишка. Когато корутината извика suspend-функция (напр. delay() или await()), runBlocking блокира нишката и изпълнява други планирани корутини в същата нишка до възобновяване на спряната. Това е кооперативно блокиране — нишката не стои празна, а обработва други корутини.

Как работи runBlocking

Вътрешният механизъм на runBlocking се основава на event-loop: при извикване на suspend-функция runBlocking спира изпълнението на текущия блок и стартира други корутини от опашката. Когато suspend-функцията завърши, изпълнението се възобновява. Този цикъл продължава, докато всички корутини не завършат.

Event-loop под капака

runBlocking използва собствена еднонишкова пула за изпълнение на корутини. За разлика от Dispatchers.IO или Default, runBlocking не сменя нишки — обработва всички корутини в текущата нишка, редувайки тяхното изпълнение. Това е единственият билдър, който гарантира изпълнение в същата нишка.

fun main() {
    val threadName = Thread.currentThread().getName()
    println("Преди runBlocking на $threadName")

    val result = runBlocking {
        println("Вътре в runBlocking на ${Thread.currentThread().getName()}")
        delay(500L)
        "Done"
    }

    println("След runBlocking: $result")
}

Изходът ще покаже, че и трите println се изпълняват на една нишка. runBlocking не сменя нишката, а организира кооперативна многозадачност в рамките на една нишка чрез event-loop.

Кога да използваме runBlocking

runBlocking е оправдан в три сценария: точка на влизане main() в конзолни приложения, единични тестове на suspend-функции и мост — извикване на suspend-код от callback-базирани или блокиращи библиотеки. В production кода на Android използването на главната нишка е категорично забранено.

За Android тестове използвайте kotlinx-coroutines-test с TestDispatcher вместо runBlocking. Това дава контрол над времето, автоматично нулиране и изолация на тестовете.

Алтернативи на runBlocking

В повечето сценарии runBlocking може и трябва да бъде заменен с асинхронни алтернативи. За Android това са viewModelScope, lifecycleScope или CoroutineScope с правилния диспечер. За тестове — TestCoroutineDispatcher и runTest.

    // Лошо: runBlocking на главната нишка на Android
runBlocking(Dispatchers.Main) {
    val result = networkApi.fetchData()
    textView.setText(result)
}

// Добре: lifecycleScope
lifecycleScope.launch {
    val result = withContext(Dispatchers.IO) { networkApi.fetchData() }
    textView.setText(result)
}

Заместителят за тестове е runTest от kotlinx-coroutines-test. Той създава TestCoroutineScope с виртуално време, позволявайки тестване на закъснения без реално чакане. Това ускорява тестовете и ги прави детерминистични.

Примери за използване на runBlocking

Най-честият сценарий — тестване на suspend-функции. runBlocking в тестовете позволява синхронно изчакване на резултата от корутина без промяна на архитектурата. Вторият сценарий — библиотеки с callback API, където suspend-функциите се извикват от блокиращ контекст чрез runBlocking.

// Тест на suspend функция с runBlocking
class RepositoryTest {
    @Test
    fun `fetchUser returns correct data`() {
        val repository = UserRepository(FakeApi())

        val result = runBlocking {
            repository.fetchUser("123")
        }

        assertEquals("John", result.name)
        assertEquals("john@test.com", result.email)
    }
}

За мост между callback и suspend света използвайте CompletableDeferred в комбинация с runBlocking вместо callback-и — това опростява веригите от асинхронни операции и подобрява четливостта на кода.

Опасности от неправилна употреба

Неправилната употреба на runBlocking е една от честите грешки при прехода от блокиращ подход към корутини. Основни проблеми: извикване на Main-нишката на Android, влагане на runBlocking, използване вътре в асинхронни функции и стартиране на дълги операции чрез runBlocking.

• ANR — runBlocking на Main-нишката на Android блокира рендирането на UI за повече от 5 секунди
• Deadlock — вложен runBlocking вътре в корутина на същата нишка води до взаимно блокиране
• Объркване с диспечерите — Dispatchers.Main вътре в runBlocking във фонова нишка няма Looper и пада с изключение
• Изтичане на памет — runBlocking не се отменя автоматично при унищожаване на Activity/Fragment

Златно правило: runBlocking е мост, а не заместител. Използвайте го само за свързване на блокиращия и неблокиращия свят. За всички останали задачи прилагайте launch, async или lifecycleScope.