Goroutine / Coroutine / Virtual Thread / Async-Await ... 名词一大堆，大家的共同点，都是提供比 OS thread 更轻量的并发执行上下文管理。提供这个设施的主要原因，无非是为了解决写复杂回调代码时的心智负担。

内存占用差异，本质上就是这些实现在 stack 实现上的选择，大致有 2 类，
stackful ，Goroutine 这种跑上来就分配 2KB/4KB 的栈，1M 并发时内存就要 2G/4G
stackless ，async-await 方案大都如此，因为无栈，内存占用往往有很大优势


把这两种方案放在一起 PK 内存占用，stackful 天然吃亏。Java virtual thread 本质上也是 stackful ，只不过很取巧的使用了可变尺寸栈，JVM 可以动态调整栈大小，不需要一开始就分配的很大。

stackful 和 stackless 都是上个世纪的理论了，这些语言的设计者们不可能对此不精通。那为何没有一边倒的选择某种方案？显然是两种方案各有利弊。我不谈底层实现差异（主要是不懂），也不谈哪个更强（于我都够用），仅从使用者的角度谈一下感受。

一，函数颜色问题。很多协程的实现，会把所有 IO 函数分成两类，一类会阻塞线程，另一类会挂起让出线程，两者之间往往不能互相调用，Kotlin 的 suspend 关键字就是给函数打标记用的，有些语言用 async 来标记也是一样的。使用这类语言的时候，我们需要清楚的了解调用的方法是不是能用于协程，使用第三方库甚至标准库的时候，也要小心翼翼，一旦弄错后果非常严重。

二，是否抢占式调度。非抢占式调度，需要使用者自己主动交出资源，很多实现提供了 yield 方法/关键字，避免大循环独占线程太久饿死其它协程。

Virtual thread(JVM)和 Goroutine 很好的解决了这两个问题，在集成第三方库的时候，基本上(当前版本 JVM 不能 100%做到)不用考虑会不会阻塞线程的问题，牺牲点内存提高开发效率，是好事还是坏事，没有定论，这要看具体的场景。

理想中的协程应该是这样的，
1. 足够轻量，fire and forget ，不需要 pool ，即便 pool 化了收益也很小
2. 函数不分类，不存在不能用于协程上下文的函数
3. 抢占式调度

但这 3 点根本无法同时实现，Go 和 JVM 都选择了 2 和 3 ，Go 在 2 上面做的最好，毕竟你想写出点阻塞 OS thread 的代码还要动点脑筋。JVM 在 1 上优化的比 Go 好，Java 官方文档敢写“Represent Every Concurrent Task as a Virtual Thread; Never Pool Virtual Threads”。

题外话，有了很轻的协程，就可以肆无忌惮的开了吗？并不是，DB 扛不住啊，所以像 Kotlin 这种 1G 内存能开 2M 个协程的语言，也特地提供 limitedParallelism 控制协程的并发度。这是调度层面做的，不一定要用协程池的方式来做。

@lesismal 66#

However, when code running in a virtual thread calls a blocking I/O operation, the Java runtime suspends the virtual thread until it can be resumed. The OS thread associated with the suspended virtual thread is now free to perform operations for other virtual threads.

Java 的 virtual thread 就是为了解决传统线程阻塞时不能让出 CPU 资源提出的方案，如果请求 SQL 就卡住线程了，那就不需要在 JVM 层面提供支持了，完全可以像 Kotlin 一样从 lib 层面支持，调用者自己确保不会阻塞。

大 A 最大的优点就是稳，3000 左右好多年了，总能有低价捡漏的机会。
跌入 2950 开始分批进场，3000 点以上陆续出货。
上证指数 ETF 还是有分红的，去年分红三次，其中有一次高达 5%。

如果你不贪心，资金量也不大(千万以下)，只追求年化 10%左右的收益，即便大 A 也很容易。

import kotlinx.coroutines.delay
import kotlinx.coroutines.launch
import kotlinx.coroutines.runBlocking


fun main(args: Array<String>) {
println("stated")
runBlocking {
val numTasks: Int = args[0].toInt()
for (i in 1..numTasks) {
launch { delay(30_000) }
}
println("launched")
}
println("finished")
}

Kotlin + OpenJDK 21 ，1M 个协程 488M 内存(RSS)

市场化国企
湖北三四线城市
税前 6
单休

全是缺点，这种国企在大环境低迷时期，没有任何稳定性可言

等你年龄再稍微大点，平均投 100 家都没一个面试

举证只能证“有”，并不能证“无”

@xiaomushen

以前发的多也只是苏州等少数几个地方，江苏大部分地方最高的时期也就十几万，第一轮降薪之后基层只剩十来万了，这轮之后恐怕不到 10 万了。

还在想明降暗升那套？以前是政策需要，现在是真的没钱，交警工商税务办法多，但没有创收能力的部门补不了。

如果企业利润和财政收入继续下行，江浙体制内也要欠薪，那些靠转移支付维持运转的地方就要崩盘了。

江苏公务员已经启动第二轮降薪了，大环境别说是好转，连维持现状都不可能

这题我会，房贷早已还清，还有房租收，除了孩子兴趣班就是吃喝玩乐，大头理财，零头炒股，2022 疫情之后基本上没什么购物欲望了，啥也不想买

我做短线指数，8 月份起每一笔都是赚的，只要保持在 3500 以下震荡，就能一直赚下去，超过 3500 反而不好办了。

我有个朋友副业是摄影，没钱途，很多小姑娘没钱只能肉偿，赚不到现金，也不能转卖

@BeforeTooLate 全国 Top3 的相关科室就在我家门口，去过无数次了

@BeforeTooLate
@JunNKG
不吃中药也不吃保健品，脂肪肝倒是有，熬夜也是因素，但是这两个因素一般不会导致 300 这么高。往上两代直系亲属也有这个问题，也是查不到原因，他们年龄大了之后才异常，我 20 出头就异常了。

我已经 300 多十几年了，查不出任何原因

这不是外包的问题，是你自己不懂得拒绝

在 WebFlux ，Vert.x ，Quarkus 三个响应式框架中做过选择，最终选择了 Vert.x 。

三个都有回调地域的心智负担，当循环+分支+递归时，响应式写法要炸，WebFlux 还是这三个里性能最弱鸡的。

Quarkus 很好，但美中不足的是不支持 reproducible builds ，官方也很不以为意，四五年不解决，所以也放弃了
https://github.com/quarkusio/quarkus/issues/676

Vert.x 非常符合要求，高性能 + 框架简单 + 支持 native image + 支持 Java virtual threads + 支持 Kotlin Coroutine ，为了方便协程式同步写法，早年折腾出 vertx-sync ，后来用上了 quasar ，在 Kotlin 和 Java 的协程出来后也是立马就支持了。