1

我正在構建一個長時間運行的應用程序,該應用程序被建模爲基於面向服務的體系結構的服務。稱之爲'serviceA'。它有一個活動來執行,每當調用API時調用'activityA'。在長時間運行的應用程序中運行並行任務

activityA有一個活動處理程序,它必須並行執行「n」個任務,然後合併並將結果返回給調用serviceA API的客戶端。

我打算使用ExecutorService來實現這種並行性。

有2種方式與此先走:

  1. 在單身範圍創建的ExecutorService,並將其作爲活動的處理程序的屬性。因此,同一個ExecutorService對象在服務的整個生命週期中都可用。當新的請求到來時,處理程序使用此ExecutorService對象提交併行任務。然後等待Future對象一定的超時時間。完成所有並行任務後,合併並返回activityA響應。

  2. 每次在活動處理程序中收到對activityA的請求時,都會創建新的ExecutorService對象。將並行任務提交給此對象,在某些超時時間內等待Future結果,合併結果,調用ExecutorService對象的關閉並返回activityA API響應。

因此,

  1. 哪2以上方法的應遵循?主要區別b/w 2是ExecutorService對象的生命週期。

  2. 如果這個數據有助於決策制定,那麼該服務應該被稱爲每秒大約15k個事務處理?

  3. 第一種方法的優點是我們不會有創建和關閉新的ExecutorService對象和線程的開銷。但是,當超時時間沒有未來結果時會發生什麼?線程是否自動關閉?它是否可用於任何將要進入ExecutorService線程池的新請求?或者它會處於某種等待狀態,並吃掉記憶 - 在這種情況下,我們需要手動做些什麼(以及什麼)?

  4. 另外,我們調用future.get()時的超時時間是從我們進行此調用的時間還是從我們將任務提交給執行程序服務的時間?

請讓我知道是否有任何2種方法是明顯的方法來解決這個問題。

謝謝。

+0

我想,它可能會幫助你http://reactivex.io/documentation/observable.html RxJava是執行並行任務的最佳解決方案之一,當然它更好,然後重新發明輪子。 – Ivan

+0

謝謝伊凡的建議!可能會研究它。但是現在我想堅持使用ExecutorService,因爲項目的週轉時間較短。 –

回答

1
  1. 第一種方式看起來像是解決此問題的明顯且正確的方法,尤其是對於給定數量的事務。你當然不想重新啓動線程。

  2. Future.get超時不會影響正在執行的線程。它將繼續運行任務,直到它完成或引發異常。在此之前,它不會接受新的任務(但同一執行器中的其他線程將會)。在這種情況下,您可能需要通過調用Future.cancel來明確取消它以釋放新任務的線程。這需要任務本身正確響應中斷(而不是永遠循環,例如,或等待阻塞I/O)。但是,這對於任何線程方法都是一樣的,因爲中斷是反正終止線程的唯一安全方法。爲了緩解這個問題,你可以使用一個動態的線程池,其運行線程的最大數量大於n。這將允許在阻塞任務正在終止的同時處理新任務。

  3. 從你叫它的時候開始。