为什么JAVA需要协程和虚拟线程?

在
JEP 425: Virtual Threads (Preview) 文章种介绍了JAVA 虚拟线程。现在包括C++，JS,C#，python，go 等语言种都添加了协程支持。

为什么我们需要协程和虚拟线程？

主要是在优化 IO密集型服务时需要创建大量线程会导致内存占用过多，还有CPU 调度线程上下文切换时间较长。
在传统的IO模型中，每个连接创建成功之后都需要由一个线程来维护，每个线程都包含一个while死循环，那么1万个连接对应1万个线程，继而有1万个while死循环，这就带来如下几个问题。

线程资源受限：线程是操作系统中非常宝贵的资源，同一时刻有大量的线程处于阻塞状态，是非常严重的资源浪费，操作系统耗不起。

线程切换效率低下：单机CPU核数固定，线程爆炸之后操作系统频繁进行线程切换，应用性能急剧下降。

虽然现代服务器可以支持的打开套接字的数量可能约为一百万甚至更多，但您不能拥有一百万个线程。因此，如果您可以说 2,000 个线程或 4,000 或 5,000 个线程，这就是您可以同时处理的最大请求数，即使您的服务器可以假设同时支持一百万个请求，因为您最多可以有一百万个请求打开socket。

Java 线程只是操作系统线程的薄包装，而操作系统线程是非常宝贵的资源。由于各种原因，现代操作系统一次不能支持超过几千个活动线程。因此，如果这是您想要编写的编程风格，那么您会受到线程数量的限制。

我们不会在同一个线程上从头到尾处理整个请求，而是我们要做一些处理，将线程返回到池中以供其他事务使用。然后假设我们向微服务发送一个传出请求。当response回来时，我们可能会在另一个线程中继续它。这种编程风格称为异步编程。

这解决了吞吐量问题。因此，通过反应式编程，您可以获得硬件支持的最大吞吐量，但是您编写程序的方式与平台的设计并不协调，因为 Java 平台的一切都是围绕线程构建的。如果您有异常，您获得的故障排除上下文是线程堆栈。一旦你使用了那些响应式框架，你得到的线程堆栈实际上并没有任何有价值的信息，任何有用的信息，因为同一个任务真的从一个线程移动到另一个线程。您无法在调试器中单步执行这些请求或那些事务，因为调试器单步执行单个线程上的操作。但是，如果您使用异步编程，您的操作实际上会从一个线程移动到另一个线程，并且您可以 t 使用 JFL 等分析器获取可操作的配置文件，因为它们按线程对操作进行分组。他们不知道这些异步事务。

从 Java 程序员的角度或从 Java 程序员的角度来看，当他们坐下来编写代码并运行它时，虚拟线程就是线程。它们是 Java 线程。语义在所有方面都完全相同，但在幕后，与我们已经开始调用平台线程的今天的线程不同，它们不会一对一地映射到 OS 线程。因此，虚拟线程不是操作系统线程的包装器。相反，它是操作系统不知道的 Java 运行时构造。

在幕后，运行时，库和 VM 将大量虚拟线程（甚至数百万）映射到非常小的 OS 线程集。所以从操作系统的角度来看，你的程序可能正在运行，我不知道，8 个或 32 个线程，但从你的角度来看，你将运行一百万个线程，这些线程将是虚拟的。virtual 这个名字应该唤起与虚拟内存相同的内涵和关联，在那里你有一些抽象的、廉价的、无限的资源，如虚拟内存或虚拟线程，然后自动巧妙地映射到一些更有限的物理资源，如 RAM 或操作系统线程。

线程局部变量。一旦你在一个池中共享线程，你必须非常非常小心，如果你使用线程局部变量，你可能会这样做，因为你使用的库，比如如果你使用一些日志库，它们使用线程局部变量。本地线程不与任务相关联，而是与线程相关联。因此，如果线程在许多任务之间共享并且您不小心，您的线程本地可能会从一个线程泄漏到另一个线程。事实上，这可能是一个安全问题。您可以将秘密从一个用户泄露给另一个用户。

• 大量线程调试仍然具有挑战性，Loom 项目团队正在与各种 IDE 供应商合作研究如何呈现大量线程。
• java project Loom 支持可插拔的调度器，允许开发人员试验不同的调度算法；默认调度程序使用基于工作窃取算法的 fork/join。在未来（发布第一个 GA 版本），团队可能会考虑添加显式的尾调用优化。

更多文章请阅读:
关于协程的文章集合

Java’s Project Loom, Virtual Threads and Structured Concurrency with Ron Pressler

JEP咖啡屋11[熟肉]-虚拟线程

虚拟线程：大规模 Java 应用的新基石