為何要透過ThreadPool來管理Thread?為何要採用Pool的方式?當AP要使用Thread時不是直接New就好了嗎?

1、ThreadPool通常用來解決兩種問題：
A.效能提升
Thread本身也是一種資源,每次New Thread都會花掉系統一些成本,因此若系統作業環境是需要大量Thread來處理時(如Online交易)，藉由ThreadPool來管理Thread如同藉由ConnectionPool來管理Connection一般，將可降低系統花在New Thread的成本

B.控制資源
透過ThreadPool來管理Thread可以有效控管系統資源並避免Thread無限制的產生，同時可以進行Thread量的統計

2、目前FOCAS是採用Spring提供之ThreadPoolTaskExecutor來運作
ThreadPool的管理共有3個參數可供相互設定：corePoolSize、maxPoolSize及queueCapacity，相互關係如下：
A.CorePool Size：設定ThreadPool可接受的主要Thread數量
因此若ActiveThread未超過CorePool Size，則ThreadPool會繼續New Thread

B.QueueCapacity：設定當Request超過CorePool Size時，可以先暫存的數量
因此若Request已經超過CorePool Size，則ThreadPool不會再New Thread，會先將Request放置於ArrayBlockingQueue
若此設定不為正整數，則ThreadPool會採用沒有限制的LinkedBlockingQueue，同時會忽略MaxPool Size的設定，也就是說Thread會無限制產生下去

C.MaxPool Size：設定當Queue滿的時候，最大Thread的數量
因此若Request超過CorePool Size，會先放入Queue中保存，若連Queue都滿了,這時候ThreadPool會再New Thread，直到等於MaxPool Size
當Request量牴觸到MaxPool Size時，ThreadPool會將後續Request丟掉，可以實作RejectedExecutionHandler來承接這些被丟掉的Request，後續再看看是要記錄到資料庫或進行其他處置

3、因此QueueCapacity及MaxPool Size的設定必須取得平衡點
A.若使用Queue大，MaxPool Size小
可以降低CPU及資源的使用，但對Online交易來說將會造成大量Request在Queue中無法立即處理，因此若是屬於即時性不高的作業，如HouseKeeping或傳檔，為了保護系統資源不被批次無限制吃光，倒是可以採用這樣的配置

B.若使用Queue小，MaxPool Size大 
可以對Request作最即時的處理，但是相對來說CPU及記憶體的使用將會昇高，因此可透過MaxPool Size來保護系統，因此若是即時性的作業如Online交易，是有回覆時間的壓力並無法在Queue中慢慢等，因此可採用這種方式

上述的行為已經在FOCAS上實側過，實際數字必須經由量測來抓才準

4.Sun網站上有針對ThreadPool做很多的說明,可以參閱
http://java.sun.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html