Java 线程限制，JVM 9

Question

所以根据most我的东西read在 internet 上，您可以在 Java 中拥有的线程数大约 10,000。但是，实际上我可以创建近 500,000 个，此时我的计算机变得无响应。 (任务管理器有点搞笑——它开始声称虽然我的 16 GB 内存中有 99% 已被使用，但使用率最高的程序仅使用了约 300 MB。在一切停止响应后，风扇安静下来，磁盘访问指示灯只是周期性地闪烁，让我相信 CPU 和磁盘都没有承受重负载。)我在一次测试中等待了大约 15 分钟，但从未出现异常(嗯，据我所知)。

为了可重复性，我(也)使用了以下代码:https://github.com/jheusser/core-java-performance-examples/blob/master/src/test/java/com/google/code/java/core/threads/MaxThreadsMain.java如此处所引用:https://dzone.com/articles/java-what-limit-number-threads . 但是，我确实将 i 的上限从 100 * 1000 增加到 1000 * 1000，因为它已成功创建所有线程。它在计算机死机之前发出的最后一条消息是 440,000 个线程:创建 4,000 个线程的时间为 1.002 秒 - 不过看起来它平均每 4000 个线程大约需要 2 秒。

我使用的是 Windows 10 专业版，版本 1703。 JRE:Java HotSpot(TM) 64 位服务器 VM(构建 9.0.4+11，混合模式)

据我所知，第二高的线程数约为 100k，https://stackoverflow.com/a/46697264/513038 .现在，许多声称的限制是多年前给出的，但它们是基于堆栈大小与内存的关系，并且在 16 GB RAM 中有 500,000 个线程(即使假设所有线程都被使用)，默认情况下每个线程 32kb，这应该小于最小堆栈大小。如果那是真的，我至少会期望在正常操作期间出现更多 StackOverflowErrors。线程系统是否在过去的 10 年里悄无声息地发生了变化？ (或者甚至在过去几个月:one of the posts 我提到的是几个月前，2018 年 4 月制作的。)

Answer 1

Has the threading system changed silently in the past 10 years?

没有。在 Linux、MacOS 和 Windows 上，Java 线程作为 native 线程实现……很久以前。

发生变化的是各种不同的操作系统调度 native 线程的方式。操作系统是 Java 线程调度发生的地方，并且将强制执行对支持的线程数量的任何硬性限制。

基本上，您的测试会尝试查看当您尝试使用病态的大量线程时会发生什么。 Windows 上的答案是它会破坏操作系统。

即使它没有彻底破坏操作系统，对于使用 100,000 个线程的 Java 应用程序来说，也有可能:

• JVM 的资源使用(堆栈内存)会很糟糕，
• native 调度程序的性能会很糟糕，而且
• 应用程序性能会很糟糕。

大量线程是编写实际 Java 应用程序的错误方法。 Actor 可能是更好的解决方案，或者 ExecutorService(具有有界线程池)或 ForkJoin 池。这将取决于应用程序和其他因素。

简而言之，您正在运行的那些测试对于正确设计的 Java 应用程序没有指导意义。使用大量线程的应用程序的解决方案是重写它们。