初識高速緩存和連接池

設(shè)想這樣一種情形：你突然口渴，需要一杯水來緩解，從心情上來講，當然是越快越好了。通常，一杯水的產(chǎn)生包括從水源（井水、河水或江水、甚至海水等）抽取，通過管道傳輸和設(shè)備凈化，才到達你飲水的容器中。上述過程是必須的，但并不是每一杯水的產(chǎn)生都必須把上述過程重復(fù)一次。你可以用一個大一點的容器（例如缸或罐等）來盛大量的水，喝水之前分到杯子小部分中即可，你的代價只是把水從缸轉(zhuǎn)移到杯子；你還可以在大量用水（例如洗澡或洗衣服等）時，只需打開水閥，而不必臨時鋪設(shè)通往水源的管道和購買凈化水的設(shè)備。因為水是人們生活不可缺少的東西，每時每刻都在被大量地使用，而且物理本質(zhì)也完全相同，所以政府會鋪設(shè)管道和建設(shè)水處理站，完成那些比較困難的工作，達到資源共享的目的，而你也可針對自己的需求，用容器來盛那些具有特定用途的水。本文將要和你討論的高速緩存和連接池與上述特定容器和傳輸管道有很多相似之處，它們都達到了同一個目的：在滿足用戶意愿的前提下，盡可能地共享資源，以提高整個系統(tǒng)的性能。

高速緩存和連接池是數(shù)據(jù)訪問中的重要技術(shù)，某些情況下的應(yīng)用對訪問數(shù)據(jù)庫的性能有巨大的提高，而且都得到了數(shù)據(jù)庫業(yè)界的普遍支持。前者由DBMS廠商針對自己的數(shù)據(jù)庫實現(xiàn)，提供可供用戶配置的方案；后者是JDBC的一個標準接口，由支持J2EE技術(shù)的應(yīng)用服務(wù)器廠商提供具體的實現(xiàn)，而你的Java程序代碼無需更改。本文將向你簡單介紹高速緩存和連接池的概念和機制，并以PointBase數(shù)據(jù)庫為例向你展示高速緩存的應(yīng)用，而一個簡單的連接池應(yīng)用場景將向你描述應(yīng)用的條件和提高的性能。

Cache（高速緩存）和Connection Pool（連接池）的概念和機制

它們不是數(shù)據(jù)庫獨有的技術(shù)，但卻得到數(shù)據(jù)庫業(yè)界的普遍支持，并在其它數(shù)據(jù)存取和對象復(fù)用領(lǐng)域有很多類似的應(yīng)用。

Cache（高速緩存）
作為個人計算機的日常使用者，你肯定聽說過這些名詞：Cache（高速緩存）、Memory（內(nèi)存）、Hard disk（硬盤）。它們都是數(shù)據(jù)存取單元，但存取速度卻有很大差異，呈依次遞減的順序。對于CPU來說，它可以從距離自己最近的Cache高速地存取數(shù)據(jù)，而不是從內(nèi)存和硬盤以低幾個數(shù)量級的速度來存取數(shù)據(jù)。而Cache中所存儲的數(shù)據(jù)，往往是CPU要反復(fù)存取的數(shù)據(jù)，有特定的機制（或程序）來保證Cache內(nèi)數(shù)據(jù)的命中率（Hit Rate）。因此，CPU存取數(shù)據(jù)的速度在應(yīng)用高速緩存后得到了巨大的提高。

對于數(shù)據(jù)庫來說，廠商的做法往往是在內(nèi)存中開辟相應(yīng)的區(qū)域來存儲可能被多次存取的數(shù)據(jù)和可能被多次執(zhí)行的語句，以使這些數(shù)據(jù)在下次被訪問時不必再次提交對DBMS的請求和那些語句在下次執(zhí)行時不必再次編譯。

