如何以最优性能将Java Swing事件转换为Kotlin Flow

我正在尝试将Java Swing事件（通常通过事件监听器获取）转换为Kotlin Flow，目前看到四种不同的实现方式，下面从性能、可靠性、资源占用三个维度逐一分析，同时解答最后关于协程创建的疑问。

四种实现代码 #

fun JButton.actionEvents1(): Flow<ActionEvent> = callbackFlow {
  val listener = ActionListener { e ->
    trySend(e)
  }
  addActionListener(listener)
  awaitClose {
    removeActionListener(listener)
  }
}

fun JButton.actionEvents2(): Flow<ActionEvent> = callbackFlow {
  val listener = ActionListener { e ->
    trySend(e).isSuccess
  }
  addActionListener(listener)
  awaitClose {
    removeActionListener(listener)
  }
}

fun JButton.actionEvents3(): Flow<ActionEvent> = callbackFlow {
  val listener = ActionListener { e ->
    trySendBlocking(e)
  }
  addActionListener(listener)
  awaitClose {
    removeActionListener(listener)
  }
}

fun JButton.actionEvents4(
  scope: CoroutineScope
): Flow<ActionEvent> = callbackFlow {
  val listener = ActionListener { e ->
    scope.launch { send(e) }
  }
  addActionListener(listener)
  awaitClose {
    removeActionListener(listener)
  }
}

各实现细节分析 #

1. actionEvents1()

• 性能：最优。trySend是非阻塞调用，直接在Swing的事件调度线程（EDT）执行，不会阻塞UI线程，对UI响应速度无影响。
• 可靠性：最差。当Flow的缓冲区满时，trySend会返回Failure，事件直接丢失，且代码中没有任何失败处理逻辑，完全感知不到丢事件。
• 资源占用：最低。不需要额外协程、阻塞等待，仅占用少量内存存储监听器实例。

2. actionEvents2()

• 性能：和actionEvents1一致，同样是非阻塞调用，EDT无负担。
• 可靠性：略优于actionEvents1。通过isSuccess可以判断事件是否发送成功，虽然代码里没做后续处理，但至少可以基于这个结果加日志、告警逻辑，避免完全不知情的丢事件。
• 资源占用：和actionEvents1相同，无额外开销。

3. actionEvents3()

• 性能：最差。trySendBlocking是阻塞调用，当Flow缓冲区满时，会直接卡住Swing的EDT线程——EDT是处理所有UI事件的核心线程，一旦阻塞会导致界面卡顿、无响应，严重影响用户体验。
• 可靠性：最高。只要Flow没有被取消，阻塞会一直等待缓冲区有空间，事件最终都会被发送，不会丢失。
• 资源占用：中等。阻塞EDT会导致其他UI事件排队等待，占用线程资源，甚至可能引发线程死锁风险。

4. actionEvents4()

• 性能：较好。scope.launch会立即返回，不会阻塞EDT，UI响应不受影响；但每个事件都启动一个新协程，会有轻微的创建开销。
• 可靠性：较高。send是挂起函数，协程会挂起直到Flow缓冲区有空间，事件不会丢失（除非Flow被取消）。
• 资源占用：高于前两种。协程本身开销很小，但如果是高频触发的事件（比如鼠标移动、滚动），大量协程创建会累积出可观的资源消耗。

关于actionEvents4的疑问：是否要避免为每个事件启动协程？ #

分场景判断：

• 如果是低频事件（比如按钮点击、菜单选择）：完全没必要避免，协程的创建开销可以忽略不计，这种写法简单直观，可靠性也有保障。
• 如果是高频事件（比如鼠标拖拽、实时输入）：建议优化。可以改用固定协程来批量处理事件，比如在callbackFlow内部启动一个常驻协程，用Channel接收事件后统一发送到Flow，避免重复创建协程；或者改用trySend配合合适的缓冲区策略（比如buffer(Channel.UNLIMITED)或buffer(Channel.CONFLATED)），平衡可靠性和性能。

内容的提问来源于stack exchange，提问作者morisil