有许多解决方案适用于实现"用户空间"线程.无论是golang.org goroutines,python的绿色线程,C#的异步,erlang的进程等.这个想法是允许并发编程,即使是单个或有限数量的线程.
我不明白的是,为什么操作系统线程如此昂贵？正如我所看到的,无论哪种方式,你必须保存任务的堆栈(操作系统线程或用户空间线程),这是几十千字节,你需要一个调度程序在两个任务之间移动.
操作系统免费提供这两种功能.OS线程为什么要比"绿色"线程更昂贵？由于每个"任务"都有专用的OS线程,导致性能下降的原因是什么？
在这里提供一些背景信息，我一直在关注项目织机一段时间。我看过织机的状态。我做过异步编程。
异步编程（由 java nio 提供）在任务等待时将线程返回到线程池，并且它竭尽全力不阻塞线程。这带来了很大的性能提升，我们现在可以处理更多的请求，因为它们不受操作系统线程数量的直接限制。但我们在这里失去的是上下文。同一个任务现在不仅仅与一个线程相关联。一旦我们将任务与线程分离，所有上下文都将丢失。异常跟踪不提供非常有用的信息并且调试很困难。
随之而来的项目织机virtual threads成为单一的并发单元。现在您可以在单个virtual thread.
直到现在一切都很好，但文章继续指出，项目织机：
一个简单的、同步的 Web 服务器将能够处理更多的请求，而无需更多的硬件。
我不明白我们如何通过异步 API 的项目机获得性能优势？在asynchrounous APIs确保不要保留任何线程空闲。那么，项目织机如何使其比asynchronousAPI更高效和高性能？
让我重新表述这个问题。假设我们有一个 http 服务器，它接收请求并使用支持的持久数据库执行一些 crud 操作。比如说，这个 http 服务器处理了很多请求 - 100K RPM。两种实现方式：
virtual threads为每个请求生成。如果有IO，虚拟线程只是等待任务完成。然后返回 HTTP 响应。基本上，没有针对virtual threads.鉴于硬件和吞吐量保持不变，在响应时间或处理更多吞吐量方面，任何一种解决方案会比另一种更好吗？
我的猜测是，与性能没有任何区别。