因為將數(shù)據(jù)寫入高速緩存的任務(wù)由Cache Manager負責(zé)，所以對用戶來說高速緩存的內(nèi)容肯定是只讀的。需要你做的工作很少，程序中的SQL語句和直接訪問DBMS時沒有分別，返回的結(jié)果也看不出有什么差別。而數(shù)據(jù)庫廠商往往會在DB Server的配置文件中提供與Cache相關(guān)的參數(shù)，通過修改它們，可針對我們的應(yīng)用優(yōu)化Cache的管理。下圖是在Win2K中配置MS Access數(shù)據(jù)源的界面，在"驅(qū)動程序"部分你可設(shè)置的頁超時和緩沖區(qū)大小就是和Cache有關(guān)的參數(shù)。在后面的討論中，我將展示一個更復(fù)雜的數(shù)據(jù)庫，向你解釋Cache對訪問數(shù)據(jù)庫性能的影響和如何尋找最優(yōu)的配置方案。

Connection Pool（連接池）

池是一個很普遍的概念，和緩沖存儲有機制相近的地方，都是縮減了訪問的環(huán)節(jié)，但它更注重于資源的共享。下圖展示了建立"調(diào)制解調(diào)器池"以共享調(diào)制解調(diào)器資源的VPN撥號方案：

對于訪問數(shù)據(jù)庫來說，建立連接的代價比較昂貴，因此，我們有必要建立"連接池"以提高訪問的性能。我們可以把連接當作對象或者設(shè)備，池中又有許多已經(jīng)建立的連接，訪問本來需要與數(shù)據(jù)庫的連接的地方，都改為和池相連，池臨時分配連接供訪問使用，結(jié)果返回后，訪問將連接交還。

JDBC 1.0標準及其擴展中沒有定義連接池，而在JDBC 2.0標準的擴展中定義了與連接池相關(guān)的接口。與接口對應(yīng)的類由應(yīng)用服務(wù)器廠商實現(xiàn)，你可在對服務(wù)器的管理過程中調(diào)節(jié)某個數(shù)據(jù)庫連接池的參數(shù)。下圖簡略地描述了連接池的運行機制：

高速緩存的參數(shù)設(shè)定

在PointBase數(shù)據(jù)庫DB Server的配置參數(shù)列表中，我們可以找到這幾個參數(shù)：cache.checkpointinterval、cache.size、SQLCaching.size等。下表是對各個參數(shù)的描述：

參數(shù)名 參數(shù)描述
cache.checkpointinterval 檢查點的時間間隔
cache.size 高速緩存的最大頁數(shù)（素數(shù)時，性能最好）
SQLCaching.size 高速緩存中SQL語句的個數(shù)

對于cache.checkpointinterval來說，和前面Access界面中的頁超時是一個概念，它指定了頁面內(nèi)容更新的時間間隔，這取決于你的應(yīng)用對時效性的要求程度。

對于cache.size來說，指定了頁面的個數(shù)，一般應(yīng)設(shè)定為符合你查詢結(jié)果的需求。至于為何是素數(shù)，我也納悶，不過還是遵照廠商的指示吧。

對于SQLCaching.size來說，指定了存儲的經(jīng)過編譯的SQL語句的個數(shù)，你可以把它設(shè)定為0，從而取消這個選項。

使用Cache后，性能到底有多大提高？我打開PointBase的Console通過JDBC驅(qū)動訪問Server，將SQL菜單下的Timing Mode選上，以顯示各個步驟的耗費時間。執(zhí)行語句是：

SELECT * FROM PRODUCT_TBL

?

?

第一次訪問，總計耗時1082毫秒，而編譯耗時771毫秒。

緊接著的第二次訪問，總計耗時僅為160毫秒，而編譯耗時為0。

再接著的第三次訪問，總計耗時僅為91毫秒，編譯耗時也為0。

關(guān)閉Console，等待超過30秒之后，重新開啟Console，執(zhí)行相同的語句，總計耗時210毫秒，編譯耗時為20毫秒。

自等待超過30秒之后，執(zhí)行語句，總計耗時101毫秒，編譯耗時為0。

由此可以看出，高速緩存的應(yīng)用大大提高了訪問數(shù)據(jù)庫的性能，而其參數(shù)的設(shè)定則要依據(jù)前面對它們的描述來進行，需要你仔細閱讀數(shù)據(jù)庫的配置文檔。

連接池的設(shè)置和應(yīng)用

我選擇IBM公司的應(yīng)用服務(wù)器平臺WebSphere來給大家演示連接池的設(shè)置，使你面對友好的Web界面，可以體驗到非常簡易的操作場景。

