runBlocking — คืออะไร, บริดจ์บล็อกกิงและทำงานอย่างไร

runBlocking คืออะไร?

runBlocking เป็นฟังก์ชัน Kotlin ที่สร้าง CoroutineScope ใหม่และเรียกใช้ coroutine ที่ส่งผ่าน โดยบล็อกเธรดปัจจุบันจนกว่าจะเสร็จสมบูรณ์ แตกต่างจาก Coroutine Builder อื่นๆ ทั้งหมด runBlocking ไม่ใช่ฟังก์ชัน suspend และสามารถเรียกใช้จากโค้ดซิงโครนัสปกติ ลายเซ็นของ runBlocking รับ CoroutineContext และบล็อก suspend และส่งกลับผลลัพธ์ชนิด T

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

runBlocking เริ่ม event-loop ใหม่บนเธรดปัจจุบัน เมื่อ coroutine เรียกฟังก์ชัน suspend (เช่น delay() หรือ await()) runBlocking จะบล็อกเธรดและเรียกใช้ coroutine อื่นที่กำหนดไว้บนเธรดเดียวกันจนกว่า coroutine ที่ถูกระงับจะกลับมาทำงานต่อ นี่คือ การบล็อกแบบร่วมมือ — เธรดไม่ว่างเฉย แต่ประมวลผล coroutine อื่น

runBlocking ทำงานอย่างไร

กลไกภายในของ runBlocking ขึ้นอยู่กับ event-loop: เมื่อเรียกฟังก์ชัน suspend runBlocking จะหยุดการทำงานของบล็อกปัจจุบันชั่วคราวและเรียกใช้ coroutine อื่นจากคิว เมื่อฟังก์ชัน suspend เสร็จสมบูรณ์ การทำงานจะกลับมาดำเนินต่อ วงจรนี้จะดำเนินต่อไปจนกว่า coroutine ทั้งหมดจะสิ้นสุด

Event-loop ภายใต้ฝาครอบ

runBlocking ใช้พูลเธรดเดียวของตัวเองในการเรียกใช้ coroutine แตกต่างจาก Dispatchers.IO หรือ Default runBlocking ไม่เปลี่ยนเธรด — มันประมวลผล coroutine ทั้งหมดบนเธรดปัจจุบัน โดยสลับการทำงานของพวกมัน นี่คือ บิลเดอร์เดียว ที่รับประกันการทำงานบนเธรดเดียวกัน

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 หรือบล็อกกิง ในโค้ด Android โปรดักชัน การใช้บนเธรดหลักเป็นสิ่ง ต้องห้ามโดยเด็ดขาด

สำหรับการทดสอบ Android ให้ใช้ kotlinx-coroutines-test กับ TestDispatcher แทน runBlocking สิ่งนี้ให้การควบคุมเวลา การทำความสะอาดอัตโนมัติ และการแยกการทดสอบ

ทางเลือกของ runBlocking

ในสถานการณ์ส่วนใหญ่ runBlocking สามารถและควรเปลี่ยนด้วยทางเลือกอะซิงโครนัส สำหรับ Android คือ viewModelScope, lifecycleScope หรือ CoroutineScope กับ dispatcher ที่เหมาะสม สำหรับการทดสอบ — 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 ในการทดสอบช่วยให้รอผลลัพธ์ของ coroutine แบบซิงโครนัสโดยไม่เปลี่ยนสถาปัตยกรรม สถานการณ์ที่สองคือไลบรารีที่มี API callback ซึ่งฟังก์ชัน 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 แทน callbacks — สิ่งนี้ทำให้ห่วงโซ่การดำเนินการอะซิงโครนัสง่ายขึ้นและปรับปรุงความสามารถในการอ่านโค้ด

อันตรายจากการใช้งานผิดวิธี

การใช้ runBlocking อย่างไม่เหมาะสมเป็นหนึ่งในข้อผิดพลาดทั่วไปเมื่อเปลี่ยนจากวิธีการบล็อกกิงไปยัง coroutine ปัญหาหลัก: การเรียกบนเธรดหลัก Android การซ้อน runBlocking การใช้ภายในฟังก์ชันอะซิงโครนัส และการเริ่มดำเนินการนานผ่าน runBlocking

• ANR — runBlocking บนเธรดหลัก Android บล็อกการเรนเดอร์ UI นานกว่า 5 วินาที
• Deadlock — runBlocking ที่ซ้อนกันภายใน coroutine บนเธรดเดียวกันนำไปสู่การบล็อกซึ่งกันและกัน
• ความสับสนของ dispatcher — Dispatchers.Main ภายใน runBlocking บนเธรดพื้นหลังไม่มี Looper และโยนข้อยกเว้น
• หน่วยความจำรั่ว — runBlocking ไม่ถูกยกเลิกอัตโนมัติเมื่อ Activity/Fragment ถูกทำลาย

กฎทอง: runBlocking คือ สะพาน ไม่ใช่สิ่งทดแทน ใช้มันเพียงเพื่อเชื่อมต่อโลกบล็อกกิงและไม่บล็อกกิง สำหรับงานอื่นๆ ทั้งหมด ให้ใช้ launch, async หรือ lifecycleScope