使用JDK16支持的Loom虚拟线程的代价 – Webtide

21-01-03 banq

在本系列博客中,我们将研究OpenJDK 16早期访问版本中现在可用的Loom虚拟线程新功能。详细点击标题见原文,直接上结论:

Loom确实允许您有许多线程,甚至1,000,000个线程,但如果这些线程具有深堆栈,则不允许这样做。这似乎增加了堆栈条目的总内存使用量,并且还付出了长时间垃圾回收的代价。这些是对虚拟线程的重大限制,因此它们不是银弹,不是可以替代内核线程的解决方案。

Project Loom旨在极大地减少编写、维护和观察可充分利用可用硬件的高吞吐量并发应用程序的工作量。…问题在于,线程(即并发的软件单元)无法匹配应用程序域的自然并发单元(会话,HTTP请求或单个数据库操作)的规模。

Project Loom可以在JVM中添加廉价且快速的生成/阻塞虚拟线程,这是很好的。但是便宜的线程却会做昂贵的事情!

拥有1,000,000个并发应用程序实体将占用内存,CPU和其他资源,无论它们阻塞还是使用异步回调。正如Loom Structured Concurrency所建议的那样,Loom可能需要完全不同的编程风格,但是我们还没有看到任何对资源的限制,这些资源会限制虚拟线程的无限生成。也有迹象表明,Loom的灵活堆栈管理带来了CPU成本。

Loom有许多主张:阻​​塞代码更容易编写,虚拟线程的启动速度非常快且阻塞成本低。但是,这些关键主张要么没有成立,要么没有得到证实:我们不认为虚拟线程能够自然扩展,因为线程本身不是限制因素,而是由资源决定扩展。除非采取其他实质性的资源管理策略,否则如果建议人们“忘记线程池,只是产生一个新线程……”就是诱导人们创建一个不稳定应用程序。

 

                   

猜你喜欢