首先，我們進入WebSphere的管理控制臺，這是一個非常漂亮的Web界面：

緊接著，我選定一個數(shù)據(jù)源：Session Persistence datasource，就可看到這個數(shù)據(jù)源的屬性配置了。在這兒，僅僅列舉和連接池有關(guān)的屬性：

Minimum Pool Size 池中保持的連接的最小數(shù)目；有新的請求，且沒有激活連接可供使用時，池中連接數(shù)將增大，到最大連接數(shù)為止
Maximum Pool Size 池中保持的連接的最大數(shù)目；當這個數(shù)目達到，且沒有激活連接可供使用時，新的請求將等待
Connection Timeout 當連接數(shù)達到最大值，且激活連接都在被使用時，新的請求等待的時間
Idle Timeout 連接可在池中閑置的時間；超過將釋放資源，到最小連接數(shù)為止
Orphan Timeout 連接在被應(yīng)用控制時，可閑置的時間；超過將返回池中

你可以根據(jù)需要來修改這些數(shù)值，以滿足你的應(yīng)用需要。接下來，我們討論一下連接池的應(yīng)用。

EJB訪問數(shù)據(jù)庫（場景1，使用JDBC 1.0） import java.sql.*;
import javax.sql.*;
...
public class AccountBean implements EntityBean {
...
public Collection ejbFindByLastName(String lName) {
try {
String dbdriver = new initialContext().lookup("java:comp/env/DBDRIVER").toString();
Class.forName(dbdriver).newInstance();
Connection conn = null;
conn = DriverManager.getConnection("java:comp/env/DBURL", "userID", "password");
...
conn.close();
}
...
}

?

?

如果EntityBean是一個共享組件，那么每次客戶請求時，都要建立和釋放與數(shù)據(jù)庫的連接，這成為影響性能的主要問題。

EJB訪問數(shù)據(jù)庫（場景2，使用JDBC 2.0） import java.sql.*;
import javax.sql.*;
// import here vendor specific JDBC drivers

public ProductPK ejbCreate() {
try {
// initialize JNDI lookup parameters
Context ctx = new InitialContext(parms);
...
ConnectionPoolDataSource cpds = (ConnectionPoolDataSource)ctx.lookup(cpsource);
...
// Following parms could all come from a JNDI look-up
cpds.setDatabaseName("PTDB");
cpds.setUserIF("XYZ");
...
PooledConnection pc = cpds.getPooledConnection();
Connection conn = pc.getConnection();
...
// do business logic
conn.close();
}
...
}
EJB組件利用JNDI的lookup()方法定位數(shù)據(jù)庫的連接池資源，利用getConnection()方法得到已經(jīng)打開的數(shù)據(jù)庫連接，而用close()來釋放連接，放回池中。因此，與場景1相比，少了與數(shù)據(jù)庫建立物理連接的損耗。對于原本要頻繁打開和關(guān)閉物理連接的應(yīng)用來說，通過這種建立邏輯連接并復(fù)用的方法，性能肯定能夠得到大幅度提高。

性能問題的深遠思索

性能問題并不局限于數(shù)據(jù)庫的應(yīng)用上，而是存在于每個軟件系統(tǒng)中。我們希望軟件系統(tǒng)付出的最小，而獲得的最大，因而無時無刻不在優(yōu)化它們。通過《Java程序訪問數(shù)據(jù)庫的速度瓶頸問題的分析和解決》和本文，我對Java程序訪問數(shù)據(jù)庫的性能問題做了分析，并提供了優(yōu)化Java程序的解決方案，希望對你有所幫助。

也許你會關(guān)心碰到類似的性能問題時應(yīng)如何分析和解決，我就針對此次探討"訪問數(shù)據(jù)庫的速度瓶頸"問題的過程中碰到的難題、網(wǎng)友的意見和自己的體會，作一個關(guān)于"方法論"的經(jīng)驗總結(jié)，希望能夠拋磚引玉，更好地解決類似的問題。

解決性能問題的幾條經(jīng)驗

不要讓硬件的低配置成為軟件正常運行的障礙，后者有升級前者的需求，請立即滿足；經(jīng)常碰到這樣的問題"P166+64M的機子跑Win2K+MySql+JBoss，能跑么？"我在回答"可以"的同時只有對著屏幕發(fā)呆了。
盡量使用商業(yè)軟件，并享受良好的售后技術(shù)支持；如果你沒有黑客精神，請不要使用自由軟件。
分析好自己的問題，也許它的本質(zhì)和他人的不同；沒有一把鑰匙可打開的任一把鎖。
確定瓶頸環(huán)節(jié)的位置；解決了瓶頸問題，往往整個的性能問題就解決了，千萬不要抓著邊緣的問題不放。
將瓶頸環(huán)節(jié)細分為多個順序的流程，用逐個替代的方法來試探瓶頸的核心位置；細分問題使你都問題有更進一步的了解。
做自己能做的和該做的事情，始終面向自己的現(xiàn)實問題；不要嘗試那些應(yīng)該由廠商解決的問題（例如，自己寫個JDBC驅(qū)動）。
他人的方案只供自己參考，解決要靠自己思考；你我應(yīng)用的情形不同，應(yīng)用解決方案要在理解他人的方案之后。
觀察新技術(shù)，應(yīng)用新技術(shù)；它往往包含了前人對問題解決的思路，只是對你來說不可見。
問題得到解決后，立即罷手，并匯報結(jié)果；在現(xiàn)實問題得到解決后，沒有必要花費精力在非核心的問題上，也許它們永遠不會被碰到，不要假想問題讓自己解決。
上述經(jīng)驗為個人即興的總結(jié)，并未有嚴謹?shù)倪壿嬐茖?dǎo)，僅代表我解決技術(shù)問題的思路，供你碰到類似問題時參考。

