多線程程序運行速度比單線程慢

Question

我試圖解決Euler Project 。 要點在這里。 是的，我明白了，沒有使用算法 - 我不想。 問題是，第二個文件正在使用ExecutorService來查找值 -我知道結果將不正確，但與單線程相比，它正在爬行。 我認為創建線程本身可能會將池大小減少到 4（我有一個八核處理器），但這沒有任何作用。

早些時候，我也使用類似的方法來顯着加快使用多線程的縮略圖生成。 但我無法理解是什么導致了這種特殊情況的緩慢。 我不是想得到正確的解決方案 - 我知道我應該先這樣做，然后再嘗試其他任何事情。 我做錯了什么。 我來這里並不是為了找到問題的解決方案，但我想了解為什么它很慢。 我使用了線程訪問的static變量。 這可能是個問題嗎？

Answer 1

我知道結果將不正確，但與單線程相比它正在爬行

我在執行 5-6 分鍾后終止程序，因為它運行得很慢

首先，我假設您使用的是Executors.newFixedThreadPool() ，它分配固定數量的線程而不是緩存的線程池。

在我看來，您可能正在創建大量作業，而您的程序內存不足。 當您填滿內存時，JVM 會在 GC 上越來越努力地工作，這表現為您的進程越來越慢。 您可以使用 jconsole 連接到應用程序以驗證線程數和內存。 您還可以對其進行線程轉儲（ kill -QUIT pid ）並查看您分叉了多少作業。

如果您正在創建大量作業而您的ExecutorService無法跟上，那么您將需要限制作業生產。 有幾種不同的方法可以做到這一點。 這是我使用的：

在 Java 中處理 HTTP 調用的大文件

從那里鏈接的其他解決方案。

我認為創建線程本身可能會將池大小減少到 4（我有一個八核處理器），但這沒有任何作用。

是的，這似乎不是處理器問題。 我會將它移回 8。如果這確實使該框無法使用，請在ExecutorService嘗試 7 或 6 個線程。

編輯：

在更多地查看代碼后，您正在執行一堆不同步的數據更新，這將導致奇怪的結果。 任何時候你修改共享內存（在你的情況下是共享static字段），那么你將不得不在互斥鎖（ ++ ）和內存共享方面進行一些同步。

如果可以，我會考慮使用AtomicLong和其他人，但您應該閱讀一些關於共享內存和同步的線程教程： http : //docs.oracle.com/javase/tutorial/essential/concurrency/sync.html