熊與我同在,我不是在多線程編程非常精明......Java的線程池和可運行在創建可運行
我目前正在建設的是使用一個線程池的ExecutorService各種可運行的系統。這很簡單。然而,我正在研究讓runnables本身產生一個額外的runnable的可能性,這個runnable基於原始runnable中發生的事情(例如,如果成功,做到這一點,如果失敗,做到這一點等等,因爲有些任務必須先於其他任務完成執行)。應該注意的是,主線程不需要被通知這些任務的結果,儘管它可能對於處理異常很方便,即如果不能聯繫外部服務並且所有線程都因此拋出異常,則停止提交任務並定期檢查外部服務,直到恢復。這並非完全必要,但它會很好。
即,提交任務A.任務A做一些事情。如果一切順利,任務A將執行任務B.如果某些事情不能正常工作或引發異常,請執行任務C.每個子任務也可能有其他任務,但只有幾個級別深。我寧願在一個任務中做這樣的事情,而不是大型的,咆哮的條件,因爲這種方法允許更大的靈活性。
但是,我不確定這將如何影響線程池。我假設從池中的一個線程內創建的任何附加線程都將存在池外,因爲它們本身並未直接提交到池中。這是一個正確的假設嗎?如果是這樣,這可能是一個壞主意(好吧,如果不是,它可能不是一個好主意),因爲它可能會導致更多的線程,因爲原來的線程完成,並提交一個新的任務,而線程從先前的任務仍然在進行(並且可能會持續比其他任務長得多)。
我也考慮過將這些實現爲Callables,並在返回的Future中放置響應對象,然後根據響應將相應的Callable添加到線程池中。但是,這會將所有操作都綁定到主線程,這似乎是不必要的瓶頸。我想我可以將一個Runnable放入池中,該池本身處理Callable和後續動作的執行,但是然後我得到兩倍的線程數。
我在這裏的正確軌道上,還是我完全脫軌?
漂亮漂亮,但不是我想要的。將工作量分成更小的塊並不是真正需要的,但從某種意義上來說,更多的是在一個池中進行條件任務鏈的模式。 – user1017413