@
dreamlike 虚拟线程核心就是提供一个替代线程的模型吧(线程是“通用”操作系统的任务承载体,这个调度机制要支持很多特性包括一些统计,而这其中大部分都是不需要的就是太重了,除了带来不必要的元数据占用内存空间,还有这些数据的保存变更逻辑就是上下文切换,而且涉及影响其他进程还需要陷入内核模式执行),线程池解决占多余内存的问题,阻塞会导致并行度丢失于是需要引入并行度补偿机制,但在阻塞密集的时候又创建了太多 worker thread 又趋近于 thread per task 了,解决办法就是(在需要进行上下文切换的地方,就是阻塞 /等待,内在逻辑也是注册回调条件成熟唤醒)用更加轻量级的上下文切换替代线程的,就是虚拟线程的,或者额外搞一种支持注册回调并会 poll 唤醒的机制直接摊牌不阻塞了拆成有依赖关系的多个分支任务(上下文丢失除非又保存,当然可以做得比较灵活在调试时才开启,真实性能差距不得而知)。
JDK 中应该只会在确定当前任务的承载体是虚拟线程时在切换的时候才会进行虚拟线程的上下文切换(而不是线程的上下文切换)。问题来了,kt corotinue 中的代码,能有阻塞(真正意义上的,能调试的那种)的逻辑吗,如果有,发生的上下文切换,还是线程的上下文切换吧。