已废弃的Green Threads与Project Loom的核心区别是什么？

你观察到的“多路复用到原生线程”只是表面相似，两者的核心设计和解决的问题完全不同，关键区别体现在这几个方面：

• 调度机制的智能化
  早期Green Threads由JVM完全控制调度，OS对其毫无感知。一旦某个Green Thread执行阻塞IO操作，绑定的整个OS线程都会被挂起，根本无法利用CPU处理其他任务，资源浪费严重。而Loom的虚拟线程采用协作式调度+内核感知：当虚拟线程遇到可预见的阻塞（比如文件IO、网络请求、锁等待）时，JVM会主动把它从载体OS线程上卸载，让OS线程去运行其他虚拟线程；如果遇到无法协作的阻塞（比如调用本地方法），JVM会自动临时分配新的OS线程来处理，避免阻塞整个线程池。

• 完全兼容现有线程API
  Green Threads是一套独立于Java标准Thread模型的实现，和后来的OS线程模型兼容性极差，这也是它被废弃的重要原因。而Loom的虚拟线程是Thread接口的原生实现，你可以用Thread.ofVirtual().start()创建虚拟线程，也能直接替换现有代码里的new Thread()，业务逻辑完全不需要修改——虚拟线程对上层代码几乎是透明的。

• 与OS系统的深度协同
  Green Threads完全脱离OS的线程管理体系，无法利用OS的优先级调度、资源隔离、信号处理等特性，也很难和原生程序交互。而虚拟线程和OS线程是协同工作的：JVM负责虚拟线程的调度，但底层的载体线程池由OS管理，JVM会根据系统负载动态调整载体线程数量；同时虚拟线程也能正常和OS的进程监控、调试工具集成，不像Green Threads那样是“黑盒”。

• 极致的性能与扩展性
  Green Threads诞生时很多OS还不支持多核CPU，JVM调度器效率也低，根本无法利用多核资源。而Loom是为多核时代设计的：JVM的调度器能高效地在多个载体线程之间分发虚拟线程，充分利用多核算力；同时虚拟线程的创建成本极低（初始栈内存仅几KB，还能动态扩容），系统可以轻松承载数百万个虚拟线程，这是Green Threads和原生OS线程都做不到的。

简单来说，Loom的虚拟线程不是回到Green Threads的老路子，而是在现代OS线程模型的基础上，解决了Green Threads的核心痛点，实现了用户态线程的高效、兼容、可扩展。

内容的提问来源于stack exchange，提问作者JavaNovice