我正在構建一個長時間運行的應用程序,該應用程序被建模爲基於面向服務的體系結構的服務。稱之爲'serviceA'。它有一個活動來執行,每當調用API時調用'activityA'。在長時間運行的應用程序中運行並行任務
activityA有一個活動處理程序,它必須並行執行「n」個任務,然後合併並將結果返回給調用serviceA API的客戶端。
我打算使用ExecutorService來實現這種並行性。
有2種方式與此先走:
在單身範圍創建的ExecutorService,並將其作爲活動的處理程序的屬性。因此,同一個ExecutorService對象在服務的整個生命週期中都可用。當新的請求到來時,處理程序使用此ExecutorService對象提交併行任務。然後等待Future對象一定的超時時間。完成所有並行任務後,合併並返回activityA響應。
每次在活動處理程序中收到對activityA的請求時,都會創建新的ExecutorService對象。將並行任務提交給此對象,在某些超時時間內等待Future結果,合併結果,調用ExecutorService對象的關閉並返回activityA API響應。
因此,
哪2以上方法的應遵循?主要區別b/w 2是ExecutorService對象的生命週期。
如果這個數據有助於決策制定,那麼該服務應該被稱爲每秒大約15k個事務處理?
第一種方法的優點是我們不會有創建和關閉新的ExecutorService對象和線程的開銷。但是,當超時時間沒有未來結果時會發生什麼?線程是否自動關閉?它是否可用於任何將要進入ExecutorService線程池的新請求?或者它會處於某種等待狀態,並吃掉記憶 - 在這種情況下,我們需要手動做些什麼(以及什麼)?
另外,我們調用future.get()時的超時時間是從我們進行此調用的時間還是從我們將任務提交給執行程序服務的時間?
請讓我知道是否有任何2種方法是明顯的方法來解決這個問題。
謝謝。
我想,它可能會幫助你http://reactivex.io/documentation/observable.html RxJava是執行並行任務的最佳解決方案之一,當然它更好,然後重新發明輪子。 – Ivan
謝謝伊凡的建議!可能會研究它。但是現在我想堅持使用ExecutorService,因爲項目的週轉時間較短。 –