【问题标题】:Is there any area where Threads should be favored over Coroutines?是否有任何领域线程应该比协程更受青睐?
【发布时间】:2018-02-28 21:43:11
【问题描述】:

我刚刚讲了 Kotlin 的 Coroutines,问题出现了 Coroutines 是否总是可以替代 Threads 或者是否也可能存在缺点。

反之亦然:有哪些领域不应该使用协程?

【问题讨论】:

  • 如果您在单线程上运行协程,那么对于非 IO 绑定的工作负载,您将受限于单线程性能。如果您通过跨多个线程运行协程来绕过此限制,那么您将回到线程:)
  • 协程在解决方案空间的一个特定角落很有用。多线程覆盖了解决方案空间的更大区域。需要多线程和协同程序的解决方案之间的重叠最少。

标签: multithreading kotlin coroutine kotlin-coroutines


【解决方案1】:

协程对于异步编程很有用。当您编写的代码大部分时间必须等待一些外部事件时,例如在现代连接的用户界面和面向微服务的后端应用程序中经常发生的情况,那么协程和 Kotlin 挂起函数的概念让您可以自然地编写看起来和易于理解的代码比具有显式线程的代码更具可扩展性。

如果您正在编写某种计算、CPU 密集型代码,那么您会发现多线程编程和并行的经典模式效果更好。

这并不意味着您不能使用协程来并行化某些 CPU 密集型应用程序,但这样做不会在代码可读性或其性能方面获得任何好处。

【讨论】:

  • 嘿罗曼!感谢协程,虽然我很难理解它们背后的魔力,这使得使用它们非常危险。一旦我理解了魔法——我当然会试一试。这只是一种反馈 :-) 我知道你已经在 Kotlin Conf 上讨论过这个话题。
  • 谢谢。看看我在 KotlinConf 发表的“深入了解协程”演讲。它提供了有关实现细节的足够信息以消除所有魔力:youtube.com/watch?v=YrrUCSi72E8
  • 还有一些中间立场:基于 DAG 的计算,其模型类似于 Actors。这是非常 CPU 密集型的,但是当他们的输出队列填满时,个别工作人员会被阻塞。然后你找另一个工人跑。如果有成百上千的工作线程,线程池中的协程的性能要好于原生线程。这是我们在 Hazelcast Jet 中使用的架构,我们已经将 Kotlin 协程作为原型应用于它(在生产中,我们有一个类似协程的 Java API)。 Kotlin 非常适合我们,100% 的 Java 性能!