下面分別解釋每一種線程池特點和使用場景：
1.public static ExecutorService newFixedThreadPool（）
創建一個可重用固定線程數的線程池，以共享的無界隊列方式來運行這些線程。在任意點，在大
多數 nThreads 線程會處於處理任務的活動狀態。如果在所有線程處於活動狀態時提交附加任務，
則在有可用線程之前，附加任務將在隊列中等待。如果在關閉前的執行期間由於失敗而導致任何
線程終止，那么一個新線程將代替它執行后續的任務（如果需要）。在某個線程被顯式地關閉之
前，池中的線程將一直存在。
2.public static ExecutorService newWorkStealingPool（）
jdk1.8新引進的線程池，創建一個擁有多個任務隊列（以便減少連接數）的線程池。由於能夠合理的使用CPU進行對任務操作（並行操作），所以適合使用在很耗時的任務中。
3.public static ExecutorService newSingleThreadExecutor()
返回一個只有一個線程的線程池,這個線程池可以在線程死后（或發生異常時）重新啟動一個線程來替代原來的線程繼續執行下去！
4.public static ExecutorService newCachedThreadPool()
創建一個可根據需要創建新線程的線程池，但是在以前構造的線程可用時將重用它們。對於執行
很多短期異步任務的程序而言，這些線程池通常可提高程序性能。調用 execute 將重用以前構造
的線程（如果線程可用）。如果現有線程沒有可用的，則創建一個新線程並添加到池中。終止並
從緩存中移除那些已有 60 秒鍾未被使用的線程。因此，長時間保持空閑的線程池不會使用任何資
源。
5.newScheduledThreadPool（）
創建一個線程池，它可安排在給定延遲后運行命令或者定期地執行。
各種線程池應用場景
1.CachedThreadPool：適合使用在任務量大但耗時少的任務。
2.FixedThreadPool：適合使用在任務量比較固定但耗時長的任務。
3.ScheduledThreadPool：適合使用在執行定時任務和具體固定周期的重復任務。
4.SingleThreadPool：適合使用在多個任務順序執行的場景。
5.newWorkStealingPool:適合使用在很耗時的任務中
關於線程的其他問題：
一般任務設多少個線程的問題？
這個需要根據具體任務和機器性能來綜合考慮，通過不斷的性能測試，分析出最佳線程數量。一般來講:
1.CPU密集型：cpu利用率較高，設置線程數量和cpu核心數一樣即可。使cpu得到充分利用。
2.IO密集型：IO密集型，主要進行長時間的IO操作，cpu利用率不如cpu密集型高，一般設置線程數為CPU兩倍。
2.如何來設置
a.需要幾個數據來計算
tasks：每秒的任務數，假設為500~1000
taskCost：每個任務需要花費的時間，假設為0.1s
responseTime：系統允許的最大響應時間，假設為2s
b.計算過程
--corePoolSize=每秒需要的線程數？
threadCount=tasks/(1/taskCost)=tasks*taskCost=(500~1000)*0.1=50~100個線程。corePoolSize的個數應該大於等於50。根據8020原則，如果每秒80%的時間執行200個任務，那么corePoolSize設置為80即可。
--queueCapacity=(coreSizePool/taskCost)*responseTime
計算可得queueCapacity=(80/0.1)*2。意思是隊列里的線程可以等待2秒，超過了就需要開新的線程來執行，千萬不能設置為Integer.MAX_VALUE，這樣隊列會很大，線程數只會保持在corePoolSize大小，當任務陡增時，不會開新的線程來執行，響應時間也會陡增。
--maxPoolSize=(max(tasks)-queueCapacity)/(1/taskCost)
計算可能maxPoolSize=(1000-80)/10=92,(最大任務數-隊列容量)/每個線程每秒處理的任務數=最大線程數
--rejectedExecutionHandler：根據具體情況來決定，任務不重要可以丟棄，也可采用排隊等策略
--keepAliveTime和allowCoreThreadTimeout通常采用默認值就可以
c.上面的計算都是理想的情況，在實際生產中，還要根據機器的性能，通橫向擴展或者升級機器硬件來處理高並發產生的任務數