聲明：本文禁止未經本人同意的任何形式轉載！如有轉載需求，可與本人通過個人資料中的電子郵箱聯繫。對於未經同意的轉載，本人將保留進一步行動的權利
JDBC連接池
大部分Java EE應用都需要通過JDBC連接後臺數據庫。因爲創建數據庫連接的消耗的資源巨大，所以應用服務器都選擇緩存一定數量的連接對象並在各個請求處理之間共享。如果請求需要數據庫的連接，但連接池中已經不能提供空間的連接，也不能創建一個新連接，那麼請求就需要等待別的連接被釋放後才能工作。反之，如果數據庫連接池太大的話，就會浪費應用服務器的資源。本部分調優的全部努力就是旨在找出請求需要等待的最佳點，以便最小程度影響飽和的資源——如果數據庫的壓力很大的話，讓請求在外面等待會更好。
連接不夠的應用服務器可能的表現有：
- 應用性能低下
- CPU利用率低
- 數據庫連接池利用率高
- 線程等待數據庫連接
- 執行線程的利用率高
- 隊列中可能有請求等待
- 數據庫服務器的CPU利用率不太高
當觀察到這些現象時，可以調高數據庫連接池的大小直至數據庫連接的利用率在普通負荷的情況下大約在70%~80%之間。在整個過程中也需要注意數據庫的負荷情況，我們也不希望對數據庫產生過大的負荷壓力。
JDBC prepared statement
對JDBC調優另一個重要的部分就是恰當配置JDBC連接中prepared statement的緩存大小。當應用對數據庫執行SQL語句時，主要經歷三個階段：
- 準備
- 執行
- 檢索
在準備階段，數據庫驅動向數據庫發出請求，數據庫需要生成查詢的執行計劃。在執行階段，數據庫執行查詢，並返回結果集的引用。在檢索階段，應用遍歷結果集並獲取需要的信息。
數據庫驅動能優化這一過程：第一次準備一個語句時，它就讓數據庫生成查詢計劃並緩存結果。在後續的操作中，已經準備好的語句(prepared statement)就能從緩存中加載進來，而不需要重回數據庫獲取。
當prepared statement的緩存尺寸太小時，數據庫驅動將被強制再次準備無緩存的語句，如果重新回到數據庫去數據的話將導致額外的處理開銷和網絡時間。Prepared statement緩存不足的主要徵兆即是JDBC不斷重複準備對同一語句的處理。
稍微要複雜一點的是，prepared statement是按照每用戶的基礎來進行緩存的，也就是說一個語句的緩存僅爲一個連接準備，所以如果當應用有100個語句需要緩存而連接池中有50個連接時，就需要有足夠大的空間來容納5000條prepared statement。
在性能監控的環節中，確定應用一共運行了多少條不同的SQL語句，這樣就可以根據每條語句執行的頻率來決定prepared statement的緩存大小。
總結
每個應用的情況都是不同的，但是上述的一些問題還是比較多出現的。本文並未涉及具體的應用服務器產品及其調優方案，而是從整體的角度對一些通用的情況做出了分析。在真正實施調優的時候，需要根據業務需求、硬件條件、軟件情況等多方面的內容做相應的調整。
聲明：本文禁止未經本人同意的任何形式轉載！如有轉載需求，可與本人通過個人資料中的電子郵箱聯繫。對於未經同意的轉載，本人將保留進一步行動的權利！