JVM 上的协程，真香

你是用的什么框架，Quasar 还是 kilim ？

发图不留种, xxxxx

@HsingChih Kotlin + Vertx，前几日发布的 vertx 3.6，为所有异步方法自动合成了 suspend function，不用再写 await 了

然而 go 的协程资源成本低很多

有时候一个类库解决的问题非要用另外一种语言...

现在都不写 Java 的吗？后端有开始用 Kotlin 的吗。

coroutine 是单线程吗？ goroutine 可以利用多核吗？小白不懂求教

@lihongjie0209 Kotlin：不仅仅是协程

@keepeye 都可以选

@WispZhan go 是 stackful 协程，kotlin 是 stackless 协程，一个 kotlin 协程内存占用还不到 1KB，go 每个协程要 2KB。
@lihongjie0209 一年前换了 Kotlin，协程是今天才上的。并非因为一个库换的语言。
@keepeye 线程数可以自己决定，vertx 部署了几个 instance 就有几个线程。
@qiyuey Kotlin 值得拥有。

借地广告下自己撸的 coroutine 轮子，现在还处于玩具阶段，但是功能是完备的
https://github.com/GuuJiang/Jacob

没 kotlin，直接用 webflux 的响应式编程也不错

换言之，go 用这种同步风格的东西已经六七年了，而且一直都很稳定，不用你改代码
vert.x 遗留代码就会比较多吧，我猜。

@lhx2008 webflux 的问题在于链式调用过于复杂，可读性太低

@sagaxu 受教了，看来之前对 kotlin 和协程了解还是不深。

@keepeye goroutine 不是简单的协程，可以高效利用多核

有代码实例吗

@GuuJiang 应该不是完整实现吧？看代码量并不大啊。

马克

诶呀终于有这个功能了
@sagaxu

c#用了多少年了, 你们才后知后觉. 还一直嘲笑 c#糖多太甜

c++早就用上了（

Kotlin 的 coroutine 还是和 go 的 goroutine 使用场景上不一样的。coroutine 本质上是调度，一些该 block 的操作还是 block 的。如果需要继续提升更高的性能，还是需要做 go 底层类似的异步转同步优化。这样改下来性能应该会比 go 更高。

另外支持 Kotlin 干死 Java，嗯嗯

@sagaxu 之前看 so 上 kotlin coroutines 作者解释过，kt 也是 stackful 的

@keepeye
@sagaxu

kt + vertx 的情况下，kt 的协程是依靠 vertx 的线程池来调度的，然后 vertx 的一个实例还有 context 线程池和一个 worker 线程池，正常的代码都在 context 线程池上跑，包括协程也是。worker 线程池是在 executeBlocking 的时候用到的。这两个线程池默认好像是 4+8 吧。

@garfeildma 你可能记错了，Kotlin 的协程实现是 continuation-passing style，内部是个状态机。
简介可以看他们 teamleader 的 ppt
https://www.slideshare.net/elizarov/introduction-to-kotlin-coroutines


@Tyanboot vertx 一个 instance 对应一个线程，线程数开到 4，如果 instance 小于 4，比如是 1，只能占用一个 CPU 核心。

@taowen putty 代码里就有 coroutine 的状态机实现，其实用不了几行代码。

@reus 如果都是 vertx 代码还好，可以无缝的跟协程一起用，海量的多线程阻塞代码是个问题。

@sagaxu 协程的通病了，和现有使用系统线程的多线程程序不容易配合。go 就没有这个问题，因为从一开始大家都是用 goroutine 的

听说 Java 现在内部也在实现协程，估计在日后的某个 JDK 版本内就有了

kotlin 才是现代语言。go 实在是有点原始，写个“列表中是否包含某个元素”都要写个 util。由于不支持泛型，每个类又要写一遍。

@reus goroutine 用底层 hack 的方式调度, 坑太多了, 时不是要注意调度问题. 像 c#一样全库异步化才是出路

@loqixh 例如什么坑？ C#没有出路，过去没有，现在没有，以后也不会有。

stackless 的协程现在变成了优势了。。？

@reus 我觉得技术上的出路和普及度上的出路要分开看。Java 继续作死 C#未必没有机会，Service Mesh 也是个翻身的机会

@youngxhui loom 进 jvm 并且能用于生产环境，至少要到 java 17 了
@fan123199 go2 一两年内应该能出来了，go 是现代 c 语言，不是现代语言
@2225377fjs stackless 和 stackful 各有优劣，stackless 胜在轻量，轻到可以用它做 generator，但是调用开销比 stackful 稍大。
@Narcissu5 C#有没有机会，就看 flag 和 bat 用的多不多，未来十年大部分互联网公司的技术骨干，多半是这些大厂输出的。

@sagaxu 主要是对 stackless 和 stackful 没有一个明确的定义，可以看看这个答案下边 Roman 的回复 https://stackoverflow.com/a/43023289/220029

@youngxhui Project Loom 吧，原来 Quasar 的作者在负责，不过听说阿里的 JDK 里边已经内置协程了

go 里一个关键词搞定的事情，java 要写一个类；是不是有线程伪装的协程都要存个疑

@reus 多用点你就知道了, go 我也是写个几个玩具的, 具体懒得说

@garfeildma Roman 这个回复里，stack*的定义是指 suspend 协程的时候，是否可以处于嵌套的调用栈中，是一种能力的描述，不是实现方式的描述。

我们所说的 stack 否，是指创建协程的时候，会不会给这个协程创建一个专属的 stackframe。这是实现方式的描述，不是能力描述。

coroutine 比多线程好用

@slince Kotlin 是通过扩展方法实现的，可以达到关键字的简便程度，同时避免了额外的关键字定义，至于你说的 Class 那个是 Java 的事情，不是 Kotlin 的

@loqixh 切，我用了五六年了

协程又流行起来啦，看来不喜欢异步 API 的人挺多的。
分享个自己撸的 C/C++协程

https://github.com/heiher/hev-task-system

@reus 上面这位明显是菜鸡，别人说坑，他就说坑，问他啥坑，又不知道。。。