Erh*_*nis 3 java multithreading limit java-threads
因此，根据我在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。但是，我确实增加了ifrom 100 * 1000to 的上限1000 * 1000，因为它成功创建了所有线程。它在计算机冻结之前发出的最后一条消息是440,000 threads: Time to create 4,000 threads was 1.002 seconds- 不过，它看起来平均每 4000 秒大约 2 秒。
我使用的是 Windows 10 Pro，版本 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年是否悄然发生了变化？（甚至在过去几个月中：我引用的其中一个帖子是在几个月前，即 2018 年 4 月发布的。）
穿线系统在过去10年是否悄然发生了变化？
不。在 Linux、MacOS 和 Windows 上，Java 线程被实现为本地线程......很久以前。
改变的是各种不同的操作系统调度本机线程的方式。操作系统是 Java 线程调度发生的地方，并且对支持的线程数量进行任何硬性限制。
基本上，您的测试试图查看当您尝试使用病态的大量线程时会发生什么。Windows 上的答案是它破坏了操作系统。
即使它没有彻底破坏操作系统，对于使用 100,000 个线程的 Java 应用程序来说，也有可能：
大量线程是编写实际 Java 应用程序的错误方法。Actors 可能是更好的解决方案，也可能是 ExecutorService（带有有限线程池）或 ForkJoin 池。这将取决于应用程序和其他因素。
简而言之，您正在运行的那些测试对于正确设计的 Java 应用程序没有指导意义。使用大量线程的应用程序的解决方案是重写它们。