java.util.ThreadPoolExecutor

合理使用線程池能帶來以下幾點好處：

1、下降資源的消耗

經過重複利用已經建立的線程下降線程建立和銷燬形成的消耗

2、提升響應速度

當任務到達時，任務能夠不須要等到線程建立就能當即執行

3、提升線程的可管理性

線程是稀缺資源，若是無限制的建立，不只會消耗系統資源，還會下降系統穩定性，使用線程池能夠進行 統一分配，調優和監控

線程池將自動調整池的大小根據corePoolSize和maximumPoolSize;當一個新任務被提交執行後，

若線程池中工做線程數小於corePoolSize時，一個新的線程將會建立並處理當前的請求，即便有其餘空閒的線程;若工做線程數多於corePoolSize，可是少於maximumPoolSize時，只有當隊列滿時新的線程纔會建立，經過設置corePoolSize和maximumPoolSize相等便可建立一個固定大小的線程池

若是當前線程池中有多於corePoolSize的工做線程，若超出線程一直閒置超過keepAliveTime時間時，那麼它們就將被終止，故當線程池中的工做線程沒有積極使用時，減小資源消耗;若是線程池更加活躍時，新的工做線程將會被建立

任何BlockingQueue可能用來傳遞和保持提交的任務，該隊列使用線程池大小相互影響，若線程池中工做線程數小於corePoolSize時，線程池老是先建立一個新的工做線程，而不是排列，目前提供3種queue策略：SynchronousQueue、LinkedBlockingQueue、ArrayBlockingQueue

當線程池已經關閉（採用有限範圍的最大線程和工做隊列容量並飽和），一個新的任務被提交執行時，那麼該任務將被Rejected，在這狀況下，線程池將調用飽和處理，提供飽和處理策略：AbortPolicy、CallerRunsPolicy、DiscardPolicy、DiscardOldestPolicy

線程池合理配置

根據任務特性分析以下：

1、任務性質：CPU密集型，IO密集型和混合型

2、任務優先級：高和低

3、任務執行時間：長和短

4、任務依賴性：是否依賴其餘資源，如數據庫鏈接

CPU密集型的任務儘量小的線程，如N+1個線程（N爲CPU的個數）;IO密集型因爲線程並非一直在執行任務，則儘量多的配置線程，如2×N;混合型任務，若是能夠拆分，則將其拆分紅一個CPU密集型任務和一個IO密集型任務，只要時間相差不大;優先級不一樣的任務可使用優先級隊列PriorityBlockingQueue來處理;依賴數據庫鏈接池的任務，由於線程提交sql後須要等待數據庫返回結果，若是等待時間越長，CPU空閒時間就越長，那麼線程數就應該設置越大，才能更好利用CPU

public class PausableThreadPoolExecutor extends ThreadPoolExecutor {

    private boolean isPaused;
    
    private ReentrantLock pausedLock = new ReentrantLock();
    private Condition unpaused = pausedLock.newCondition();
    
    
    public PausableThreadPoolExecutor() {
        super(2, 4, 500, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(1));
    }
    
    @Override
    protected void beforeExecute(Thread t, Runnable r) {
        super.beforeExecute(t, r);
        pausedLock.lock();
        try {
            while (isPaused) unpaused.await();
        } catch (InterruptedException e) {
            t.interrupt();
        } finally {
            pausedLock.unlock();
        }
    }
    
    public void pause() {
        pausedLock.lock();
        try {
            isPaused = true;
        } finally {
            pausedLock.unlock();
        }
    }
    
    public void resume() {
        pausedLock.lock();
        try {
            isPaused = false;
            unpaused.signalAll();
        } finally {
            pausedLock.unlock();
        }
    }

}