項目是B/S模式，放在linux服務器上，tomcat和oracle11g在一台服務器上，tomcat讀取數據庫采用C3P0連接池，一直比較穩定，所以也沒有去管。后來把tomcat放在一台win2008下，數據庫放在另外一台win2008下。運行了半月有余，期間經常報數據庫連接錯誤，但刷新下頁面也就好了。因為是偶發問題，也沒有去關注。終於有一天徹底報錯進不了了，報錯截圖如下：
大意是與數據庫連接有問題。這才慌慌的打開數據庫服務器查看原因。數據庫貌似正常，但用sqlplus連接不上，報超過最大連接數。於是用netstat -ano ，本意是想看看監聽端口是否正常監聽。未曾想出現了四百多條 1521端口 的time_wait信息：
難怪數據庫連不上，於是就暫時先把數據庫重啟了下。查看了半個小時，數據庫連接保持在50左右，以為正常了。到了下午，放心不下，又上服務器查看了一下，乖乖，又有200多條TIME_WAIT。還好發現的早，不然過幾天肯定又得出問題。遂谷歌百度搜索一陣，貌似這個問題國內外出現不少，按照一個簡單的解決方法：
在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名為TcpTimedWaitDelay的
DWORD鍵,設置為60,以縮短TIME_WAIT的等待時間
同時添加 MaxUserPort 值為 65534
之后一直就沒再出現過這個問題。我就一直納悶了，配置都差不多，難道是win系統和linux系統性能差別，我想也不可能啊，不能差這么多。這事就一直放在心上，有天突然想起，原來linux下是因為web和數據庫放在同一台服務器上，web和數據庫是通過本地進程通訊，沒涉及到tcp協議。而后來win系統是分開兩台，兩台低層是通過TCP交流數據。由於win系統的一些默認設置，導致數據庫連接池用完后沒有及時釋放TCP的空閑數據庫連接。TCP連接就一直持續增加，慢慢超過了限制。配置了TcpTimedWaitDelay 后，TCP連接在空閑60秒后會自動釋放。因此，一般情況下就保持着50個左右的穩定連接。
我想應該是如此，有時候看着數據庫池好用，但其實還是對低層做了一個包裝。低層的設置還是要配置一下。
-----------------------------------------華麗的分割線，測試一天后補充--------------------------------------------------------------------
第二天，故障依舊，看來不是改改注冊表的事情。而且，之后查資料得知主動關閉連接的一方才會進入TIME_WAIT的狀態。而數據庫一般不會主動關閉連接，只有客戶端主動執行了conn.close()，才會關閉數據庫連接。那會是什么問題呢，我陷入了深深的思索，無果，繼續谷歌百度，看了一些資料。登陸數據庫服務器，執行了一下
select count(*) from v$process
查到當前連接數有147
然后執行
show parameter processes
數據庫的最大連接數才150
問題在此了，那就好解釋，由於后來請求數超過了oracle的最大連接數，所以對於超過數量的連接，oracle就自動斷開了，才會有那么多的TIME_WAIT狀態。
改大連接
alter system set processes =400 scope = spfile;
session不用改，processes 改了后session自動會根據一個比例增加，改完后我的是624
然后把數據庫連接池最大值改成150
測試了一天，再沒出現故障，通過netstat -ano| findstr "1521" 查詢到的端口狀態基本上都是established（已建立連接）和少量的LISTENING