在最近的專案中，遇到了一些需要經常使用sql查詢，寫入文件，可以分割子任務的狀況。為了提高程式吞吐量，我使用了線程池。
一開始，考慮將使用者依數量分片，因為在資料庫查詢中，oracle對where in（）有不得超過1000個查詢量的限制，所以考慮將每900個使用者分一片，每片為一個task，交給fix線程池處理。
但是每個task又有查詢優惠券和查詢待評論數兩個較大的子任務，這兩個子任務需要大量的sql查詢，於是又考慮將這兩個子任務也封裝為task，交給線程池處理。但因為主任務的執行依賴子任務的結果，如果使用同一個執行緒池，則子任務被提交後，work佇列中被執行的任務還是主任務，cpu一直在先提交的主任務上等待Future.get （）的返回，子任務得不到cpu資源去執行，一直在任務佇列中等待，這將造成程式的死等待。所以將執行緒池由fix改為cache，希望提交的任務能得到cpu時間，不會一直在佇列中等待。後來這裡也引發了問題，將在下一篇文章中說明。
當使用者的帳單資料被計算出來後，需要調用範本中心產生郵件，還需要將產生的郵件儲存到磁碟上，這是兩種不同的io密集型任務，一個是在socket上等待，一個是在本地io上等待。考慮到如果繼續提交到cache線程池，那麼線程池會為每個task產生一個線程，將耗費大量資源，cpu將頻繁切換線程，降低了程式的吞吐量。因此新建一個fix線程池，將這些後續任務提交給fix線程池處理，線程池使用固定數量的work去跑，即能在不同阻塞情況下，讓程式可以繼續運行，也避免了創建大量thread的資源浪費。
其實最後程式裡用了五個執行緒池，分級使用的原因有以下考慮：
為了提高程式執行效率，可以將使用者先按照語言分類，然後再按照900人一片進行分片，每片任務中，又涉及兩個頻繁查詢資料庫的子任務，每片處理完後，又需要進行網路io生產郵件和磁碟io保存郵件。如果使用相同的執行緒池，則上級任務生產的子任務提交fix執行緒池後，因為work佇列仍在被上級任務佔用，不同類型的io操作都會在task佇列中等待，無法提高系統吞吐量。將下級任務提交到其他執行緒池後，下級任務就能有立即執行的機會，進行網路io和磁碟讀寫，提高了運作效率。
