Channel：什么是通道、通道类型和 Kotlin 协程

Kotlin 中的 Channel 是什么？

Channel — 概念上类似于 Java 中的 BlockingQueue，但使用 suspend 函数 send() 和 receive() 代替阻塞的 put() 和 take()。Kotlin 开发者使用 Channel 来组织协程之间的数据交换，无需通过共享内存进行同步。通道保证有序交付 — 发送顺序与接收顺序一致。

创建通道

要创建 Channel，需要调用工厂函数 Channel<T>(capacity)。参数 capacity 确定通道类型：RENDEZVOUS (0)、UNLIMITED (Int.MAX_VALUE)、CONFLATED (-1) 或具体数字。元素类型 T 由泛型指定。通过 close() 关闭通道表示不会再有新元素。

Send 和 Receive

send(value) — 是一个 suspend 函数，如果通道已满，则挂起发送协程。receive() — 是一个 suspend 函数，如果通道为空，则挂起接收者。替代方案 trySend() 和 tryReceive() — 是非阻塞版本，在操作不可能时返回 Boolean 或 null。它们在非 suspend 上下文中很有用。

kotlinx.coroutines 中的 Channel 类型

Kotlin 通过缓冲区容量提供了四种 Channel 变体：Rendezvous (5BB9量 0)、Buffered (5BB9量 N)、Conflated (5BB9量 1，898D写) 和 Unlimited (5BB9量 Int.MAX_VALUE)。每种类型解决自己的任务，从严格同步到大规模数据缓冲。

Rendezvous Channel — 最严格的类型：send() 会阻塞，直到另一个协程中的 receive() 被调用。实质上，这是两个协程的相会点。适合严格的握手协议，当发送者必须等待接收者处理元素时。数据丢失被排除 — send 在 receive 执行完成前不会结束。

Conflated Channel — 仅存储最后发送的值。如果发送者在接收者取走旧值前放入了新值，旧值被丢弃。Conflated Channel 对 UI 状态很有用：如果用户快速改变滑块位置，中间值可以丢弃，只处理最后一个。

通道上的 Producer-Consumer

经典的 Producer-Consumer 模式在 Channel 上通过并行协程实现。Producer 在循环中调用 send(value)，consumer — receive(value)。生产者和消费者可以在不同的 Dispatchers 上工作：Producer 在 Dispatchers.IO上，consumer 在 Dispatchers.Main 上。Channel 自动同步访问，无需 Lock 和 synchronized。

Fan-out — 多个消费者共用一个通道。每个元素精确地到达一个消费者（round-robin 分配）。Fan-in — 多个生产者写入一个通道。发送协程争夺发送权，但元素顺序保持不变。两种场景都不需要额外的同步。

Produce — 是一个协程构建器，创建具有自动关闭功能的通道。函数 produce { } 返回 ReceiveChannel — 为消费者提供的只读通道。在构建器内部，send() 发送数据，当代码块执行完成或出现异常时，通道自动关闭，避免内存泄漏。

Select 和多路复用

kotlinx.coroutines 库提供了 select — 一个表达式，等待多个替代方案中第一个完成的通道。Select 允许对多个通道进行多路复用：例如，等待来自两个数据源的数据，并处理第一个响应的数据源。语法— select<T> { channel1.onReceive { } channel2.onReceive { } }。这是 Rx 中 amb 运算符的替代方案。

Channel 代码示例

第一个示例—最简单的 Rendezvous Channel，发送者等待接收：

val channel = Channel<String>()

scope.launch {
    channel.send("Hello")
    println("已发送")
}

scope.launch {
    val msg = channel.receive()
    println("已接收: $msg")
}

第二个示例—多个消费者共用一个通道（fan-out）：

val channel = Channel<Int>(Channel.UNLIMITED)

scope.launch {
    for (x in 1..10) channel.send(x)
    channel.close()
}

repeat(2) { id ->
    scope.launch {
        for (msg in channel) {
            println("消费者 #$id: $msg")
        }
    }
}

第三个示例—使用 produce 构建器并处理错误：

val source = produce {
    for (i in 1..5) {
        delay(200)
        send(i)
    }
}