可以提前告訴大家的是，下一篇文章我將把主題轉(zhuǎn)移到JDO的介紹和討論上。這個陌生的API已經(jīng)進入Final Draft了，可它到底能夠給數(shù)據(jù)存取帶來什么好處，和JDBC有什么關(guān)聯(lián)的地方，《JDO（Java Data Object）的發(fā)展和介紹》將向你娓娓道來。

初識高速緩存和連接池

設(shè)想這樣一種情形：你突然口渴，需要一杯水來緩解，從心情上來講，當然是越快越好了。通常，一杯水的產(chǎn)生包括從水源（井水、河水或江水、甚至海水等）抽取，通過管道傳輸和設(shè)備凈化，才到達你飲水的容器中。上述過程是必須的，但并不是每一杯水的產(chǎn)生都必須把上述過程重復(fù)一次。你可以用一個大一點的容器（例如缸或罐等）來盛大量的水，喝水之前分到杯子小部分中即可，你的代價只是把水從缸轉(zhuǎn)移到杯子；你還可以在大量用水（例如洗澡或洗衣服等）時，只需打開水閥，而不必臨時鋪設(shè)通往水源的管道和購買凈化水的設(shè)備。因為水是人們生活不可缺少的東西，每時每刻都在被大量地使用，而且物理本質(zhì)也完全相同，所以政府會鋪設(shè)管道和建設(shè)水處理站，完成那些比較困難的工作，達到資源共享的目的，而你也可針對自己的需求，用容器來盛那些具有特定用途的水。本文將要和你討論的高速緩存和連接池與上述特定容器和傳輸管道有很多相似之處，它們都達到了同一個目的：在滿足用戶意愿的前提下，盡可能地共享資源，以提高整個系統(tǒng)的性能。

高速緩存和連接池是數(shù)據(jù)訪問中的重要技術(shù)，某些情況下的應(yīng)用對訪問數(shù)據(jù)庫的性能有巨大的提高，而且都得到了數(shù)據(jù)庫業(yè)界的普遍支持。前者由DBMS廠商針對自己的數(shù)據(jù)庫實現(xiàn)，提供可供用戶配置的方案；后者是JDBC的一個標準接口，由支持J2EE技術(shù)的應(yīng)用服務(wù)器廠商提供具體的實現(xiàn)，而你的Java程序代碼無需更改。本文將向你簡單介紹高速緩存和連接池的概念和機制，并以PointBase數(shù)據(jù)庫為例向你展示高速緩存的應(yīng)用，而一個簡單的連接池應(yīng)用場景將向你描述應(yīng)用的條件和提高的性能。

