java - FixedThreadPool 不够并行

Question

我使用 forPool = Executors.newFixedThreadPool(poolSize); 创建了一个固定线程池，其中 poolSize 被初始化为处理器上的核心数(比如说 4)。在某些运行中，它运行良好并且 CPU 利用率始终保持在 400%。

但有时，使用率会下降到 100%，并且永远不会回升到 400%。我安排了 1000 多个任务，所以问题不在于此。我捕获了每个异常，但没有抛出异常。所以这个问题是随机的，不可重现，但非常普遍。它们是数据并行操作。在每个线程的末尾，都有一个同步访问来更新单个变量。我不太可能在那里陷入僵局。事实上，一旦我发现这个问题，如果我破坏池，并创建一个新的大小为 4 的池，它仍然只有 100% 使用率。没有 I/O。

这似乎违反了 java 对“FixedThreadPool”的保证。我读错了保证吗？是否只保证并发性而不保证并行性？

关于这个问题 - 您是否遇到并解决了这个问题？如果我想要并行性，我做的是否正确？

谢谢!

关于线程转储:我发现有 4 个线程都在进行并行操作。但使用率仍然只有 ~100%。这是 400% usage 处的线程转储和 100% usage .我将线程数设置为 16 以触发场景。它以 400% 运行一段时间，然后下降到 100%。当我使用 4 个线程时，它以 400% 的速度运行并且很少下降到 100%。 This是并行化代码。

****** [重大更新] ******

事实证明，如果我给 JVM 大量的内存来玩，这个问题就解决了，性能也不会下降。但我不知道如何使用这些信息来解决这个问题。帮助!

Answer 1

鉴于增加堆大小会使问题“消失”(可能不会永久消失)这一事实，该问题可能与 GC 有关。

Operation 实现是否有可能在调用之间生成一些状态，这些状态存储在堆上

pOperation.perform(...);

?如果是这样，那么您可能遇到了内存使用问题，也许是泄漏。随着更多任务的完成，堆上的数据也会越来越多。垃圾收集器必须越来越努力地尝试并尽可能多地回收，逐渐占用您总可用 CPU 资源的 75%。即使销毁 ThreadPool 也无济于事，因为那不是存储引用的地方，而是在操作中。

16 线程案例更多地遇到这个问题可能是因为它更快地生成更多状态(不知道 Operation 实现，所以我很难说)。

在保持问题设置不变的同时增加堆大小会使这个问题看起来消失，因为您有更多空间容纳所有这些状态。