我正在尝试编写一个程序，该程序将并行执行可变数量的可能(但不一定)计算量大的任务。这些任务(Runnable 类型)将同时提交，一旦所有这些任务完成，线程池就应该关闭(换句话说，池只需要接受初始任务，仅此而已)。
在我在此站点上找到的大多数答案中，问题是关于基于服务器的任务(我在一个像样的桌面上运行我的程序)或一个在不规则时间间隔内接受任务的池。在没有具体说明用途的问题中，答案通常是“视情况而定”。
我对线程的经验基本上为零，所以我真的不知道最佳的“线程数与任务强度”的比率是多少。
就上下文而言，我正在处理的程序处理矩阵集合(由 3D 数组表示)，其中每个矩阵最多可包含 1000x1000 个元素。其中一项任务可能是执行卷积运算，每个任务都是对集合中的一个矩阵的运算。
是否有针对此类特定问题的建议？
最佳答案
当有人向服务器询问该问题时，您会听到同样的情况:不要做出假设，而要进行实验。
尝试确定(最坏情况:猜测)您的用户在其上运行您的软件的典型硬件设置。然后确保您可以很好地进行自动化性能测试。然后看看会发生什么。
但事实是:这不会有太大帮助。你看，当你运行自己的服务器时，你(希望)可以控制这些机器所忙于的工作量。对于桌面设置，远程用户在他们的盒子上运行您的代码......您对那里运行的其他内容的了解零。您可能会发现 16 个线程适合 50% 的用户。但其他人可能正在他们的机器上做很多其他事情，而 16 对他们来说已经太多了。
这才是真正的症结所在。无论您发现特定硬件配置的“好用”数量是多少，您都无法控制其他 工作负载。
从这个角度来看，我会相当保守。对于 CPU 密集型工作负载，“太多”线程无论如何都无济于事，因此请以 CPU 数量或更好的内核数量为起点。
除此之外，这里可能真正有用的是:向您的应用程序添加某种“数据收集”。意思是:让它定期打电话回家，告诉你类似这样的事情:“这是我正在运行的硬件，我正在使用 X 线程，系统上的其他工作负载是 Y”。这可能会帮助您获得一些启发式方法，以适应最重要的用户设置。但要注意收集什么数据。预先定义您希望得到回答的问题，然后提取回答这些问题所需的数据。
关于java - 一次提交多个相关任务的线程池的推荐大小，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/56432685/