如果java虚拟线程稳定了，是不是有一大批框架和工具要重写？

知乎上有一个提问，“如果java虚拟线程稳定了，是不是有一大批框架和工具要重写？”，我整理了下我的知乎回答：

首先，抛开虚拟线程、协程，我们看看现在的架构。

在顶层，开辟出很多调度单位（线程、协程）；在底层，有很多的IO原语（accept、read、write）；在中间，有很多的组织逻辑。

协程主要做的就是，在底层执行IO原语的时候，暂时保存上下文，等执行结束后，再恢复上下文继续执行。

那么在现有的协程实现方案上，就出现了两种模式：

有栈协程，就是协程上下文包括了callstack，当IO完成、恢复上下的时候，连带着callstack恢复。那么对于callstack中的各个caller（调用者）和callee（被调用者），都感知不到整个协程的调用过程，自然代码就不用修改了。

有栈协程的优点就是不需要现有的代码改动太多，只需要调度单位创建+调度器+IO操作方面改动即可。但开发者的把控就比较弱，不能干涉调度过程。

Go和Java的Loom，都是有栈协程。

无栈协程，就是协程上下问不包含callstack，恢复上下文的时候，也只是通知上下文完成了。接下来干什么事情，还是得重新构建callstack。

比如 A -> B -> C -> IO函数，当出现IO调用，需要保留上下文，那么就需要C->B->A逐个返回上下文，恢复的时候也是 A -> B ->C去恢复执行。

无栈协程的优点就是开发者可以完全掌控执行、调度过程（比如我IO结束后，就不需要恢复callstack）、实现起来也比较贴近底层、性能上限会稍微高一点，但缺点也显而易见，很多代码需要改动、开发者的负担较重（有多少次不知道应该await还是直接return呢，尤其是在弱类型的情况下）。

JS、Python的async/await，Rust的异步，都是无栈协程。

结论：

Java 的 Virtual Thread 是有栈协程，能够保存上下文；随着 Virtual Thread 的普及，new线程的地方需要重写（比如需要改成new Vritual Thread）；而其他地方，比如中间的业务逻辑、底层的IO操作，都不需要重写也能正常工作。

业务几乎不用任何修改就能享受 Virtual Thread 带来的性能提升。