Cache（高速緩存）和Connection Pool（連接池）的概念和機制

它們不是數(shù)據(jù)庫獨有的技術(shù)，但卻得到數(shù)據(jù)庫業(yè)界的普遍支持，并在其它數(shù)據(jù)存取和對象復(fù)用領(lǐng)域有很多類似的應(yīng)用。

Cache（高速緩存）
作為個人計算機的日常使用者，你肯定聽說過這些名詞：Cache（高速緩存）、Memory（內(nèi)存）、Hard disk（硬盤）。它們都是數(shù)據(jù)存取單元，但存取速度卻有很大差異，呈依次遞減的順序。對于CPU來說，它可以從距離自己最近的Cache高速地存取數(shù)據(jù)，而不是從內(nèi)存和硬盤以低幾個數(shù)量級的速度來存取數(shù)據(jù)。而Cache中所存儲的數(shù)據(jù)，往往是CPU要反復(fù)存取的數(shù)據(jù)，有特定的機制（或程序）來保證Cache內(nèi)數(shù)據(jù)的命中率（Hit Rate）。因此，CPU存取數(shù)據(jù)的速度在應(yīng)用高速緩存后得到了巨大的提高。

對于數(shù)據(jù)庫來說，廠商的做法往往是在內(nèi)存中開辟相應(yīng)的區(qū)域來存儲可能被多次存取的數(shù)據(jù)和可能被多次執(zhí)行的語句，以使這些數(shù)據(jù)在下次被訪問時不必再次提交對DBMS的請求和那些語句在下次執(zhí)行時不必再次編譯。

因為將數(shù)據(jù)寫入高速緩存的任務(wù)由Cache Manager負責(zé)，所以對用戶來說高速緩存的內(nèi)容肯定是只讀的。需要你做的工作很少，程序中的SQL語句和直接訪問DBMS時沒有分別，返回的結(jié)果也看不出有什么差別。而數(shù)據(jù)庫廠商往往會在DB Server的配置文件中提供與Cache相關(guān)的參數(shù)，通過修改它們，可針對我們的應(yīng)用優(yōu)化Cache的管理。下圖是在Win2K中配置MS Access數(shù)據(jù)源的界面，在"驅(qū)動程序"部分你可設(shè)置的頁超時和緩沖區(qū)大小就是和Cache有關(guān)的參數(shù)。在后面的討論中，我將展示一個更復(fù)雜的數(shù)據(jù)庫，向你解釋Cache對訪問數(shù)據(jù)庫性能的影響和如何尋找最優(yōu)的配置方案。

Connection Pool（連接池）

池是一個很普遍的概念，和緩沖存儲有機制相近的地方，都是縮減了訪問的環(huán)節(jié)，但它更注重于資源的共享。下圖展示了建立"調(diào)制解調(diào)器池"以共享調(diào)制解調(diào)器資源的VPN撥號方案：

對于訪問數(shù)據(jù)庫來說，建立連接的代價比較昂貴，因此，我們有必要建立"連接池"以提高訪問的性能。我們可以把連接當作對象或者設(shè)備，池中又有許多已經(jīng)建立的連接，訪問本來需要與數(shù)據(jù)庫的連接的地方，都改為和池相連，池臨時分配連接供訪問使用，結(jié)果返回后，訪問將連接交還。

JDBC 1.0標準及其擴展中沒有定義連接池，而在JDBC 2.0標準的擴展中定義了與連接池相關(guān)的接口。與接口對應(yīng)的類由應(yīng)用服務(wù)器廠商實現(xiàn)，你可在對服務(wù)器的管理過程中調(diào)節(jié)某個數(shù)據(jù)庫連接池的參數(shù)。下圖簡略地描述了連接池的運行機制：

高速緩存的參數(shù)設(shè)定

在PointBase數(shù)據(jù)庫DB Server的配置參數(shù)列表中，我們可以找到這幾個參數(shù)：cache.checkpointinterval、cache.size、SQLCaching.size等。下表是對各個參數(shù)的描述：

