資料庫線程池
① mysql資料庫線程池問題，為什麼總是報錯Cannot create PoolableConnectionFactory
一般這種情況可能的原因有這幾種:
1. 可能連接超過mysql設置的上限(你的應該沒超)
2. 程序問題，建立了連接不關閉(這個有可能,看看你的session)
3. 在沒有使用連接池的情況下，每次都建立一個新的連接到資料庫（即使每次操作完畢都及時准確的close了），但是由於可能建立到資料庫連接的頻率很高（比如在for循環里），那麼會迅速建立大量的tcp連接到mysql的指定埠，OS在關閉tcp連接是有一定的延遲的，也是有一定數量限制的，所以就會出現無法連接的情況（connection refused）。
-------------------------------------
我個人感覺設置最大連接數可能用處不大,因為默認的是100,你說剛10個就出問題~所以我覺得可能還是和系統有關系,因為你說刷新的不頻繁就不會報錯~
不過你到可以先試試看~萬一能行更好不是~
還有啊,你可以找別的機器試驗下,在別人的電腦上做下測試~
② 常量池線程池連接池各是什麼，優點及特點是什麼
線程池就是 申請固定數目的線程，放在某個空間中。當申請線程時，就從線程池中取得。當線程池中的線程都被佔用的時候，無法獲取到新的線程。
連接池是資料庫連接池，跟線程池原理一樣。
目的都是一樣的，防止鏈接過多造成壓力。
③ 啥時候會使用線程池
編者註：java中的線程池是運用場景最多的並發組件，幾乎所有需要非同步或並發執行任務的程序都可以使用線程池。
在開發過程中，合理地使用線程池能夠帶來至少以下幾個好處。
降低資源消耗：通過重復利用已創建的線程降低線程創建和銷毀造成的消耗。
提高響應速度：當任務到達時，任務可以不需要等到線程創建就能立即執行。
提高線程的可管理性：線程是稀缺資源，如果無限制地創建，不僅會消耗系統資源，還會降低系統的穩定性，使用線程池可以進行統一分配、調優和監控。但是，要做到合理利用線程池，必須了解其實現原理。
代碼解耦：比如生產者消費者模式。
線程池實現原理
當提交一個新任務到線程池時，線程池的處理流程如下：
如果當前運行的線程少於corePoolSize，則創建新線程來執行任務（注意，執行這一步驟需要獲取全局鎖）。
如果運行的線程等於或多於corePoolSize，則將任務加入BlockingQueue。
如果無法將任務加入BlockingQueue（隊列已滿），則創建新的線程來處理任務（注意，執行這一步驟也需要獲取全局鎖）。
如果創建新線程將使當前運行的線程數超出maximumPoolSize，該任務將被拒絕，並調用相應的拒絕策略來處理（RejectedExecutionHandler.rejectedExecution()方法，線程池默認的飽和策略是AbortPolicy，也就是拋異常）。
ThreadPoolExecutor採取上述步驟的總體設計思路，是為了在執行execute()方法時，盡可能地避免獲取全局鎖（那將會是一個嚴重的可伸縮瓶頸）。在ThreadPoolExecutor完成預熱之後（當前運行的線程數大於等於corePoolSize），幾乎所有的execute()方法調用都是執行步驟2，而步驟2不需要獲取全局鎖。
線程池任務 拒絕策略包括 拋異常、直接丟棄、丟棄隊列中最老的任務、將任務分發給調用線程處理。
線程池的創建：通過ThreadPoolExecutor來創建一個線程池。
new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, timeUnit, runnableTaskQueue, handler);
創建一個線程池時需要輸入以下幾個參數：
corePoolSize（線程池的基本大小）：當提交一個任務到線程池時，線程池會創建一個線程來執行任務，即使其他空閑的基本線程能夠執行新任務也會創建線程，等到線程池的線程數等於線程池基本大小時就不再創建。如果調用了線程池的prestartAllCoreThreads()方法，線程池會提前創建並啟動所有基本線程。
maximumPoolSize（線程池最大數量）：線程池允許創建的最大線程數。如果隊列滿了，並且已創建的線程數小於最大線程數，則線程池會再創建新的線程執行任務。值得注意的是，如果使用了無界的任務隊列這個參數就沒什麼效果。
keepAliveTime（線程活動保持時間）：線程池的工作線程空閑後，保持存活的時間。所以，如果任務很多，並且每個任務執行的時間比較短，可以調大時間，提高線程的利用率。
TimeUnit（線程活動保持時間的單位）：可選的單位有天（DAYS）、小時（HOURS）、分鍾（MINUTES）、毫秒（MILLISECONDS）、微秒（MICROSECONDS，千分之一毫秒）和納秒（NANOSECONDS，千分之一微秒）。
runnableTaskQueue（任務隊列）：用於保存等待執行的任務的阻塞隊列。可以選擇以下幾個阻塞隊列。
- ArrayBlockingQueue：是一個基於數組結構的有界阻塞隊列，此隊列按FIFO（先進先出）原則對元素進行排序。
LinkedBlockingQueue：一個基於鏈表結構的阻塞隊列，此隊列按FIFO排序元素，吞吐量通常要高於ArrayBlockingQueue。靜態工廠方法Executors.newFixedThreadPool()使用了這個隊列。
SynchronousQueue：一個不存儲元素的阻塞隊列。每個插入操作必須等到另一個線程調用移除操作，否則插入操作一直處於阻塞狀態，吞吐量通常要高於LinkedBlockingQueue，靜態工廠方法Executors.newCachedThreadPool使用了這個隊列。
PriorityBlockingQueue：一個具有優先順序的無界阻塞隊列。
線程的狀態
在HotSpot VM線程模型中，Java線程被一對一映射到本地系統線程，Java線程啟動時會創建一個本地系統線程；當Java線程終止時，這個本地系統線程也會被回收。操作系統調度所有線程並把它們分配給可用的CPU。
thread運行周期中，有以下6種狀態，在 java.lang.Thread.State 中有詳細定義和說明：
// Thread類
public enum State {
/**
* 剛創建尚未運行
*/
NEW,
/**
* 可運行狀態，該狀態表示正在JVM中處於運行狀態，不過有可能是在等待其他資源，比如CPU時間片，IO等待
*/
RUNNABLE,
/**
* 阻塞狀態表示等待monitor鎖（阻塞在等待monitor鎖或者在調用Object.wait方法後重新進入synchronized塊時阻塞）
*/
BLOCKED,
/**
* 等待狀態，發生在調用Object.wait、Thread.join (with no timeout)、LockSupport.park
* 表示當前線程在等待另一個線程執行某種動作，比如Object.notify()、Object.notifyAll()，Thread.join表示等待線程執行完成
*/
WAITING,
/**
* 超時等待，發生在調用Thread.sleep、Object.wait、Thread.join (in timeout)、LockSupport.parkNanos、LockSupport.parkUntil
*/
TIMED_WAITING,
/**
*線程已執行完成，終止狀態
*/
TERMINATED;
}
線程池操作
向線程池提交任務，可以使用兩個方法向線程池提交任務，分別為execute()和submit()方法。execute()方法用於提交不需要返回值的任務，所以無法判斷任務是否被線程池執行成功。通過以下代碼可知execute()方法輸入的任務是一個Runnable類的實例。
threadsPool.execute(new Runnable() {
@Override
public void run() {
// TODO Auto-generated method stub
}
});
submit()方法用於提交需要返回值的任務。線程池會返回一個future類型的對象，通過這個future對象可以判斷任務是否執行成功，通過future的get()方法來獲取返回值，future的get()方法會阻塞當前線程直到任務完成，而使用get（long timeout，TimeUnit unit）方法則會阻塞當前線程一段時間後立即返回，這時候有可能任務還沒有執行完。
Future<Object> future = executor.submit(harReturnValuetask);
try {
Object s = future.get();
} catch (InterruptedException e) {
// 處理中斷異常
} catch (ExecutionException e) {
// 處理無法執行任務異常
} finally {
// 關閉線程池
executor.shutdown();
}
合理配置線程池
要想合理配置線程池，必須先分析任務的特點，可以從以下幾個角度分析：
任務的性質：CPU密集型任務、IO密集型任務和混合型任務。
任務的優先順序：高、中和低。
任務的執行時間：長、中和短。
任務的依賴性：是否依賴其他系統資源，如資料庫連接。
性質不同的任務可以用不同規模的線程池分開處理。CPU密集型任務應配置盡可能少的線程，如配置Ncpu+1個線程的線程池。由於IO密集型任務線程並不是一直在執行任務，則應配置多一點線程，如2*Ncpu。混合型的任務，如果可以拆分，將其拆分成一個CPU密集型任務和一個IO密集型任務，只要這兩個任務執行的時間相差不是太大，那麼分解後執行的吞吐量將高於串列執行的吞吐量。如果這兩個任務執行時間相差太大，則沒必要進行分解。可以通過Runtime.getRuntime().availableProcessors()方法獲得當前設備的CPU個數。
優先順序不同的任務可以使用優先順序隊列PriorityBlockingQueue來處理。它可以讓優先順序高的任務先執行。執行時間不同的任務可以交給不同規模的線程池來處理，或者可以使用優先順序隊列，讓執行時間短的任務先執行。依賴資料庫連接池的任務，因為線程提交SQL後需要等待資料庫返回結果，等待的時間越長，則CPU空閑時間就越長，那麼線程數應該設置得越大，這樣才能更好地利用CPU。
線程池中線程數量未達到coreSize時，這些線程處於什麼狀態？
這些線程處於RUNNING或者WAITING，RUNNING表示線程處於運行當中，WAITING表示線程阻塞等待在阻塞隊列上。當一個task submit給線程池時，如果當前線程池線程數量還未達到coreSize時，會創建線程執行task，否則將任務提交給阻塞隊列，然後觸發線程執行。（從submit內部調用的代碼也可以看出來）
ScheledThreadPoolExecutor
ScheledThreadPoolExecutor繼承自ThreadPoolExecutor。它主要用來在給定的延遲之後運行任務，或者定期執行任務。
ScheledThreadPoolExecutor的功能與Timer類似，但
ScheledThreadPoolExecutor功能更強大、更靈活。Timer對應的是單個後台線程，而
ScheledThreadPoolExecutor可以在構造函數中指定多個對應的後台線程數。
ScheledThreadPoolExecutor繼承自ThreadPoolExecutor，
ScheledThreadPoolExecutor和ThreadPoolExecutor的區別是，ThreadPoolExecutor獲取任務時是從BlockingQueue中獲取的，而
ScheledThreadPoolExecutor是從DelayedWorkQueue中獲取的（注意，DelayedWorkQueue是BlockingQueue的實現類）。
ScheledThreadPoolExecutor把待調度的任務（ScheledFutureTask）放到一個DelayQueue中，其中ScheledFutureTask主要包含3個成員變數：
sequenceNumber：任務被添加到ScheledThreadPoolExecutor中的序號；
time：任務將要被執行的具體時間；
period：任務執行的間隔周期。
ScheledThreadPoolExecutor會把待執行的任務放到工作隊列DelayQueue中，DelayQueue封裝了一個PriorityQueue，PriorityQueue會對隊列中的ScheledFutureTask進行排序，具體的排序比較演算法實現如下：
ScheledFutureTask在DelayQueue中被保存在一個PriorityQueue（基於數組實現的優先隊列，類似於堆排序中的優先隊列）中，在往數組中添加/移除元素時，會調用siftDown/siftUp來進行元素的重排序，保證元素的優先順序順序。
static class DelayedWorkQueue extends AbstractQueue<Runnable>
implements BlockingQueue<Runnable> {
private static final int INITIAL_CAPACITY = 16;
private RunnableScheledFuture<?>[] queue =
new RunnableScheledFuture<?>[INITIAL_CAPACITY];
private final ReentrantLock lock = new ReentrantLock();
private int size = 0;
private Thread leader = null;
private final Condition available = lock.newCondition();
}
從DelayQueue獲取任務的主要邏輯就在take()方法中，首先獲取lock，然後獲取queue[0]，如果為null則await等待任務的來臨，如果非null查看任務是否到期，是的話就執行該任務，否則再次await等待。這里有一個leader變數，用來表示當前進行awaitNanos等待的線程，如果leader非null，表示已經有其他線程在進行awaitNanos等待，自己await等待，否則自己進行awaitNanos等待。
// DelayedWorkQueue
public RunnableScheledFuture<?> take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
for (;;) {
RunnableScheledFuture<?> first = queue[0];
if (first == null)
available.await();
else {
long delay = first.getDelay(NANOSECONDS);
if (delay <= 0)
return finishPoll(first);
first = null; // don't retain ref while waiting
if (leader != null)
available.await();
else {
Thread thisThread = Thread.currentThread();
leader = thisThread;
try {
available.awaitNanos(delay);
} finally {
if (leader == thisThread)
leader = null;
}
}
}
}
} finally {
if (leader == null && queue[0] != null)
available.signal();
lock.unlock();
}
}
獲取到任務之後，就會執行task的run()方法了，即ScheledFutureTask.run()：
public void run() {
boolean periodic = isPeriodic();
if (!canRunInCurrentRunState(periodic))
cancel(false);
else if (!periodic)
ScheledFutureTask.super.run();
else if (ScheledFutureTask.super.runAndReset()) {
setNextRunTime();
reExecutePeriodic(outerTask);
}
}
推薦閱讀：
JMM Java內存模型
happens-before那些事兒
為什麼說LockSupport是Java並發的基石？
責任鏈的2種實現方式，你更pick哪一種
2閱讀
④ 線程池的技術背景
在面向對象編程中，創建和銷毀對象是很費時間的，因為創建一個對象要獲取內存資源或者其它更多資源。在Java中更是如此，虛擬機將試圖跟蹤每一個對象，以便能夠在對象銷毀後進行垃圾回收。所以提高服務程序效率的一個手段就是盡可能減少創建和銷毀對象的次數，特別是一些很耗資源的對象創建和銷毀。如何利用已有對象來服務就是一個需要解決的關鍵問題，其實這就是一些池化資源技術產生的原因。比如大家所熟悉的資料庫連接池正是遵循這一思想而產生的，本文將介紹的線程池技術同樣符合這一思想。
目前，一些著名的大公司都特別看好這項技術，並早已經在他們的產品中應用該技術。比如IBM的WebSphere，IONA的Orbix 2000在SUN的 Jini中，Microsoft的MTS（Microsoft Transaction Server 2.0），COM+等。
⑤ 什麼是線程池，如何設計一個動態大小的線程
只要您遵循幾條簡單的准則，線程池可以成為構建伺服器應用程序的極其有效的方法：
不要對那些同步等待其它任務結果的任務排隊。這可能會導致上面所描述的那種形式的死鎖，在那種死鎖中，所有線程都被一些任務所佔用，這些任務依次等待排隊任務的結果，而這些任務又無法執行，因為所有的線程都很忙。
在為時間可能很長的操作使用合用的線程時要小心。如果程序必須等待諸如 I/O 完成這樣的某個資源，那麼請指定最長的等待時間，以及隨後是失效還是將任務重新排隊以便稍後執行。這樣做保證了：通過將某個線程釋放給某個可能成功完成的任務，從而將最終取得某些進展。
理解任務
要有效地調整線程池大小，您需要理解正在排隊的任務以及它們正在做什麼。它們是 CPU 限制的（CPU-bound）嗎？它們是 I/O 限制的（I/O-bound）嗎？您的答案將影響您如何調整應用程序。如果您有不同的任務類，這些類有著截然不同的特徵，那麼為不同任務類設置多個工作隊列可能會有意義，這樣可以相應地調整每個池。
調整池的大小
調整線程池的大小基本上就是避免兩類錯誤：線程太少或線程太多。幸運的是，對於大多數應用程序來說，太多和太少之間的餘地相當寬。
請回憶：在應用程序中使用線程有兩個主要優點，盡管在等待諸如 I/O 的慢操作，但允許繼續進行處理，並且可以利用多處理器。在運行於具有 N 個處理器機器上的計算限制的應用程序中，在線程數目接近 N 時添加額外的線程可能會改善總處理能力，而在線程數目超過 N 時添加額外的線程將不起作用。事實上，太多的線程甚至會降低性能，因為它會導致額外的環境切換開銷。
線程池的最佳大小取決於可用處理器的數目以及工作隊列中的任務的性質。若在一個具有 N 個處理器的系統上只有一個工作隊列，其中全部是計算性質的任務，在線程池具有 N 或 N+1 個線程時一般會獲得最大的 CPU 利用率。
對於那些可能需要等待 I/O 完成的任務（例如，從套接字讀取 HTTP 請求的任務），需要讓池的大小超過可用處理器的數目，因為並不是所有線程都一直在工作。通過使用概要分析，您可以估計某個典型請求的等待時間（WT）與服務時間（ST）之間的比例。如果我們將這一比例稱之為 WT/ST，那麼對於一個具有 N 個處理器的系統，需要設置大約 N*(1+WT/ST) 個線程來保持處理器得到充分利用。
處理器利用率不是調整線程池大小過程中的唯一考慮事項。隨著線程池的增長，您可能會碰到調度程序、可用內存方面的限制，或者其它系統資源方面的限制，例如套接字、打開的文件句柄或資料庫連接等的數目。
⑥ 【Java基礎】線程池的原理是什麼
什麼是線程池？
總歸為：池化技術 ---》資料庫連接池 緩存架構 緩存池 線程池 內存池，連接池，這種思想演變成緩存架構技術---> JDK設計思想有千絲萬縷的聯系
首先我們從最核心的ThreadPoolExecutor類中的方法講起，然後再講述它的實現原理，接著給出了它的使用示例，最後討論了一下如何合理配置線程池的大小。
Java 中的 ThreadPoolExecutor 類
java.uitl.concurrent.ThreadPoolExecutor 類是線程池中最核心的一個類，因此如果要透徹地了解Java 中的線程池，必須先了解這個類。下面我們來看一下 ThreadPoolExecutor 類的具體實現源碼。
在 ThreadPoolExecutor 類中提供了四個構造方法：
⑦ SQL Server的線程池，內存池和連接池有什麼區別和關系
網上找了寫資料：�0�2資料庫連接池: �0�2�0�2�0�2�0�2�0�2 �0�2�0�2�0�2�0�2 資料庫連接是一種關鍵的有限的昂貴的資源，這一點在多用戶的網頁應用程序中體現得尤為突出。 �0�2�0�2 �0�2 一個資料庫連接對象均對應一個物理資料庫連接，每次操作都打開一個物理連接，使用完都關閉連接，這樣造成系統的 性能低下。 資料庫連接池的解決方案是在應用程序啟動時建立足夠的資料庫連接，並講這些連接組成一個連接池( 簡單說：在一個「 池」里放了好多半成品的資料庫聯接對象)，由應用程序動態地對池中的連接進行申請、使用和釋放。對於多於連接池中連接數的並發請求，應該在請求隊列中排隊等待。並且應用程序可以根據池中連接的使用率，動態增加或減少池中的連接數。 �0�2�0�2 �0�2連接池技術盡可能多地重用了消耗內存地資源，大大節省了內存，提高了伺服器地服務效率，能夠支持更多的客戶服務。通過使用連接池，將大大提高程序運行效率，同時，我們可以通過其自身的管理機制來監視資料庫連接的數量、使用情況等。 �0�2�0�2�0�2 1) 最小連接數是連接池一直保持的資料庫連接，所以如果應用程序對資料庫連接的使用量不大，將會有大量的資料庫連接資源被浪費； �0�2�0�2�0�2 2) 最大連接數是連接池能申請的最大連接數，如果資料庫連接請求超過此數，後面的資料庫連接請求將被加入到等待隊列中，這會影響之後的資料庫操作。 �0�2線程池�0�2SQL Server 維護一個操作系統線程池，以便執行從客戶端送達的成批 SQL 語句。在 Microsoft Windows NT�0�3 上，如果伺服器的 lightweight pooling 配置選項設為 1，則 SQL Server 不再維護線程，轉而維護一個纖程池；纖程使用比線程更少的資源。使用線程池或纖程池，可以使 SQL Server 在同時執行多個 SQL 語句時優化處理時間分配。該池中的線程或纖程共同作為工作線程。 �0�2工作線程數是由伺服器配置選項 max worker threads 控制的。默認值為 255 而且幾乎不需要更改。 當從客戶端收到一批 Transact-SQL 語句時，如果現有的工作線程空閑，就會分配它來執行這個批處理。如果沒有空閑的現有工作線程而且工作線程數少於 max worker threads，那麼就會分配一個新的工作線程。如果沒有空閑的工作線程而且已經達到 max worker threads，那麼新的批處理就要一直等到現有工作線程完成其當前批處理任務而空閑為止。當工作線程數達到 max worker threads 時，SQL Server 顯示如下消息：工作線程限制 255 已經達到。 �0�2對所有工作線程進行分配，並不意味著 SQL Server 的性能會降低。通常，新的批處理等待空閑線程只需要很短的時間。分配更多的線程可能會降低性能，因為增加的工作需要在線程之間協調資源。很多在生產狀態運行的 SQL Server 系統都會達到這樣的狀態，而且以非常高的性能級別運行。 �0�2內存池內存池的思想通過這個池字表露無疑，應用程序可以通過系統的內存分配調用預先一次性申請適當大小的內存作為一個內存池，之後應用程序自己對內存的分配和釋放則可以通過這個內存池來完成。
⑧ 線程太多會對伺服器有什麼影響
多線程技術可以提高cpu利用率，尤其是多核cpu的機器,提高並發執行效率。這是建立在cpu執行有空餘的情況下的，多線程也並非沒有代價，首先線程作為操作系統的最小調度單位也是要佔用內存空間的，其次線程調度及上下文切換也會消耗性能。一般線程數為cpu個數*2+1較好，線程太多會佔用內存，頻繁的線程上下文切換也會導致效率降低。
⑨ 為什麼要使用線程池
為什麼要用線程池？諸如Web 伺服器、資料庫伺服器、文件伺服器或郵件伺服器之類的許多伺服器應用程序都面向處理來自某些遠程來源的大量短小的任務。請求以某種方式到達伺服器，這種方式可能是通過網路協議（例如 HTTP、FTP 或 POP）、通過 JMS 隊列或者可能通過輪詢資料庫。不管請求如何到達，伺服器應用程序中經常出現的情況是：單個任務處理的時間很短而請求的數目卻是巨大的。構建伺服器應用程序的一個過於簡單的模型應該是：每當一個請求到達就創建一個新線程，然後在新線程中為請求服務。實際上，對於原型開發這種方法工作得很好，但如果試圖部署以這種方式運行的伺服器應用程序，那麼這種方法的嚴重不足就很明顯。每個請求對應一個線程（thread-per-request）方法的不足之一是：為每個請求創建一個新線程的開銷很大；為每個請求創建新線程的伺服器在創建和銷毀線程上花費的時間和消耗的系統資源要比花在處理實際的用戶請求的時間和資源更多。除了創建和銷毀線程的開銷之外，活動的線程也消耗系統資源。在一個 JVM 里創建太多的線程可能會導致系統由於過度消耗內存而用完內存或「切換過度」。為了防止資源不足，伺服器應用程序需要一些辦法來限制任何給定時刻處理的請求數目。線程池為線程生命周期開銷問題和資源不足問題提供了解決方案。通過對多個任務重用線程，線程創建的開銷被分攤到了多個任務上。其好處是，因為在請求到達時線程已經存在，所以無意中也消除了線程創建所帶來的延遲。這樣，就可以立即為請求服務，使應用程序響應更快。而且，通過適當地調整線程池中的線程數目，也就是當請求的數目超過某個閾值時，就強制其它任何新到的請求一直等待，直到獲得一個線程來處理為止，從而可以防止資源不足。
⑩ mysql資料庫每次查詢是一條線程嗎
MySQL的查詢使用的是線程池。當有大量請求並發訪問時，一定伴隨著資源的不斷創建和釋放，導致資源利用率低，降低了服務質量。線程池技術，預先會創建一定數量的線程，當有請求達到時，線程池分配一個線程提供服務，請求結束後，該線程又去服務其他請求。 通過這種方式，避免了線程和內存對象的頻繁創建和釋放，降低了服務端的並發度，減少了上下文切換和資源的競爭，提高資源利用效率。在MySQL早期的版本中，處理連接的方式是One-Connection-Per-Thread,即對於每一個資料庫連接，MySQL-Server都會創建一個獨立的線程服務，請求結束後，銷毀線程。再來一個連接請求，則再創建一個連接，結束後再進行銷毀。但是，這種方式在高並發情況下，會導致線程的頻繁創建和釋放。當然，通過thread-cache，我們可以將線程緩存起來，以供下次使用，避免頻繁創建和釋放的問題，但是無法解決高連接數的問題。One-Connection-Per-Thread方式隨著連接數暴增，導致需要創建同樣多的服務線程，高並發線程意味著高的內存消耗，更多的上下文切換(cpu cache命中率降低)以及更多的資源競爭，導致服務出現抖動。相對於One-Thread-Per-Connection方式，一個線程對應一個連接，Thread-Pool實現方式中，線程處理的最小單位是statement(語句)，一個線程可以處理多個連接的請求。這樣，在保證充分利用硬體資源情況下(合理設置線程池大小)，可以避免瞬間連接數暴增導致的伺服器抖動。