作者曾經主持以及經歷的幾個產品及專案中，包括了各種資料庫及應用伺服器，基本上幾種常見的資料庫連線池都用到了，根據使用的情況把這些連線池比較一下吧。感覺在介紹之前有必要闡述一下連線池的幾個概念，有助於後邊一些文字的理解。最原始的資料庫使用就是開啟一個連線並進行使用，使用過後一定要關閉連線釋放資源。由於頻繁的開啟和關閉連線對jvm包括資料庫都有一定的資源負荷，尤其應用壓力較大時資源佔用比較多容易產生效能問題。由此使用連線池的作用就顯現出來，他的原理其實不復雜：先開啟一定數量的資料庫連線，當使用的時候分配給呼叫者，呼叫完畢後返回給連線池，注意返回給連線池後這些連線並不會關閉，而是準備給下一個呼叫者進行分配。由此可以看出連線池節省了大量的資料庫連線開啟和關閉的動作，對系統性能提升的益處不言而喻。幾個概念：最小連線--應用啟動後隨即開啟的連線數以及後續最小維持的連線數。最大連線數--應用能夠使用的最多的連線數連線增長數--應用每次新開啟的連線個數舉個例子說明連線池的運作：假設設定了最小和最大的連線為10，20，那麼應用一旦啟動則首先開啟10個數據庫連線，但注意此時資料庫連線池的正在使用數字為0--因為你並沒有使用這些連線，而空閒的數量則是10。然後你開始登入，假設登入程式碼使用了一個連線進行查詢，那麼此時資料庫連線池的正在使用數字為1、空閒數為9，這並不需要從資料庫開啟連線--因為連線池已經準備好了10個給你留著呢。登入結束了，當前連線池的連線數量是多少？當然是0，因為那個連線隨著事務的結束已經返還給連線池了。然後同時有11個人在同一秒進行登入，會發生什麼：連線池從資料庫新申請（開啟）了一個連線，連同另外的10個一併送出，這個瞬間連線池的使用數是11個，不過沒關係正常情況下過一會兒又會變成0。如果同時有21個人登入呢？那第21個人就只能等前面的某個人登入完畢後釋放連線給他。這時連線池開啟了20個數據庫連線--雖然很可能正在使用數量的已經降為0，那麼20個連線會一直保持嗎？當然不，連線池會在一定時間內關閉一定量的連線還給資料庫，在這個例子裡數字是20-10=10，因為只需要保持最小連線數就好了，而這個時間週期也是連線池裡配置的。好了，基本概念說完了，言歸正傳進行比較了。首先說明的一點，為了應用便於移植以及可配置的角度，建議還是使用jndi統一進行連線池的配置。怎麼配置其實網上都有很多例子，這裡簡單舉個例子（使用spring框架）：首先在應用的上下文定義中配置jndi名稱，如一個resource.xml檔案，裡邊的寫法     <bean id="dataSource"class="org.springframework.jndi.JndiObjectFactoryBean">        <propertyname="jndiName"><value>jdbc/myapp</value></property>    </bean> 注意dataSource這個bean在dao層(hibernate或jdbc)的配置檔案裡需要作為dataSource名稱的屬性配置到所有bean中其中“jdbc/myds”這個就是jndi名稱了，下一步就是在應用伺服器連線池裡進行資料庫連線以及對應的jndi配置了一 開源資料連線池 1 dbcp dbcp可能是使用最多的開源連線池，原因大概是因為配置方便，而且很多開源和tomcat應用例子都是使用的這個連線池吧。這個連線池可以設定最大和最小連線，連線等待時間等，基本功能都有。這個連線池的配置參見附件壓縮包中的:dbcp.xml 使用評價：在具體專案應用中，發現此連線池的持續執行的穩定性還是可以，不過速度稍慢，在大併發量的壓力下穩定性有所下降，此外不提供連線池監控 2 c3p0 c3p0是另外一個開源的連線池，在業界也是比較有名的，這個連線池可以設定最大和最小連線，連線等待時間等，基本功能都有。這個連線池的配置參見附件壓縮包中的:c3p0.xml。使用評價：在具體專案應用中，發現此連線池的持續執行的穩定性相當不錯，在大併發量的壓力下穩定性也有一定保證，          此外不提供連線池監控。           3 proxool proxool這個連線池可能用到的人比較少，但也有一定知名度，這個連線池可以設定最大和最小連線，連線等待時間等，基本功能都有。這個連線池的配置參見附件壓縮包中的：proxool.xml。使用評價：在具體專案應用中，發現此連線池的持續執行的穩定性有一定問題，有一個需要長時間跑批的任務場景任務，同樣的程式碼在另外2個開源連線池中成功結束，但在proxool中出現異常退出。但是proxool有一個優勢--連線池監控，這是個很誘人的東西，大概的配置方式就是在web.xml中新增如下定義：    <servlet>        <servlet-name>admin</servlet-name>        <servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class>        </servlet>   <servlet-mapping>      <servlet-name>admin</servlet-name>      <url-pattern>/admin</url-pattern>   </servlet-mapping>   並在應用啟動後訪問：http://localhost:8080/myapp/admin這個url即可監控不過proxool本身的包在監測使用中會有編碼問題，附件中有一個解決此問題的包，參見附件壓縮包中的：proxool-0.9.0RC3.jar。另外需要jdk1.5以上的環境。者曾經主持以及經歷的幾個產品及專案中，包括了各種資料庫及應用伺服器，基本上幾種常見的資料庫連線池都用到了，根據使用的情況把這些連線池比較一下吧。感覺在介紹之前有必要闡述一下連線池的幾個概念，有助於後邊一些文字的理解。最原始的資料庫使用就是開啟一個連線並進行使用，使用過後一定要關閉連線釋放資源。由於頻繁的開啟和關閉連線對jvm包括資料庫都有一定的資源負荷，尤其應用壓力較大時資源佔用比較多容易產生效能問題。由此使用連線池的作用就顯現出來，他的原理其實不復雜：先開啟一定數量的資料庫連線，當使用的時候分配給呼叫者，呼叫完畢後返回給連線池，注意返回給連線池後這些連線並不會關閉，而是準備給下一個呼叫者進行分配。由此可以看出連線池節省了大量的資料庫連線開啟和關閉的動作，對系統性能提升的益處不言而喻。幾個概念：最小連線--應用啟動後隨即開啟的連線數以及後續最小維持的連線數。最大連線數--應用能夠使用的最多的連線數連線增長數--應用每次新開啟的連線個數舉個例子說明連線池的運作：假設設定了最小和最大的連線為10，20，那麼應用一旦啟動則首先開啟10個數據庫連線，但注意此時資料庫連線池的正在使用數字為0--因為你並沒有使用這些連線，而空閒的數量則是10。然後你開始登入，假設登入程式碼使用了一個連線進行查詢，那麼此時資料庫連線池的正在使用數字為1、空閒數為9，這並不需要從資料庫開啟連線--因為連線池已經準備好了10個給你留著呢。登入結束了，當前連線池的連線數量是多少？當然是0，因為那個連線隨著事務的結束已經返還給連線池了。然後同時有11個人在同一秒進行登入，會發生什麼：連線池從資料庫新申請（開啟）了一個連線，連同另外的10個一併送出，這個瞬間連線池的使用數是11個，不過沒關係正常情況下過一會兒又會變成0。如果同時有21個人登入呢？那第21個人就只能等前面的某個人登入完畢後釋放連線給他。這時連線池開啟了20個數據庫連線--雖然很可能正在使用數量的已經降為0，那麼20個連線會一直保持嗎？當然不，連線池會在一定時間內關閉一定量的連線還給資料庫，在這個例子裡數字是20-10=10，因為只需要保持最小連線數就好了，而這個時間週期也是連線池裡配置的。好了，基本概念說完了，言歸正傳進行比較了。首先說明的一點，為了應用便於移植以及可配置的角度，建議還是使用jndi統一進行連線池的配置。怎麼配置其實網上都有很多例子，這裡簡單舉個例子（使用spring框架）：首先在應用的上下文定義中配置jndi名稱，如一個resource.xml檔案，裡邊的寫法     <bean id="dataSource"class="org.springframework.jndi.JndiObjectFactoryBean">        <propertyname="jndiName"><value>jdbc/myapp</value></property>    </bean> 注意dataSource這個bean在dao層(hibernate或jdbc)的配置檔案裡需要作為dataSource名稱的屬性配置到所有bean中其中“jdbc/myds”這個就是jndi名稱了，下一步就是在應用伺服器連線池裡進行資料庫連線以及對應的jndi配置了一 開源資料連線池 1 dbcp dbcp可能是使用最多的開源連線池，原因大概是因為配置方便，而且很多開源和tomcat應用例子都是使用的這個連線池吧。這個連線池可以設定最大和最小連線，連線等待時間等，基本功能都有。這個連線池的配置參見附件壓縮包中的:dbcp.xml 使用評價：在具體專案應用中，發現此連線池的持續執行的穩定性還是可以，不過速度稍慢，在大併發量的壓力下穩定性有所下降，此外不提供連線池監控 2 c3p0 c3p0是另外一個開源的連線池，在業界也是比較有名的，這個連線池可以設定最大和最小連線，連線等待時間等，基本功能都有。這個連線池的配置參見附件壓縮包中的:c3p0.xml。使用評價：在具體專案應用中，發現此連線池的持續執行的穩定性相當不錯，在大併發量的壓力下穩定性也有一定保證，          此外不提供連線池監控。           3 proxool proxool這個連線池可能用到的人比較少，但也有一定知名度，這個連線池可以設定最大和最小連線，連線等待時間等，基本功能都有。這個連線池的配置參見附件壓縮包中的：proxool.xml。使用評價：在具體專案應用中，發現此連線池的持續執行的穩定性有一定問題，有一個需要長時間跑批的任務場景任務，同樣的程式碼在另外2個開源連線池中成功結束，但在proxool中出現異常退出。但是proxool有一個優勢--連線池監控，這是個很誘人的東西，大概的配置方式就是在web.xml中新增如下定義：    <servlet>        <servlet-name>admin</servlet-name>        <servlet-class>org.logicalcobwebs.proxool.admin.servlet.AdminServlet</servlet-class>        </servlet>   <servlet-mapping>      <servlet-name>admin</servlet-name>      <url-pattern>/admin</url-pattern>   </servlet-mapping>   並在應用啟動後訪問：http://localhost:8080/myapp/admin這個url即可監控不過proxool本身的包在監測使用中會有編碼問題，附件中有一個解決此問題的包，參見附件壓縮包中的：proxool-0.9.0RC3.jar。另外需要jdk1.5以上的環境。總結時刻：綜上所述，這幾種開源連線池各有優劣，推薦使用c3p0，經檢驗這種連線池效能穩定，承壓能力強。而proxool儘管有明顯的效能問題，但由於它具備監控功能，因此建議在開發測試時使用，有助於確定是否有連線沒有被關掉，可以排除一些程式碼的效能問題。二 商業中介軟體連線池上面列舉了幾種開源的連線池，其實可以肯定的說，如果條件允許使用weblogic和websphere等中介軟體，那麼不要猶豫，一定要使用這些商業級別的中介軟體所自帶的資料庫連線池，他們的效能以及調配和開源的不在一個量級，舉個例子，曾經有一個專案，資料量比較大，同樣的程式碼應用，在3種開源的連線池裡都多少出現過系統異常，而weblogic和websphere的連線池則正常執行，當然後來發現程式碼有一定瑕疵，但也側面說明了商業連線池的強大。 1 weblogic的連線池 weblogic 8是一個讓人使用起來很輕鬆方便的應用伺服器軟體，但是到了9簡直就是折磨，不知道是bea是怎麼想的，oracle收購了bea以後出了10，比9強不少，但是最喜歡的還是8。。。題外話不說了，就以8.1版本介紹一下他的資料庫連線池（其實10的配置也差不多）首先是連線池的基本設定，這個不講了，網上有很多教程。然後進入Data Sources選單配置資料來源裡邊的JNDIName，要和之前在應用配置中的一致：jdbc/myapp。然後是連線池一些具體專案的配置，包括設定最小（Initial Capacity），最大（ MaximumCapacity）連線，以及每次連線增加時需要一次性增加多少連線（Capacity Increment）。AllowShrinking（是否把不用的連線退還資料庫以保持最小連線數--這個就可以參見之前的連線池闡述的例子進行理解了）。另外還有幾個有意思的選項Test Reserved Connections：對取得的連線進行測試，Test ReleasedConnections：對釋放的連線進行測試。有人會問了，這個有什麼用啊？不知道大家在專案中有沒有遇到java報連線失效的異常，反正我碰到過，只有在系統壓力大的時候才出現。而有了這個選項就不用擔心這個問題了--因為連線池已經幫你測試了，一旦檢查到連線是無效的他會廢棄掉還給資料庫，只給你有效的。不過這個連線失效的異常其實多半是應用的不嚴謹造成的，我們更因該關心應程式碼的問題--但起碼weblogic想到幫你彌補一下，是不是很貼心：）另外一個重要功能當然是連線池監控：monitor選項卡里可以看到使用情況，有人又要問了，沒有什麼指標啊，別忘了customview這個功能連結哦：）有以下指標：當前連線數、曾經達到的峰值、可以使用的連線數、等待的連線數、從資料庫開啟的連線數、曾經關閉的連線數。。。其中前3項是我最關注的使用評價：在具體專案應用中，此連線池的持續執行的穩定性很強，在大併發量的壓力下效能也相當優秀，另外在一些異常情況下連線池裡的連線也能夠及時釋放。          連線池監控一目瞭然，及時到位。         2 websphere的連線池還是先來段題外話：記得有人說過，websphere只有版本6以後才算是websphere，個人很贊同。websphere5以及以前的版本。。。還是忘了吧。其實websphere的連線池秉承ibm一貫的風格：功能強大，使用複雜：）進入控制檯使用“JDBC提供程式”功能選單進行連線池的基本配置，一路下來，不同的資料庫配置方式不盡相同，最奇怪的是還要單獨手工加上user和password引數，如果沒有資料指導的話還真是摸不著頭腦。這些基本設定還是網上找吧很多的。連線池設定完還需要設定資料來源，jndi名字一樣與之前的對應：jdbc/myapp 高階設定包括初始化連線數，最大連線，連線有效性檢查，不使用超時。。其實這些都和weblogic中的連線池配置大致一樣。連線池監控：使用執行監控選單，裡邊會有一個監控專案選擇，選jdbc監控即可，可惡的是一開始彈出什麼伺服器作業系統需要安裝什麼圖形化控制元件，選擇是那麼就得去找到控制元件在作業系統（linux）下安裝，然後很多的依賴元件都沒有。。。搞了半天才發現選擇否，監控資料以及圖形一樣能出來嘛，真是要怒了。雖然經過一番波折但是監控的內容還是很強大的，就連線池來說一樣包括當前連線數、曾經達到的峰值、可以使用的連線數、從資料庫開啟的連線數、曾經關閉的連線數。。。其中前3項是我最關注的，比較奇怪的現象是應用剛啟動的時候已開啟的連線數量竟然沒有達到初始定義的連線數量，不清楚websphere是怎麼個計算機制。另外在壓力大的時候可使用的連線數會是負數，當時很奇怪，想想也瞭然了，那個負數肯定是排隊等待的數量了使用評價：在具體專案應用中，此連線池的持續執行的穩定性相當強，在大併發量的壓力下效能也足夠優秀，另外在一些異常情況下連線池裡的連線能夠及時釋放，          連線池監控配置有些複雜，但是配置好後各項指標一目瞭然並且有圖形顯示            總結時刻：這兩種商業級別的連線池都給我留下深刻印象，功能強大，使用穩定，效能優秀，監控到位。可以說難分伯仲，相對而言weblogic的連線池使用配置和監控配置更簡單明瞭，而websphere的更復雜但選項功能也更多一些。其實這正是對兩種應用伺服器的使用印象的直接反映，當然總體比較2種應用伺服器應該又是另一個話題了，也許在下一期的內容裡。。。比較了多種連線池的優劣，下面這個話題可能和比較本身沒有直接關係，但個人認為應該是更有價值的一些經驗分享吧，那就是---這麼多指標配置，那些最大和最小連線數以及其他一些必要的配置指標，在一個正式的生產專案中到底應該配置什麼值呢？其實這個值首先還是要根據具體的專案情況、資料規模以及併發數來制定的(儘管像是套話，但是我們研發人員嚴謹的作風還是必要的:)。具體而言在中型偏小型的專案--給個數值把，使用者數300到3000，資料量100萬到1億---中,建議weblogic設定為最大和最小都是200，websphere最小200最大300，前提是2者設定的最小記憶體要在1G以上，當然如果條件允許記憶體越大越好，不過32位機記憶體1.5G的限制是一定的（64位嘛我願意設個4G記憶體過來，速度提升的感覺很爽啊）。這個數字出來以後相信會有不少問題要拋過來，我一一談一下自己的體驗和想法吧 1 為什麼是200或300而不是更高？回答： 再分配多了效果也不大了，一個是應用伺服器維持這個連線數需要記憶體支援，剛才說了32位的機器只能支援到1.5G，並且維護大量的連線進行分配使用對cpu也是一個不小的負荷，因此不宜太大。 2 為什麼不小一點？回答：  如果太小，那麼在上述規模專案的併發量以及資料量上來以後會造成排隊現象，系統會變慢，資料庫連線會經常開啟和關閉，效能上有壓力，使用者體驗也不好。 3 為什麼weblogic最小最大都一樣，而websphere不一樣回答：  其實和分配記憶體的最小最大值的情況一樣，一般都推薦2個值應該一致，都放在記憶體裡就好了嘛。但是ibm官方推薦2個值要有區別---官方說法還是要聽的 4 其他開源連線池的分配方案還沒說呢？回答： 開源的個人認為到100就可以了，再高他也不會太穩定，當然1G的最小記憶體是一定要給tomcat分的 5 還有其他的指標嗎？回答： 當然還有一些，但個人認為剩下的具體情況具體分析了不在這裡一一列舉了，大家有興趣可以和我討論分享一下。林林總總說了不少希望對大家有幫助，這些比較分析和資料都具備實際應用支撐。總結時刻：綜上所述，這幾種開源連線池各有優劣，推薦使用c3p0，經檢驗這種連線池效能穩定，承壓能力強。而proxool儘管有明顯的效能問題，但由於它具備監控功能，因此建議在開發測試時使用，有助於確定是否有連線沒有被關掉，可以排除一些程式碼的效能問題。二 商業中介軟體連線池上面列舉了幾種開源的連線池，其實可以肯定的說，如果條件允許使用weblogic和websphere等中介軟體，那麼不要猶豫，一定要使用這些商業級別的中介軟體所自帶的資料庫連線池，他們的效能以及調配和開源的不在一個量級，舉個例子，曾經有一個專案，資料量比較大，同樣的程式碼應用，在3種開源的連線池裡都多少出現過系統異常，而weblogic和websphere的連線池則正常執行，當然後來發現程式碼有一定瑕疵，但也側面說明了商業連線池的強大。 1 weblogic的連線池 weblogic 8是一個讓人使用起來很輕鬆方便的應用伺服器軟體，但是到了9簡直就是折磨，不知道是bea是怎麼想的，oracle收購了bea以後出了10，比9強不少，但是最喜歡的還是8。。。題外話不說了，就以8.1版本介紹一下他的資料庫連線池（其實10的配置也差不多）首先是連線池的基本設定，這個不講了，網上有很多教程。然後進入Data Sources選單配置資料來源裡邊的JNDIName，要和之前在應用配置中的一致：jdbc/myapp。然後是連線池一些具體專案的配置，包括設定最小（Initial Capacity），最大（ MaximumCapacity）連線，以及每次連線增加時需要一次性增加多少連線（Capacity Increment）。AllowShrinking（是否把不用的連線退還資料庫以保持最小連線數--這個就可以參見之前的連線池闡述的例子進行理解了）。另外還有幾個有意思的選項Test Reserved Connections：對取得的連線進行測試，Test ReleasedConnections：對釋放的連線進行測試。有人會問了，這個有什麼用啊？不知道大家在專案中有沒有遇到java報連線失效的異常，反正我碰到過，只有在系統壓力大的時候才出現。而有了這個選項就不用擔心這個問題了--因為連線池已經幫你測試了，一旦檢查到連線是無效的他會廢棄掉還給資料庫，只給你有效的。不過這個連線失效的異常其實多半是應用的不嚴謹造成的，我們更因該關心應程式碼的問題--但起碼weblogic想到幫你彌補一下，是不是很貼心：）另外一個重要功能當然是連線池監控：monitor選項卡里可以看到使用情況，有人又要問了，沒有什麼指標啊，別忘了customview這個功能連結哦：）有以下指標：當前連線數、曾經達到的峰值、可以使用的連線數、等待的連線數、從資料庫開啟的連線數、曾經關閉的連線數。。。其中前3項是我最關注的使用評價：在具體專案應用中，此連線池的持續執行的穩定性很強，在大併發量的壓力下效能也相當優秀，另外在一些異常情況下連線池裡的連線也能夠及時釋放。          連線池監控一目瞭然，及時到位。         2 websphere的連線池還是先來段題外話：記得有人說過，websphere只有版本6以後才算是websphere，個人很贊同。websphere5以及以前的版本。。。還是忘了吧。其實websphere的連線池秉承ibm一貫的風格：功能強大，使用複雜：）進入控制檯使用“JDBC提供程式”功能選單進行連線池的基本配置，一路下來，不同的資料庫配置方式不盡相同，最奇怪的是還要單獨手工加上user和password引數，如果沒有資料指導的話還真是摸不著頭腦。這些基本設定還是網上找吧很多的。連線池設定完還需要設定資料來源，jndi名字一樣與之前的對應：jdbc/myapp 高階設定包括初始化連線數，最大連線，連線有效性檢查，不使用超時。。其實這些都和weblogic中的連線池配置大致一樣。連線池監控：使用執行監控選單，裡邊會有一個監控專案選擇，選jdbc監控即可，可惡的是一開始彈出什麼伺服器作業系統需要安裝什麼圖形化控制元件，選擇是那麼就得去找到控制元件在作業系統（linux）下安裝，然後很多的依賴元件都沒有。。。搞了半天才發現選擇否，監控資料以及圖形一樣能出來嘛，真是要怒了。雖然經過一番波折但是監控的內容還是很強大的，就連線池來說一樣包括當前連線數、曾經達到的峰值、可以使用的連線數、從資料庫開啟的連線數、曾經關閉的連線數。。。其中前3項是我最關注的，比較奇怪的現象是應用剛啟動的時候已開啟的連線數量竟然沒有達到初始定義的連線數量，不清楚websphere是怎麼個計算機制。另外在壓力大的時候可使用的連線數會是負數，當時很奇怪，想想也瞭然了，那個負數肯定是排隊等待的數量了使用評價：在具體專案應用中，此連線池的持續執行的穩定性相當強，在大併發量的壓力下效能也足夠優秀，另外在一些異常情況下連線池裡的連線能夠及時釋放，          連線池監控配置有些複雜，但是配置好後各項指標一目瞭然並且有圖形顯示            總結時刻：這兩種商業級別的連線池都給我留下深刻印象，功能強大，使用穩定，效能優秀，監控到位。可以說難分伯仲，相對而言weblogic的連線池使用配置和監控配置更簡單明瞭，而websphere的更復雜但選項功能也更多一些。其實這正是對兩種應用伺服器的使用印象的直接反映，當然總體比較2種應用伺服器應該又是另一個話題了，也許在下一期的內容裡。。。比較了多種連線池的優劣，下面這個話題可能和比較本身沒有直接關係，但個人認為應該是更有價值的一些經驗分享吧，那就是---這麼多指標配置，那些最大和最小連線數以及其他一些必要的配置指標，在一個正式的生產專案中到底應該配置什麼值呢？其實這個值首先還是要根據具體的專案情況、資料規模以及併發數來制定的(儘管像是套話，但是我們研發人員嚴謹的作風還是必要的:)。具體而言在中型偏小型的專案--給個數值把，使用者數300到3000，資料量100萬到1億---中,建議weblogic設定為最大和最小都是200，websphere最小200最大300，前提是2者設定的最小記憶體要在1G以上，當然如果條件允許記憶體越大越好，不過32位機記憶體1.5G的限制是一定的（64位嘛我願意設個4G記憶體過來，速度提升的感覺很爽啊）。這個數字出來以後相信會有不少問題要拋過來，我一一談一下自己的體驗和想法吧 1 為什麼是200或300而不是更高？回答： 再分配多了效果也不大了，一個是應用伺服器維持這個連線數需要記憶體支援，剛才說了32位的機器只能支援到1.5G，並且維護大量的連線進行分配使用對cpu也是一個不小的負荷，因此不宜太大。 2 為什麼不小一點？回答：  如果太小，那麼在上述規模專案的併發量以及資料量上來以後會造成排隊現象，系統會變慢，資料庫連線會經常開啟和關閉，效能上有壓力，使用者體驗也不好。 3 為什麼weblogic最小最大都一樣，而websphere不一樣回答：  其實和分配記憶體的最小最大值的情況一樣，一般都推薦2個值應該一致，都放在記憶體裡就好了嘛。但是ibm官方推薦2個值要有區別---官方說法還是要聽的 4 其他開源連線池的分配方案還沒說呢？回答： 開源的個人認為到100就可以了，再高他也不會太穩定，當然1G的最小記憶體是一定要給tomcat分的 5 還有其他的指標嗎？回答： 當然還有一些，但個人認為剩下的具體情況具體分析了不在這裡一一列舉了，大家有興趣可以和我討論分享一下。林林總總說了不少希望對大家有幫助，這些比較分析和資料都具備實際應用支撐。