參數(shù)名 參數(shù)描述
cache.checkpointinterval 檢查點的時間間隔
cache.size 高速緩存的最大頁數(shù)（素數(shù)時，性能最好）
SQLCaching.size 高速緩存中SQL語句的個數(shù)

對于cache.checkpointinterval來說，和前面Access界面中的頁超時是一個概念，它指定了頁面內(nèi)容更新的時間間隔，這取決于你的應(yīng)用對時效性的要求程度。

對于cache.size來說，指定了頁面的個數(shù)，一般應(yīng)設(shè)定為符合你查詢結(jié)果的需求。至于為何是素數(shù)，我也納悶，不過還是遵照廠商的指示吧。

對于SQLCaching.size來說，指定了存儲的經(jīng)過編譯的SQL語句的個數(shù)，你可以把它設(shè)定為0，從而取消這個選項。

使用Cache后，性能到底有多大提高？我打開PointBase的Console通過JDBC驅(qū)動訪問Server，將SQL菜單下的Timing Mode選上，以顯示各個步驟的耗費時間。執(zhí)行語句是：

SELECT * FROM PRODUCT_TBL

?

?

第一次訪問，總計耗時1082毫秒，而編譯耗時771毫秒。

緊接著的第二次訪問，總計耗時僅為160毫秒，而編譯耗時為0。

再接著的第三次訪問，總計耗時僅為91毫秒，編譯耗時也為0。

關(guān)閉Console，等待超過30秒之后，重新開啟Console，執(zhí)行相同的語句，總計耗時210毫秒，編譯耗時為20毫秒。

自等待超過30秒之后，執(zhí)行語句，總計耗時101毫秒，編譯耗時為0。

由此可以看出，高速緩存的應(yīng)用大大提高了訪問數(shù)據(jù)庫的性能，而其參數(shù)的設(shè)定則要依據(jù)前面對它們的描述來進行，需要你仔細閱讀數(shù)據(jù)庫的配置文檔。

連接池的設(shè)置和應(yīng)用

我選擇IBM公司的應(yīng)用服務(wù)器平臺WebSphere來給大家演示連接池的設(shè)置，使你面對友好的Web界面，可以體驗到非常簡易的操作場景。

首先，我們進入WebSphere的管理控制臺，這是一個非常漂亮的Web界面：

緊接著，我選定一個數(shù)據(jù)源：Session Persistence datasource，就可看到這個數(shù)據(jù)源的屬性配置了。在這兒，僅僅列舉和連接池有關(guān)的屬性：

Minimum Pool Size 池中保持的連接的最小數(shù)目；有新的請求，且沒有激活連接可供使用時，池中連接數(shù)將增大，到最大連接數(shù)為止
Maximum Pool Size 池中保持的連接的最大數(shù)目；當這個數(shù)目達到，且沒有激活連接可供使用時，新的請求將等待
Connection Timeout 當連接數(shù)達到最大值，且激活連接都在被使用時，新的請求等待的時間
Idle Timeout 連接可在池中閑置的時間；超過將釋放資源，到最小連接數(shù)為止
Orphan Timeout 連接在被應(yīng)用控制時，可閑置的時間；超過將返回池中

你可以根據(jù)需要來修改這些數(shù)值，以滿足你的應(yīng)用需要。接下來，我們討論一下連接池的應(yīng)用。

