Android 深度实践

Appearance

协程调试探针 ​

源：Debugging coroutines

在传统的 Java 开发中，我们可以通过 jstack 查看线程堆栈。但在协程世界中，一个线程可能承载数千个协程，且协程在挂起时不占用任何线程。普通的线程快照只能看到调度器线程池的闲置状态，无法透视业务逻辑的真实停滞点。协程探针 (Debug Probes) 弥补了这一鸿沟，它允许我们在运行时“扫描”所有活跃协程的状态、堆栈及层级关系。

启用与配置 ​

探针通过拦截协程的创建、恢复和完成事件来工作。由于其存在性能开销，默认情况下是关闭的。

kotlin
// 建议在 Application.onCreate 或 main 函数起始处调用
// 必须在所有协程启动前安装
DebugProbes.install()

// ... 执行业务逻辑 ...

// 打印快照
DebugProbes.dumpCoroutines()

// 卸载以恢复性能
DebugProbes.uninstall()
bash
# 推荐用于服务器或本地调试，无需修改业务代码
-Dkotlinx.coroutines.debug=on

解读协程快照 (Dump) ​

调用 DebugProbes.dumpCoroutines() 会输出一份详尽的报告。理解这份报告的每一个字段是排查问题的基础。

查看典型的 Dump 报告示例
text
Coroutines dump @ 2025-12-23T15:30:00

// 1. 协程名称与状态
Coroutine "PaymentWorker":Running @at kotlinx.coroutines.Delay.delay(Delay.kt:92)
    // 2. 协程挂起或运行时的虚拟堆栈
    at com.example.service.PaymentService.process(PaymentService.kt:45)
    at com.example.service.PaymentService$process$1.invokeSuspend(PaymentService.kt)
    // 3. 结构化并发中的父子关系
    (parent=JobImpl{Active}@5c3b5b1)

Coroutine "InventoryWatcher":Suspended @at kotlinx.coroutines.channels.AbstractChannel.receive(AbstractChannel.kt:590)
    at com.example.inventory.Watcher.start(Watcher.kt:12)
    (parent=JobImpl{Active}@2d1a3b4)

状态深度解析 ​

  • Running：协程当前正在某个线程上执行代码。如果一直停留在 Running 且堆栈不变，说明发生了线程阻塞（如死循环或同步 IO）。
  • Suspended：协程已挂起。这是最常见的状态。如果一个本该完成的任务长期处于 Suspended，说明其等待的资源（如 Mutex 或 Channel）可能发生了死锁或丢失。
  • Created：使用 CoroutineStart.LAZY 创建但尚未启动的协程。

实战：定位协程泄露 ​

协程泄露通常发生在使用了错误的 CoroutineScope（如 GlobalScope）或结构化并发被破坏时。

kotlin
class LeakDetector {
    private val scope = CoroutineScope(SupervisorJob())

    fun startLeakyTask() {
        // 假设这是一个被遗忘的任务，没有正确取消
        scope.launch(CoroutineName("LeakyTask")) {
            delay(Long.MAX_VALUE)
        }
    }
}
kotlin
// 定时打印协程统计
fun monitor() {
    val info = DebugProbes.dumpCoroutinesInfo()
    println("活跃协程数: ${info.size}")
    
    // 如果发现数量持续增长，使用 printJobLayout 打印层级结构
    DebugProbes.printJobLayout(myAppMainJob) 
}

技巧：使用 CoroutineName

在 Dump 报告中，默认的协程名通常是 coroutine#1。强烈建议在 launch 时传入 CoroutineName("业务模块名")，这能让你在数千个协程中瞬间准确定位目标。

实战：排查挂起死锁 ​

当两个协程互相等待对方持有的 Mutex 时，会发生协程层面的死锁。此时线程没有阻塞，但业务完全停滞。

kotlin
val mutexA = Mutex()
val mutexB = Mutex()

// 任务 A 锁定 A 尝试 B
launch(CoroutineName("Deadlock-A")) {
    mutexA.withLock {
        delay(100)
        mutexB.withLock { println("A done") }
    }
}

// 任务 B 锁定 B 尝试 A
launch(CoroutineName("Deadlock-B")) {
    mutexB.withLock {
        delay(100)
        mutexA.withLock { println("B done") }
    }
}

// 此时执行 DebugProbes.dumpCoroutines()：
// 你会看到 "Deadlock-A" 状态为 Suspended，堆栈指向 mutexB.lock()
// 你会看到 "Deadlock-B" 状态为 Suspended，堆栈指向 mutexA.lock()
// 结论：确定发生了 Mutex 循环等待。

性能开销与生产环境建议 ​

探针通过包装 Continuation 来追踪状态，这会带来额外的开销：

  • 内存占用：每个协程额外占用约 1KB 内存用于存储堆栈轨迹。
  • 执行效率：协程的创建和恢复速度会下降约 10%-20%。

生产环境策略

  1. 默认关闭：不要在生产环境的 Application.onCreate 中默认开启。
  2. 后门开启：可以通过特定的 Debug 接口或指令（如接收到某个自定义广播）动态调用 install()，采集完快照后立即 uninstall()。
  3. 配合 JMX：在服务器端，可以通过 JMX 动态开关探针，实现非侵入式的线上诊断。

核心开发准则 ​

  1. 结构化并发是调试的前提：探针的 printJobLayout 依赖于正确的父子关系。如果代码中大量使用 GlobalScope，你将得到一堆孤立的节点，无法进行系统性排查。
  2. 关注 Suspended 堆栈：如果探针结果显示大量协程挂起在同一个 receive() 或 lock() 调用处，说明该底层资源（如 Channel 或 Mutex）可能存在吞吐量瓶颈或逻辑死锁。
  3. 利用 IDE 可视化：IntelliJ IDEA 的 "Coroutines" 面板是探针的最佳 UI 呈现，它支持实时查看协程状态流转。
  4. 及时清理：安装探针后务必在诊断结束后卸载，避免对性能造成持久影响。