使用runBlocking测试挂起函数：阻塞当前线程执行协程
原理：协程与阻塞线程之间的桥梁
runBlocking是Kotlin协程库中唯一一个会阻塞当前线程的协程构建器。它创建一个新的协程作用域，并在此作用域内执行协程代码，同时阻塞当前线程直到该协程及其所有子协程执行完毕。正是这种“阻塞等待”特性，使得它成为JUnit测试中调用挂起函数的唯一直接方式——测试线程可以像调用普通同步方法一样等待协程结果。
| 构建器 | 是否阻塞当前线程 | 返回值 | 典型用途 |
|---|---|---|---|
runBlocking | 是 | 协程表达式的返回值 | main函数、测试、桥接阻塞与非阻塞代码 |
launch | 否 | Job | 启动不计结果的协程 |
async | 否 | Deferred<T> | 并发执行并等待结果 |
执行模型关键点：
runBlocking内部维护一个事件循环，它在阻塞线程的同时会处理协程的调度、挂起和恢复，因此协程内的挂起函数可以正常工作，而不会发生死锁。
实现流程：在JUnit测试中使用runBlocking
- 声明测试方法：直接在
@Test方法内部调用runBlocking，传入一个挂起lambda。 - 调用挂起函数：在
runBlocking块内直接调用待测试的挂起函数。 - 断言结果：使用JUnit的
assertEquals等断言验证返回值。 - （可选）验证Mock交互：在块外或块内使用Mockito验证模拟对象行为。
代码示例：测试挂起的网络请求
假设有一个挂起的Repository方法：
suspend fun fetchUser(id: Int): User {
delay(100) // 模拟网络延迟
return User(id, "test_user")
}对应的JUnit测试：
@Test
fun `fetchUser should return correct user`() {
val result = runBlocking {
val repo = UserRepository()
repo.fetchUser(1)
}
assertEquals(1, result.id)
assertEquals("test_user", result.name)
}
提示：测试中
runBlocking会阻塞测试线程最多等待协程完成，默认没有超时限制。为避免测试卡死，建议在测试框架层面设置全局超时（如JUnit 5的@Timeout）。
适用场景
- 纯挂起函数单元测试：不涉及协程上下文切换或复杂并发，直接测试业务逻辑。
- 桥接阻塞框架：需要与不支持协程的第三方库或旧API交互时。
- 快速验证：在小型单元测试中快速验证协程内部行为，无需引入
TestCoroutineDispatcher等测试工具。 - main函数入口：在
fun main()中使用runBlocking是启动协程应用的标准方式。
局限与常见错误
| 局限 / 错误 | 说明 | 解决方案 |
|---|---|---|
| 线程阻塞导致死锁 | 在协程内部对同一线程执行阻塞操作（如Thread.sleep）时可能引发死锁。 | 在协程中始终使用挂起版本delay()代替线程阻塞。 |
不支持多个runBlocking嵌套 | 嵌套会导致外部runBlocking等待内部，破坏协程协作式调度。 | 避免嵌套；使用coroutineScope或supervisorScope代替。 |
| 测试超时不可控 | 默认没有超时，长时间运行的协程会阻塞测试线程。 | 使用JUnit 5的@Timeout注解或withTimeout包装调用。 |
| 无法测试协程取消与调度 | runBlocking只能在当前线程调度，无法测试跨线程协程的取消行为。 | 对取消相关测试使用TestCoroutineDispatcher。 |
| 性能影响 | 阻塞线程在大量测试中会降低并行执行效率。 | 对于集成测试，优先使用kotlinx-coroutines-test提供的测试调度器。 |
常见陷阱：不要在生产代码的挂起函数内部调用
runBlocking！这样做会阻塞调用线程，违反协程的非阻塞原则，并极大概率导致性能瓶颈或死锁。保持协程的传递性——挂起函数应该始终通过suspend关键字传播协程上下文。
调试与验证
在runBlocking测试中调试挂起函数时，可以使用IDE的断点正常暂停。由于协程是在当前线程上顺序执行的，调用栈清晰，便于逐行跟踪。输出日志时，注意Thread.currentThread().name始终为测试线程名，不会出现协程跨线程跳转的现象。
// 调试示例：在runBlocking块内打印线程信息
@Test
fun `debug thread identity`() {
runBlocking {
println("Thread: ${Thread.currentThread().name}") // 始终为测试主线程
delay(10)
println("Still on thread: ${Thread.currentThread().name}")
}
}性能与稳定性考虑
- 避免长时间阻塞：单个
runBlocking测试应控制在毫秒级，防止CI流水线超时。 - 配合
withTimeout：在测试中给协程加上超时保护，防止挂起函数意外无限阻塞。 - 使用
@TestInstance控制生命周期：在类级测试中使用@TestInstance(TestInstance.Lifecycle.PER_CLASS)可以复用协程上下文，减少runBlocking开销。 - 并行测试冲突：由于
runBlocking会占用线程资源，在多线程并行测试中应限制并发数，避免测试线程池耗尽。