scope.launch {
    source
        .consumeAsFlow()
        .catch { println("错误: $it") }
        .collect { println("元素: $it") }
}

Channel 与 Flow 的对比

Channel — 是 hot 原语：数据的发射不依赖于订阅者。Flow — 是 cold：数据在订阅时生成。Channel 支持多个生产者和消费者，保证每个元素被一个消费者接收（fan-out）。Flow 不适合多个独立生产者的场景。

Channel 使用可配置容量的缓冲区和 suspend 函数 send/receive 管理压力反馈。Flow 使用 suspend 机制 collect，通过协程实现自动压力反馈。Channel — 是一个低级工具，适用于特定场景：callback 转换、actor 模型、多发送者任务队列。

对于 Android 中的日常场景（UI 状态、数据库的响应式流），Google 推荐使用 Flow，而非 Channel。Channel 应在需要大量数据交换并精确控制缓冲时使用，或通过 callbackFlow 转换 callback 接口时使用—callbackFlow 的内部实现使用了 Channel。

一个重要的实际案例：在实现 WebSocket 客户端时，Channel 允许从一个协程写入消息，并从另一个协程读取消息，保证每条消息只被处理一次。Flow 不适合这个任务，因为它是 cold 的，不支持多个生产者。具有 UNLIMITED 容量的 Channel 确保入站消息不会在消费者的临时延迟中丢失。

管理通道的生命周期—是使用 Channel 的重要部分。当所有数据发送完毕后，必须关闭通道，以便消费者能完成迭代。调用 channel.close() 表示不会再有新元素。消费者可以通过 for (item in channel) 迭代—在 close() 和缓冲区清空后，循环自动结束。替代方案是，消费者可以在循环中调用 receive() 并处理 ClosedReceiveChannelException。

Channel 在 Android 中被广泛用于实现无依赖的 EventBus：使用 Broadcast 策略的全局 Channel<Event> 允许从应用程序的任何位置发送事件。与基于 LiveData 的总线不同，Channel 不绑定到 lifecycle，在切换屏幕时不需要归零。来自 ViewModel 的 send() 和 Activity/Fragment 中通过 lifecycleScope 的 receive() 提供了类型安全的通信，无需 Event 类。多个消费者在 Channel 上分担负载—每个元素被处理一次，这防止了同一事件在不同订阅者中被重复处理。

在 actor 系统中，Channel 作为 mailbox—actor 消息队列的实现基础。Actor — 是一个在循环中从 Channel 读取消息并顺序处理它们的协程。这种方法保证每条消息按发送顺序处理，无数据竞争。与 Akka 不同，Kotlin 没有内置的 actor 类型，但 Channel + launch 是一个轻量替代方案。

对于双向交换，使用 通道对：一个通道用于客户端向服务器发送请求，另一个用于服务器向客户端发送响应。例如，在多线程应用中实现 Pipe：生产者写入 OutputChannel，消费者从 InputChannel 读取。Suspend 函数 send 和 receive 保证 Producer-Consumer 不会溢出调用栈，因为协程是挂起而非阻塞。具有 BUFFERED 容量的 Channel 适合大多数场景，其中生产者和消费者的速度大致相等。对于非对称场景，请使用 UNLIMITED，以避免生产者在消费者忙碌时被挂起—这减少了死锁风险，但增加了内存消耗。

选择 Channel 的容量

在设计基于通道的架构时，记住 capacity 很重要：容量的选择直接影响峰值负载下的行为。具有 BUFFERED(N) 容量的通道赞作平滑缓冲区：如果消费者暂时比生产者慢，元素会累积。如果消费者的平均速度稳定低于生产者，缓冲区将被填满，发送协程将被挂起 — 这是自动的压力反馈，防止内存过载。

如果需要监控和调试 Channel，请使用 kotlinx-coroutines-debug：该工具显示活跃协程的数量、它们的通道状态（打开/关闭，缓冲区中元素的数量）以及挂起的 send/receive 操作的调用栈。Channel 还可以被包装在日志代理中：LoggingChannel<T> 类将调用委托给真实的 Channel，记录 send、receive 和 close 操作。这有助于在 close() 未被调用且消费者协程永远等待新元素时发现通道泄漏。