EJB訪問數(shù)據(jù)庫（場景1，使用JDBC 1.0） import java.sql.*;
import javax.sql.*;
...
public class AccountBean implements EntityBean {
...
public Collection ejbFindByLastName(String lName) {
try {
String dbdriver = new initialContext().lookup("java:comp/env/DBDRIVER").toString();
Class.forName(dbdriver).newInstance();
Connection conn = null;
conn = DriverManager.getConnection("java:comp/env/DBURL", "userID", "password");
...
conn.close();
}
...
}

?

?

如果EntityBean是一個共享組件，那么每次客戶請求時，都要建立和釋放與數(shù)據(jù)庫的連接，這成為影響性能的主要問題。

EJB訪問數(shù)據(jù)庫（場景2，使用JDBC 2.0） import java.sql.*;
import javax.sql.*;
// import here vendor specific JDBC drivers

public ProductPK ejbCreate() {
try {
// initialize JNDI lookup parameters
Context ctx = new InitialContext(parms);
...
ConnectionPoolDataSource cpds = (ConnectionPoolDataSource)ctx.lookup(cpsource);
...
// Following parms could all come from a JNDI look-up
cpds.setDatabaseName("PTDB");
cpds.setUserIF("XYZ");
...
PooledConnection pc = cpds.getPooledConnection();
Connection conn = pc.getConnection();
...
// do business logic
conn.close();
}
...
}
EJB組件利用JNDI的lookup()方法定位數(shù)據(jù)庫的連接池資源，利用getConnection()方法得到已經(jīng)打開的數(shù)據(jù)庫連接，而用close()來釋放連接，放回池中。因此，與場景1相比，少了與數(shù)據(jù)庫建立物理連接的損耗。對于原本要頻繁打開和關(guān)閉物理連接的應(yīng)用來說，通過這種建立邏輯連接并復(fù)用的方法，性能肯定能夠得到大幅度提高。

性能問題的深遠思索

性能問題并不局限于數(shù)據(jù)庫的應(yīng)用上，而是存在于每個軟件系統(tǒng)中。我們希望軟件系統(tǒng)付出的最小，而獲得的最大，因而無時無刻不在優(yōu)化它們。通過《Java程序訪問數(shù)據(jù)庫的速度瓶頸問題的分析和解決》和本文，我對Java程序訪問數(shù)據(jù)庫的性能問題做了分析，并提供了優(yōu)化Java程序的解決方案，希望對你有所幫助。

也許你會關(guān)心碰到類似的性能問題時應(yīng)如何分析和解決，我就針對此次探討"訪問數(shù)據(jù)庫的速度瓶頸"問題的過程中碰到的難題、網(wǎng)友的意見和自己的體會，作一個關(guān)于"方法論"的經(jīng)驗總結(jié)，希望能夠拋磚引玉，更好地解決類似的問題。

解決性能問題的幾條經(jīng)驗

不要讓硬件的低配置成為軟件正常運行的障礙，后者有升級前者的需求，請立即滿足；經(jīng)常碰到這樣的問題"P166+64M的機子跑Win2K+MySql+JBoss，能跑么？"我在回答"可以"的同時只有對著屏幕發(fā)呆了。
盡量使用商業(yè)軟件，并享受良好的售后技術(shù)支持；如果你沒有黑客精神，請不要使用自由軟件。
分析好自己的問題，也許它的本質(zhì)和他人的不同；沒有一把鑰匙可打開的任一把鎖。
確定瓶頸環(huán)節(jié)的位置；解決了瓶頸問題，往往整個的性能問題就解決了，千萬不要抓著邊緣的問題不放。
將瓶頸環(huán)節(jié)細分為多個順序的流程，用逐個替代的方法來試探瓶頸的核心位置；細分問題使你都問題有更進一步的了解。
做自己能做的和該做的事情，始終面向自己的現(xiàn)實問題；不要嘗試那些應(yīng)該由廠商解決的問題（例如，自己寫個JDBC驅(qū)動）。
他人的方案只供自己參考，解決要靠自己思考；你我應(yīng)用的情形不同，應(yīng)用解決方案要在理解他人的方案之后。
觀察新技術(shù)，應(yīng)用新技術(shù)；它往往包含了前人對問題解決的思路，只是對你來說不可見。
問題得到解決后，立即罷手，并匯報結(jié)果；在現(xiàn)實問題得到解決后，沒有必要花費精力在非核心的問題上，也許它們永遠不會被碰到，不要假想問題讓自己解決。
上述經(jīng)驗為個人即興的總結(jié)，并未有嚴謹?shù)倪壿嬐茖?dǎo)，僅代表我解決技術(shù)問題的思路，供你碰到類似問題時參考。

可以提前告訴大家的是，下一篇文章我將把主題轉(zhuǎn)移到JDO的介紹和討論上。這個陌生的API已經(jīng)進入Final Draft了，可它到底能夠給數(shù)據(jù)存取帶來什么好處，和JDBC有什么關(guān)聯(lián)的地方，《JDO（Java Data Object）的發(fā)展和介紹》將向你娓娓道來。

]]>