.NET 平台上的green thread 异步模型实验结果最近出来了，具体参见：https://github.com/dotnet/runtimelab/issues/2398 ，实验结果总结一下就是在.NET和 ASP.NET Core中实现Green Thread是可行的。Green Thread 在.NET运行时环境中的基本成本和好处，以及与异步编程模型的交互和挑战。如果引入了全新的异步编程模型，对于.NET开发人员来说，Green Thread 和现有异步模型async/await 之间的交互非常复杂。因此，决定暂停绿色线程试验，继续改进现有的async/await模型，以便在.NET中开发异步代码。
文章对为什么要进行Green thread的实验的总结一下就这么几点：
- .NET的异步编程模型简化了应用程序的异步代码编写，对于增强I/O绑定方案的可伸缩性非常关键。
- I/O绑定代码经常处于等待状态，如等待网络返回数据。异步代码提高了可伸缩性，显著降低了等待I/O的请求成本。
- 异步C#代码的优势是在等待I/O操作时的低成本，并且允许服务器并行处理大量请求。
- 但异步编码也有挑战，因为开发者需要确定哪些方法应该异步化。全面异步化不现实，因为异步方法有性能、类型限制，并且编程模型复杂。
- Green thread的目的是简化编程模型，使得所有代码可以以同步方式编写，但仍保持可伸缩性和性能。
- Green thread在其他编程环境中已经被验证为有效，现在的考虑是它是否适用于C#，特别是考虑到存在的async/await模型。
文章里也对搁置Green thread的结论总结几点：
- Green thread为.NET开发人员提供了一个全新的异步编程模型。asp. net core benchmark 显示 green thread 性能不如现有的 async/await，async/await 达到 178,620 rps 的同时 green thread 只达到了 162,019 rps， .NET 平台是目前为止唯一一个同时实现了Green Thread 和async/await 异步模型的平台，这就让我们有了一个横向比较两种编程模型的平台，这也就破案了在社区中 异步编程模型哪个更快的争论，这里有个非常好的面试题就说 golang，nodejs，java等等他们实现的异步编程模型分别是哪一种，他们有什么优缺点等。
- Green thread与现有的异步模型之间的交互是复杂的。特别是从Green thread代码调用异步方法需要转换到异步代码的同步模式，这在常规线程上不是一个好的选择。micro benchmark 显示深 green thread 调用栈的性能远不如深 async/await 调用链。
- 在Green thread模型中，与本机代码的互操作性是复杂和相对较慢的。基于P/Invoke的基准测试显示，Green thread上的操作成本明显增加。100,000,000 次 P/Invoke 从原来的 300ms 变成需要 1800ms。
- Green thread在与某些特定特性如线程局部静态变量和本机线程状态交互时存在功能上的问题。thread local 变量的支持以及暴露 native thread 状态变得非常难以实现。
- Green thread与某些安全缓解措施，如防止面向返回的编程的影子堆栈（ shadow stacks），的交互是具有挑战性的。
- 在某些关键场景中，Green thread模型的速度有可能超过异步，但这种性能提升的代价是其他场景下的性能下降，以及需要放弃一些兼容性和特性。
- 一个未解之谜是，通过优化异步，是否可以让Green thread在性能上超过异步。
- 开发团队发现以上问题在其它使用 green thread 的语言中同样存在。
文章后面的讨论值得看一看，其中rcollette 的观点特别有意思：https://github.com/dotnet/runtimelab/issues/2398#issuecomment-1713003525