考慮一個可以分解成數百個小型，獨立運行的任務的大任務。更具體地說，每個小任務是發送一個輕量級網絡請求並決定從服務器收到的答案。預計這些小任務不會超過一秒，並且總共涉及幾臺服務器。Java執行器：小任務還是大任務？
我想到了兩種使用Executor框架來實現這個功能的方法，我想知道哪一個更好，爲什麼。
對不起，如果我的問題顯示我懶惰測試這些，看看自己什麼更好（至少在性能方面）。我的問題在回答這個具體案例的同時，有一個更廣泛的方面。在像這樣的情況下，當你想使用執行器來執行所有的調度和其他任務時，創建大量小任務還是將它們分組爲較少數量的較大任務會更好？
創建大量小任務還是將這些任務分組爲較少數量的較大任務會更好？
很難概括這樣的問題，但在你的情況下，我認爲創建一些任務每個做5到10件事情然後提交給執行器服務是沒有意義的。
我會把所有的工作作爲一堆個人的小任務提交給ExecutorService。我認爲這將使得從對象/代碼的角度來看，任務更加清潔。他們不需要收集請求/回覆，可以專注於提出一個請求並處理一個響應。
如果您不希望將併發請求發送到特定服務器，則會有一個例外。那麼讓一個任務完成特定服務器的所有請求/響應併爲每個服務器提交一個任務是有意義的。
一般來說，我認爲小任務會更好，因爲它們就像模塊一樣，即使需求發生變化，也可以按照期望的方式進行組合。
但是，如果它們只能作爲一個塊執行，那麼對於一個大任務您可以更好地進行概述。
表演當然也是一個問題。但這很大程度上取決於服務器/機器的CPU數量以及整個系統的負載。即使我們知道，你究竟在做什麼，你需要測試以確定哪些更有效。但請記住，任務的初始化和管理也需要一些時間，如果您的操作非常小，您可能會在實際執行中投入更多時間在任務管理中。
對於需要處理請求的應答服務器，並行運行所有（小）任務可能也很困難。請記住，Web服務等通常也會限制它們可以提供多少個並行請求。
謝謝你的回答。考慮到你的第三段，我正在問如何知道這些任務是否「足夠大」。我並不關心並行執行的性質和併發運行任務的數量。無論任務是小還是大，在創建執行程序時都可以輕鬆配置它們。 –
ForkJoinPool是您的解決方案。您可以拆分大型任務的小型子任務。看看這篇文章：http://stackoverflow.com/questions/34613989/java-how-to-get-finished-threads-to-pickup-tasks-from-running-threads/34614276#34614276 –
我建議你確保每個任務至少比10-100毫秒長，除非它更簡單，否則可能不會給你帶來太多好處。 –
這取決於「更好」的含義 - 例如，無論您需要吞吐量還是低延遲。也可能取決於您是在單核上還是在8核上運行。 – DNA
你能解釋更多@Peter的評論嗎？ – Gray