跟踪java中的线程冲突

使用YourKit，我测量了一个应用程序，并确定了主CPU接收器。我构造了计算，通过一个具有固定线程数的ExecutorService来并行化它

在24核机器上，添加线程的好处在4核以上的速度非常快。所以，我想，这里一定有一些争用或锁定，或者IO延迟，或者别的什么

好的，我打开了YourKit的“监视使用情况”功能，工作线程中显示的阻塞时间很小。仔细查看线程状态图，工作线程几乎都是“绿色”（正在运行），而不是黄色（等待）或红色（阻塞）

CPU评测仍然在工作线程内部的调用树中显示96%的时间

所以有些东西正在耗尽实时性。这可能是调度开销吗

在伪代码中，您可以将其建模为：

loop over blobs:
    submit tasks for a blob via invokeAll of executor
    do some single-threaded processing on the results
end loop over blobs

在测试运行中，大约有680个blob，每个blob大约有13个任务。因此，每个线程（假设四个）对每个blob进行大约3次调度

硬件：我在MacBook pro上进行了小规模的测试，然后在linux上的大型Dell:hwinfo上报告了24个不同的项目--cpu，包括

Intel(R) Xeon(R) CPU           X5680  @ 3.33GHz

---

英特尔的网站告诉我，每个都有6个内核，12个线程，我怀疑我有4个。这很可能不是竞争，尽管很难说没有更多细节。分析结果可能会产生误导，因为Java报告线程在磁盘或网络I/O上被阻塞时是可运行的。Yourkit仍然将其计算为CPU时间

---

您最好的选择是打开CPU评测并深入了解工作线程中花费的时间。如果它最终主要出现在java.io类中，那么仍然存在磁盘或网络延迟。

您还没有完全并行化处理。在上一个blob的结果完成之前，您可能不会提交下一个blob，因此没有并行处理

如果可以，请尝试以下方法：

for each blob{

        create a runnable for blob process name it blobProcessor;
        create a runnable for blob results name it resultsProcessor;
        submit blobProcessor;
               before blobProcessor finishes, submit resultsProcessor;
}

此外：

---

请看一看时差，它使用光纤提供无线程并发。

假设您有4个内核，每个内核有8个逻辑线程，这意味着您有4个真正的处理单元，可以跨32个线程共享。这还意味着，当同一个内核上有2-8个活动线程时，它们必须争夺CPU管道、指令和数据缓存等资源

当您有许多线程必须等待外部资源（如磁盘或网络IO）时，这种方法最有效。如果您有CPU密集型进程，您可能会发现每个核心一个线程将使用您所有的CPU能力

我编写了一个库，它支持linux和windows的线程和内核分配。如果您有Solaris，它可能很容易移植，因为它支持JNI posix调用和JNA调用

---

由于invokeAll等待所有任务完成，任务是否可能大小不同？假设blob A有6个任务，但其中一个任务的时间是其他任务的5倍。对于1个线程，运行时间为10、2:5（5,1*5）、3:5（5,1x3,1x2）。因此，没有更多的性能优势，因为额外的线程在短任务中吃力，但blob单线程仍在长线程上等待。如果是这样的话，我会看到线程中有一些等待，我有理由怀疑我是否有高极点。不是这样。大量的并行处理正在进行。并行区域的总工作量远远大于其他部分。请查看我的编辑。我在linux上，你的东西应该是直接适用的。