在本系列博客中，我们将研究OpenJDK 16早期访问版本中现在可用的Loom虚拟线程新功能。详细点击标题见原文，直接上结论：
Loom确实允许您有许多线程，甚至1,000,000个线程，但如果这些线程具有深堆栈，则不允许这样做。这似乎增加了堆栈条目的总内存使用量，并且还付出了长时间垃圾回收的代价。这些是对虚拟线程的重大限制，因此它们不是银弹，不是可以替代内核线程的解决方案。
Project Loom旨在极大地减少编写、维护和观察可充分利用可用硬件的高吞吐量并发应用程序的工作量。…问题在于，线程（即并发的软件单元）无法匹配应用程序域的自然并发单元（会话，HTTP请求或单个数据库操作）的规模。
Project Loom可以在JVM中添加廉价且快速的生成/阻塞虚拟线程，这是很好的。但是便宜的线程却会做昂贵的事情！
拥有1,000,000个并发应用程序实体将占用内存，CPU和其他资源，无论它们阻塞还是使用异步回调。正如Loom Structured Concurrency所建议的那样，Loom可能需要完全不同的编程风格，但是我们还没有看到任何对资源的限制，这些资源会限制虚拟线程的无限生成。也有迹象表明，Loom的灵活堆栈管理带来了CPU成本。
Loom有许多主张：阻塞代码更容易编写，虚拟线程的启动速度非常快且阻塞成本低。但是，这些关键主张要么没有成立，要么没有得到证实：我们不认为虚拟线程能够自然扩展，因为线程本身不是限制因素，而是由资源决定扩展。除非采取其他实质性的资源管理策略，否则如果建议人们“忘记线程池，只是产生一个新线程……”就是诱导人们创建一个不稳定应用程序。