为了提供一些背景信息,我已经关注Project Loom有一段时间了。我阅读过Loom的现状,并且已经进行了异步编程。
Java NIO提供的异步编程会在任务等待时将线程返回到线程池,并尽力避免阻塞线程。这带来了很大的性能提升,我们现在可以处理更多的请求,因为它们不直接受操作系统线程数量的限制。但是我们在这里失去的是上下文。一旦我们将任务与线程分离,同一任务就不再与一个线程相关联。异常跟踪没有提供非常有用的信息,调试也变得困难。
这就是Project Loom引入了虚拟线程作为并发的单个单位的原因。现在,您可以在单个虚拟线程上执行一个单个任务。
到目前为止都还好,但文章继续声明,使用Project Loom:
一个简单的同步Web服务器将能够处理更多的请求而无需更多的硬件。
我不明白我们如何通过Project Loom获得比异步API更好的性能?异步API确保不会让任何线程空闲。那么,Project Loom做了什么使它比异步API更高效和更具性能?
编辑
让我重新表述这个问题。假设我们有一个HTTP服务器,它接收请求,并与持久化数据库进行一些crud操作。假设,该HTTP服务器处理了很多请求 - 100K RPM。有两种实现方式:- HTTP服务器具有专用线程池。当请求到达时,线程执行任务,直到任务传递到数据库,此时任务必须等待来自数据库的响应。此时,线程返回到线程池,并继续执行其他任务。当数据库响应时,由线程池中的某个线程处理,并返回HTTP响应。
- HTTP服务器为每个请求生成虚拟线程。如果有IO,则虚拟线程只需等待任务完成即可。然后返回HTTP响应。基本上,对于虚拟线程没有池业务正在进行。