JAVA認證公共基礎知識J2EE知識

J2EE：教你提升JSP應用程序的七大絕招

你時常被客戶抱怨JSP頁面響應速度很慢嗎？你想過當客戶訪問次數(shù)劇增時，你的WEB

應用能承受II益增加的訪問量嗎？本文講述了調(diào)整JSP和servlet的一些非常實用的方法，它

可使你的servlet和JSP頁面響應更快，擴展性更強。而且在用戶數(shù)增加的情況下，系統(tǒng)負載

會呈現(xiàn)出平滑上長的趨勢。在本文中，我將通過一些實際例子和配置方法使得你的應用程序

的性能有出人意料的提升。其中，某些調(diào)優(yōu)技術是在你的編程工作中實現(xiàn)的。而另一些技術

是與應用服務器的配置相關的。在本文中，我們將詳細地描述怎樣通過調(diào)整servlet和JSP

頁面，來提高你的應用程序的總體性能。在閱讀本文之前，假設你有基本的servlet和JSP

的知識。

方法一：在servlet的init()方法中緩存數(shù)據(jù)

當應用服務器初始化servlet實例之后，為客戶端請求提供服務之前，它會調(diào)用這個

servlet的init()方法。在一個servlet的生命周期中,init()方法只會被調(diào)用一次。通過在init()

方法中緩存一些靜態(tài)的數(shù)據(jù)或完成一些只需要執(zhí)行一次的、耗時的操作，就可大大地提高系

統(tǒng)性能。

例如，通過在init()方法中建立一個JDBC連接池是一個最佳例子，假設我們是用jdbc2.0

的Datasource接口來取得數(shù)據(jù)庫連接，在通常的情況下，我們需要通過JNDI來取得具體的

數(shù)據(jù)源。我們可以想象在一個具體的應用中，如果每次SQL請求都要執(zhí)行?次JNDI查詢的

話，那系統(tǒng)性能將會急劇下降。解決方法是如下代碼，它通過緩存DataSource,使得下一次

SQL調(diào)用時仍然可以繼續(xù)利用它：

publicclassControllerServletextendsHttpServlet

(

privatejavax.sql.DataSourcetestDS=null;

publicvoidinit(ServletConfigconfig)throwsServletException

(

super.init(config);

Contextctx=null;

try

(

ctx=newlnitialContext();

testDS=(javax.sql.DataSource)ctx.lookup("jdbc/testDSn);

)

catch(NamingExceptionne)

(

ne.printStackTrace();

)

catch(Exceptione)

e.printStackTrace();

publicjavax.sql.DataSourcegetTestDS()

returntestDS;

方法2:禁止servlet和JSP自動重載(auto-reloading)

Servlet/JSP提供了?個實用的技術，即自動重載技術，它為開發(fā)人員提供了一個好的開

發(fā)環(huán)境，當你改變servlet和JSP頁面后而不必重啟應用服務器。然而，這種技術在產(chǎn)品運行

階段對系統(tǒng)的資源是一個極大的損耗，因為它會給JSP引擎的類裝載器(classbader)帶來極大

的負擔。因此關閉自動重載功能對系統(tǒng)性能的提升是一個極大的幫助。

方法3:不要濫用HttpSession

在很多應用中，我們的程序需要保持客戶端的狀態(tài)，以便頁面之間可以相互聯(lián)系。但不

幸的是由于HTTP具有天生無狀態(tài)性，從而無法保存客戶端的狀態(tài)。因此?般的應用服務器

都提供了session來保存客戶的狀態(tài)。在JSP應用服務器中，是通過HttpSession對像來實現(xiàn)

session的功能的，但在方便的同時，它也給系統(tǒng)帶來了不小的負擔。因為每當你獲得或更

新session時，系統(tǒng)者要對它進行費時的序列化操作。你可以通過對HttpSession的以下幾種

處理方式來提升系統(tǒng)的性能：

?如果沒有必要，就應該關閉JSP頁面中對HttpSession的缺省設置：如果你沒有明確

指定的話，每個JSP頁面都會缺省地創(chuàng)建一一個HttpSession。如果你的JSP中不需要使用session

的話，那可以通過如下的JSP頁面指示符來禁止它：

<%@pagesession="false"%>

?不要在HttpSession中存放大的數(shù)據(jù)對像：如果你在HttpSession中存放大的數(shù)據(jù)對像

的話，每當對它進行讀寫時，應用服務器都將對其進行序列化，從而增加了系統(tǒng)的額外負擔。

你在HttpSession中存放的數(shù)據(jù)對像越大，那系統(tǒng)的性能就下降得越快。

?當你不需要HttpSession時，盡快地釋放它：當你不再需要session時，你可以通過調(diào)

用HttpSession.invalidate。方法來釋放它。

?盡量將session的超時時間設得短一點：在JSP應用服務器中，有一個缺省的session

的超時時間。當客戶在這個時間之后沒有進行任何操作的話，系統(tǒng)會將相關的session自動

從內(nèi)存中釋放。超時時間設得越大，系統(tǒng)的性能就會越低，因此最好的方法就是盡量使得它

的值保持在一個較低的水平。

方法4:將頁面輸出進行壓縮

壓縮是解決數(shù)據(jù)冗余的一個好的方法，特別是在網(wǎng)絡帶寬不夠發(fā)達的今天。有的瀏覽器

支持gzip(GNUzip)進行來對HTML文件進行壓縮，這種方法可以戲劇性地減少HTML文件的

下載時間。因此，如果你將servlet或JSP頁面生成的HTML頁面進行壓縮的話，那用戶就會

覺得頁面瀏覽速度會非?？?。但不幸的是，不是所有的瀏覽器都支持gzip壓縮，但你可以

通過在你的程序中檢查客戶的瀏覽器是否支持它。下面就是關于這種方法實現(xiàn)的一個代碼片

段：

publicvoiddoGet(HttpServletRequestrequest,HttpServletResponseresponse)

throwslOException,ServletException

(

Outputstreamout=null

Stringencoding=request.getHeader("Accept-Encoding")；

if(encoding!=null&&encoding.indexOf(Mgzip")!=-1)

(

request.setHeader("Content-Encoding","gzip");

out=newGZIPOutputStream(request.getOutputStream());

)

elseif(encoding!=null&&encoding.indexOfCcompress")!=-1)

(

request.setHeader("Content-Encoding","compress");

out=newZIPOutputStream(request.getOutputStream());

)

else

(

out=request.getOutputStream();

方法5:使用線程池

應用服務器缺省地為每個不同的客戶端請求創(chuàng)建一個線程進行處理，并為它們分派

service。方法，當service。方法調(diào)用完成后，與之相應的線程也隨之撤消。由于創(chuàng)建和撤消

線程會耗費一定的系統(tǒng)資源，這種缺省模式降低了系統(tǒng)的性能。但所幸的是我們可以通過創(chuàng)

建一個線程池來改變這種狀況。另外，我們還要為這個線程池設置一個最小線程數(shù)和一個最

大線程數(shù)。在應用服務器啟動時，它會創(chuàng)建數(shù)量等于最小線程數(shù)的一個線程池，當客戶有請

求時，相應地從池從取出一個線程來進行處理，當處理完成后，再將線程重新放入到池中。

如果池中的線程不夠地話,系統(tǒng)會自動地增加池中線程的數(shù)量，但總量不能超過最大線程數(shù)。

通過使用線程池，當客戶端請求急劇增加時，系統(tǒng)的負載就會呈現(xiàn)的平滑的上升曲線，從而

提高的系統(tǒng)的可伸縮性。

方法6:選擇正確的頁面包含機制

在JSP中有兩種方法可以用來包含另一個頁面：1、使用include指示符(V%@includee

file="test.jsp"%>)<>2、使用jsp指示符(Vjsp:includeepage="test.jsp"flush="true"/

>)?在實際中我發(fā)現(xiàn)，如果使用第一種方法的話，可以使得系統(tǒng)性能更高。

方法7:正確地確定javabean的生命周期

JSP的一個強大的地方就是對javabean的支持。通過在JSP頁面中使用<jsp:useBean>

標簽，可以將javabean直接插入到?個JSP頁面中。它的使用方法如下：

<jsp:useBeanid="name"scope="page|request|session|application"class=

"package.className"type="typeName">

</jsp:useBean>

其中scope屬性指出了這個bean的生命周期。缺省的生命周期為page。如果你沒有正

確地選擇bean的生命周期的話，它將影響系統(tǒng)的性能。

舉例來說，如果你只想在一次請求中使用某個bean,但你卻將這個bean的生命周期設

置成了session,那當這次請求結束后，這個bean將仍然保留在內(nèi)存中，除非session超時

或用戶關閉瀏覽器。這樣會耗費一定的內(nèi)存，并無謂的增加了JVM垃圾收集器的工作量。

因此為bean設置正確的生命周期，并在bean的使命結束后盡快地清理它們，會使用系統(tǒng)性

能有一個提高。

其它一些有用的方法

?在字符串連接操作中盡量不使用“+”操作符：在java編程中，我們常常使用“+”

操作符來將幾個字符串連接起來，但你或許從來沒有想到過它居然會對系統(tǒng)性能造成影響

吧？由于字符串是常量，因此JVM會產(chǎn)生一些臨時的對像。你使用的“+”越多，生成的

臨時對像就越多，這樣也會給系統(tǒng)性能帶來一些影響。解決的方法是用StringBuffer對像來

代替“+”操作符。

?避免使用System.out.println。方法：由于System.out.println()是一種同步調(diào)用，即在調(diào)

用它時，磁盤I/O操作必須等待它的完成，因此我們要盡量避免對它的調(diào)用。但我們在調(diào)試

程序時它又是一個必不可少的方便工具，為了解決這個矛盾，我建議你最好使用Log4j工具

(http://J),它既可以方便調(diào)試，而不會產(chǎn)生System.out.println()這樣的方法。

?ServletOutputStream與Printwriter的權衡:使用Printwriter可能會帶來一些小的開

銷，因為它將所有的原始輸出都轉換為字符流來輸出，因此如果使用它來作為頁面輸出的話，

系統(tǒng)要負擔?個轉換過程。而使用ServletOutputStream作為頁面輸出的話就不存在一個問

題，但它是以二進制進行輸出的。因此在實際應用中要權衡兩者的利弊。

總結

本文的目的是通過對servlet和JSP的一些調(diào)優(yōu)技術來極大地提高你的應用程序的性能，

并因此提升整個J2EE應用的性能。通過這些調(diào)優(yōu)技術，你可以發(fā)現(xiàn)其實并不是某種技術平

臺(比如J2EE和.NET之爭)決定了你的應用程序的性能，重要是你要對這種平臺有一個較

為深入的了解，這樣你才能從根本上對自己的應用程序做一個優(yōu)化！

J2EE常見問題J2EE平臺的特征與優(yōu)點

問題：什么是Java2Platform,EnterpriseEdition(J2EE)?

Java2Platform,EnterpriseEdition(J2EE)是一組協(xié)調(diào)規(guī)范與實踐，它們組合起來，能夠實

現(xiàn)用于開發(fā)、部署和管理多層的以服務器為中心的應用程序的解決方案。建立在Java2

Platform,StandardEdition(J2SE)的基礎上，J2EE平臺添加了一些必要的能力，以便為企業(yè)

級提供完整的、穩(wěn)定的、安全的和快速的Java平臺。由于它大大減少了開發(fā)和部署多層解

決方案的成本和復雜程度，帶來了可以快速進行部署并且容易增強的服務，因此它為企業(yè)創(chuàng)

造了價值。

問題：J2EE平臺有哪些主要優(yōu)點？

J2EE平臺提供了以下特征：

完整的Web服務支持。J2EE提供了一個框架，以便在Java平臺上開發(fā)和部署Web

服務。JavaAPIforXML-basedRPC(JAX-RPC)使得Java技術開發(fā)人員能夠開發(fā)基于SOAP的、

能夠互操作并且可移植的Web服務。開發(fā)人員可以使用標準的JAX-RPC編程模型來開發(fā)

基于SOAP的Web服務客戶端和端點。Web服務端點是使用Web服務描述語言(WSDL)文

檔來描述的。JAX-RPC使得JAX-RPC客戶端能夠調(diào)用跨異構平臺上開發(fā)的Web服務。同樣，

JAX-RPCWeb服務端點可以由異構客戶端調(diào)用。有關進一步信息，請參閱

http://java.sun.eom/webservices/o

更加快速的解決方案面市時間。J2EE平臺使用“容器”來簡化開發(fā)。J2EE容器提供

了業(yè)務邏輯與資源和生命周期管理的分離，這表明開發(fā)人員可以將重點放在編寫業(yè)務邏輯

(它們的增值)上，而不是放在企業(yè)基礎結構上。例如，EnterpriseJavaBeans(EJB)容器(由J2EE

供應商實現(xiàn))處理了分布式通信、線程處理、縮放、事務管理等。與此類似，JavaServlets簡

化了Web開發(fā)，因為它在Web容器中提供了針對組件、通信和會話管理的基礎結構，而

該容器又與Web服務器集成。

自由的選擇。J2EE是一組許多供應商都可以實現(xiàn)的標準。供應商可以自由地完成實現(xiàn),

但在標準或API上卻不能自由完成。Sun為J2EE持證人提供了綜合的J2EECompatibility

TestSuite(CTS)oJ2EECTS有助于在應用程序供應商之間保證兼容性，從而保證了針對J2EE平

臺編寫的應用程序和組件的可移植性。J2EE平臺為服務器帶來了“WriteOnce,Run

Anywhere”(編寫一次，隨處運行)的能力。

簡化的連接。J2EE技術使得可以容易地連接已經(jīng)擁有的應用程序和系統(tǒng)，并將這些能

力帶到了Web、手機和設備。J2EE提供了JavaMessageService,以便以采用松耦合、異步

的方式來集成不同的應用程序。J2EE也提供了CORBA支持，以便通過遠程方法調(diào)用來緊

密地鏈接系統(tǒng)。J2EE平臺還具有J2EEConnectors,用于鏈接企業(yè)信息系統(tǒng)，比如ERP系統(tǒng)、

打包的財務應用程序和CRM應用程序。

通過提供具有如下特征的平臺：更加快速的解決方案面市時間、自由的選擇和簡化的連

接，J2EE平臺可幫助IT縮減TCO,同時免去了針對企業(yè)軟件要求的單一源碼。

問題：J2EE平臺是否能夠與其他WS-I實現(xiàn)進行互操作？

是的，前提是其他實現(xiàn)要符合WS-L

問題：J2EE平臺中包含了哪些技術？

J2EE平臺中的主要技術有：JavaAPIforXML-BasedRPC(JAX-RPC)、JavaServerPages、Java

Servlets>EnterpriseJavaBeans組件、J2EEConnectorArchitecture(JCA)、J2EEManagement

ModeKJ2EEDeploymentAPI>JavaManagementExtensions(JMX)、J2EEAuthorizationContract

forContainersJavaAPIforXMLRegistries(JAXR),JavaMessageService(JMS)、JavaNamingand

Directorylnterface(JNDI)>JavaTransactionAPI(JTA),CORBA和JDBC數(shù)據(jù)訪問API。

問題：J2EE1.4平臺新增了什么？J2EE1.4提供了完整的Web服務支持功能，該支持是

通過新的JAX-RPC1.1API來完成的，該API支持基于servlets和企業(yè)beans的服務端點。

JAX-RPC1.1提供了與基于WSDL和SOAP協(xié)議的Web服務的互操作性。J2EE1.4平臺也

支持J2EE規(guī)范(JSR921)的Web服務，它定義了Web服務的部署要求并利用了JAX-RPC

編程模型。除了眾多的Web服務API之外，J2EE1.4平臺提供了對WS-IBasicProfile1.0

的支持。這表明除了平臺無關性和完整的Web服務支持之外，J2EE1.4還提供了平臺Web

服務互操作性。

J2EE1.4還引入J2EEManagement1.0API,該API定義了J2EEManagement的信息模

型，包括標準的ManagementEJB(MEJB)。J2EEManagement1.0API使用JavaManagement

ExtensionsAPI(JMX)oJ2EE1.4也引入了J2EEDeploymentLIAPI,它提供了一個標準的API,

用于部署J2EE應用程序。

現(xiàn)在，J2EE平分使得可以容易地開發(fā)Web前端，并且該前端具有JavaServlet和

JavaServerPages(JSP)技術的增強功能?，F(xiàn)在，servlets也支持請求偵聽器和增強的篩選器。

JSP技術已經(jīng)簡化了頁面和擴展的部署模型，由于它引入了簡單的表達語言、標簽文件和更

加簡單的標簽擴展API等特性。對于開發(fā)人員，特別是熟悉腳本語言的開發(fā)人員來說，這

使得他們可以比以往更加容易地生成支持JSP的頁面。

J2EE平臺的其他增強功能包括J2EEConnectorArchitecture,它提供了傳入資源適配器

和JavaMessageService(JMS)的可插入性。EnterpriseJavaBeans(EJB)技術的新特性包括

Web服務端點、計時器服務以及EJBQL和消息驅動beans的增強功能。J2EE1.4平臺也

包括部署描述符的增強功能?，F(xiàn)在，它們是使用XMLSchema來定義的，開發(fā)人員也可使

用XMLSchema來驗證XML結構。

問題：我現(xiàn)在應該使用哪一版本的平臺——1.4或1.3?

J2EE1.4規(guī)范是最新規(guī)范，因此現(xiàn)在可以使用J2EE1.4SDK來部署應用程序。不過，為

了提高可靠性、可伸縮性和性能，推薦在J2EE1.4商業(yè)實現(xiàn)上部署應用程序，該商業(yè)實現(xiàn)

將在2004年初可用。如果想在2004年以前部署應用程序，并且可靠性、可伸縮性和性能

是至關重要的情況下，那就應該考慮使用支持J2EE1.3的高性能應用程序服務器，比如Sun

JavaSystemApplicationServer7。許多應用程序服務器供應商期望在春季之前發(fā)布J2EE1.4

平臺版本的產(chǎn)品。

問題：針對J2EE1.3平臺編寫的應用程序是否可以在J2EE1.4平臺實現(xiàn)上運行？

針對J2EE1.3規(guī)范編寫的J2EE應用程序將可以在J2EE1.4實現(xiàn)上運行。向后兼容是

規(guī)范的要求。

問題：J2EE體系結構是如何與SunJavaEnterpriseSystem關聯(lián)的？

J2EE體系結構是SunJavaSystemApplicationServer的基礎，它是SunJavaEnterprise

System的組件。在當前SunJavaEnterpriseSystem中，JavaSystemApplicationServer是以

J2EE1.3平臺為基礎的，并為Web服務提供了附加的支持。熟悉J2EE技術的開發(fā)人員可

以容易地應用他們的技術，來生成使用SunJavaEnterpriseSystem的應用程序，包括Web

服務應用程序。有關進一步信息，請參閱SunJavaEnterpriseSystemWeb站點。

問題：我該怎樣學習J2EE平臺？

有關J2EE平臺以及如何獲得規(guī)范的進一步信息，請參閱http://java.sun.eom/j2ee/o

了解J2EE平臺及在J2EE1.4平臺中新增了什么的最有效辦法是，利用J2EE1.4SDK

來親自體驗這些API。J2EE1.4SDK提供了兼容于J2EE1.4的應用程序服務器，并將它作為

開發(fā)和部署支持Web服務、多層的企業(yè)應用程序的基礎?？梢詮娜缦抡军c免費下載J2EE

1.4SDK：/j2ee/downloads/index.htmlo

J2EE文檔頁面提供了一些鏈接，它們指向各種自我導向的學習材料，比如針對初學者

的教程和FAQo

需要更高級資料的開發(fā)人員可以訪問JavaBlueprintsfortheenterprise。企業(yè)的Java

Blueprints是最佳實踐指導原則，可用于設計和生成基于J2EE的應用程序。設計指導文檔

提供了兩樣東西。首先，它提供了在Java2平臺上生成N層應用程序的指導原則。其次,

它提供了一組設計模式，用于設計這些應用程序，以及提供了一組有關如何生成應用程序的

例子或訣竅。

Sun教育服務也提供了許多培訓課程，它們可以引導您獲得下面三種證書的?種：Sun

CertifiedWebComponentDeveloper,SunCertifiedBusinessComponentDeveloper利ISun

CertifiedEnterpriseArchitecto

J2EE程序員應該掌握的Linux系統(tǒng)的知識

大型J2EE應用都在建構在linux環(huán)境下的。開發(fā)環(huán)境下我們可以通過samba映射成本地

的網(wǎng)絡驅動器，直接在windows環(huán)境下進行編程調(diào)試。但是最后的發(fā)布還是要到linux環(huán)境，

同時我們對網(wǎng)上web服務器和數(shù)據(jù)庫服務器的應用管理（比如自動腳本發(fā)布等），應用監(jiān)控

（web服務是否正常、mysql數(shù)據(jù)庫的使用情況）、系統(tǒng)監(jiān)控（監(jiān)控磁盤空間的使用情況等）

都要求程序員熟悉必要的linux知識。

當然程序員不必對整個linux系統(tǒng)樣樣精通。下面列出程序員基本需要掌握的linux知識。

一、linux的基本命令

1、用戶管理

userdel刪除用戶帳號

useradd增加用戶賬號

su改變當前用戶的ID

2、文件目錄管理

Is瀏覽目錄，查看當前目錄下的文件和文件名

chmod修改文件權限

chown改變文件所有者

cp復制文件

cd改變當前目錄

mv重命名文件或移動文件

rm刪除文件或者目錄

pwd當前目錄

scp遠程拷貝

alias別名

3、其他命令

In在文件之間建立鏈接

tail輸出文件內(nèi)容后面的部分，一般我們會通過tail-f實時查看當前程序打印的日志。

type查看一個命令所在路徑

wc查看行數(shù)

grep在文件內(nèi)容中查找

find查找文件

date查看日期

crontab制定計劃任務，通常用于系統(tǒng)監(jiān)控。

df查看磁盤剩余空間，你最好在crontab中寫個腳本監(jiān)控磁盤的空間。超過90%就給

相關的人員發(fā)emailo

ps查看進程狀態(tài)

top查看CPU的使用率

kill終止進程

killalljava程序員最喜歡用killall-9java吧

w查看登錄用戶和他們正在做什么，也可以看看系統(tǒng)的load,load太高，就該找找原

因了。

who查看當前用戶的便當情況

tar解壓或壓縮文件

echo控制臺輸出

wgethttp訪問

rpmrpm包管理

4、重定向、管道

5、標準輸出、標準錯誤

6、使用'屏蔽?個特殊字符的含義

7、正則表達式

二、熟練掌握vim編輯器

三、liunx環(huán)境下shell腳本、perl腳本的編寫

為了對網(wǎng)上服務器應用進行管理，通常需要編寫一些腳本。

腳本的編寫重點掌握下面幾點：

1、理解雙引號、單引號、反引號的含義。

2、反斜線的使用。

3、shell腳本賦值語句左邊的變量名不要加上$,常寫perl腳本的常犯此錯誤。

4、字符串比較長，含有空格的時候，作為一個參數(shù)時腳本出錯，用雙引號把字符串括

起來。

5、掌握好awk和sed的用法。

四、基本軟件包的安裝

apache、resin、mysql

一般的步驟就是：

configure

make

makeinstall

J2EE的MVC體系結構及其設計模式

目前大多數(shù)企業(yè)采用J2EE技術的結構設計與解決方案。對于我們學習和研究J2EE體系

結構來說，了解與掌握J2EE體系結構的設計方法及一些常用模式是必須的；模型-視圖-控制

(model-view-control,簡稱MVC)結構是目前最常見的J2EE應用所基于的體系結構，MVC主

要適用于交互式的Web應用，尤其是存在大量頁面及多次客戶訪問及數(shù)據(jù)顯示；相比較而

言，一個工作流體系結構更多應用于過程控制和較少交互的情況下；除了體系結構外，J2EE

的設計模式對我們解決應用系統(tǒng)的設計也有很大的幫助。

一、J2EE的模型-視圖-控制(MVC)體系結構

模型-視圖-控制結構是交互式應用程序廣泛使用的一種體系結構。它有效地在存儲和展

示數(shù)據(jù)的對象中區(qū)分功能模塊以降低它們之間的連接度，這種體系結構將傳統(tǒng)的輸入、處理

和輸入模型轉化為圖形顯示的用戶交互模型，或者換一種說法，是多層次的Web商業(yè)應用；

MVC體系結構具有三個層面：模型(Model)、視圖(View)和控制(Controller),每個層面有其

各自的功能作用，MVC體系結構如下：

J2EE的MVC體系結構及其設計模式

圖1MVC體系結構

模型層負責表達和訪問商業(yè)數(shù)據(jù)，執(zhí)行商業(yè)邏輯和操作。也就是說，這一層就是現(xiàn)實生

活中功能的軟件模擬；在模型層變化的時候，它將通知視圖層并提供后者訪問自身狀態(tài)的能

力，同時控制層也可以訪問其功能函數(shù)以完成相關的任務。

視圖層負責顯示模型層的內(nèi)容。它從模型層取得數(shù)據(jù)并指定這些數(shù)據(jù)如何被顯示出來。

在模型層變化的時候，它將自動更新。另外視圖層也會將用戶的輸入傳送給控制器。

控制層負責定義應用程序的行為。它可以分派用戶的請求并選擇恰當?shù)囊晥D以用于顯

示，同時它也可以解釋用戶的輸入并將它們映射為模型層可執(zhí)行的操作;在?個圖形界面中，

常見的用戶輸入包括點擊按鈕和菜單選擇。在Web應用中，它包括對Web層的HTTPGET

和POST的請求：控制層可以基于用戶的交互和模型層的操作結果來選擇下一個可以顯示的

視圖，一個應用程序通常會基于一組相關功能設定一個控制層的模塊，甚至一些應用程序會

根據(jù)不同的用戶類型具有不同的控制層設定，這主要是由于不同用戶的視圖交互和選擇也是

不同的。

在模型層、視圖層和控制層之間劃分責任可以減少代碼的重復度，并使應用程序維護起

來更簡單。同時由于數(shù)據(jù)和商務邏輯的分開，在新的數(shù)據(jù)源加入和數(shù)據(jù)顯示變化的時候，數(shù)

據(jù)處理也會變得更簡單。

二、J2EE設計模式

一個設計模式描述了對于特定設計問題被驗證的解決方案,它綜合了所有開發(fā)者對這個

問題所在領域的知識和見解；同時也是對于常見問題的可重用方案，它們一般適用于單個問

題，但是組織在一起就可以提供整個企業(yè)系統(tǒng)的解決方案。下面我們列舉八種常用于J2EE

平臺的設計模式，并對每種模式作簡單的介紹，便于大家學習、理解與靈活應用。

1、前控制器

前控制器(frontcontroller)主要提供一種可以集中式管理請求的控制器，一個前控制器可

以接受所有的客戶請求，將每個請求遞交給相應的請求句柄，并適當?shù)仨憫脩簟?/p>

前控制器也是表示層的設計模式，它的出現(xiàn)主要是由于表示層通常需要控制和協(xié)調(diào)來自

不同用戶的多個請求，而這種控制機制又根據(jù)不同的需要，可能會集中式控制或分散式控制。

換句話說，就是應用系統(tǒng)需要對于表示層的請求提供i個集中式控制模塊，以提供各種系統(tǒng)

服務，包括內(nèi)容提取、視圖管理和瀏覽，如果系統(tǒng)中沒有這種集中式控制模塊或控制機制，

每個不同的系統(tǒng)服務都需要進行單獨的視圖處理，這樣代碼的重復性就會提高，致使系統(tǒng)開

發(fā)代價提高；同時，如果沒有一個固定模塊管理視圖之間的瀏覽機制，致使其瀏覽功能下放

于每個不同的視圖中，最終必將使得系統(tǒng)的可維護性受到破壞；本文中我們主要討論的是集

中式控制模塊，而不是分散式控制，因為前者更適合于大型的應用系統(tǒng)。

基于上面所說的問題，研究人員提出了前控制器的設計模式。在這種模式中，控制器提

供一個處理不同請求的控制點，這里的處理工作包括安全事務、視圖選擇、錯誤處理和響應

內(nèi)容的生成；通過將這些處理工作集中在一點進行，大大地減低了Java代碼量，同時這種

方法也可以減少在視圖模塊的程序邏輯，保證了在不同請求之間可以重用大量的邏輯代碼。

通常，控制器都是和一個分派組件聯(lián)合工作的，分派組件主要是用于視圖管理和瀏覽，也就

是為用戶選擇下一個應該顯示的視圖，并同時提供對于相關顯示資源的控制。分派組件可以

包含在控制器之內(nèi)，或是在另外一個單獨的組件中：雖然前控制器模式推薦對于全部的請求

使用統(tǒng)一處理，但是它也沒有限制在個系統(tǒng)中只能具有一個控制器，在系統(tǒng)中的每個層次

都可以具有多個控制器，并且映射至不同的系統(tǒng)服務，下圖2顯示了前控制器的類圖。

圖2前控制器的類圖

圖3顯示了前控制器的序列圖，表示一個控制器如何處理相關的請求。

圖3前控制器序列圖

下面我們來討論一下圖3的各個組件。

2、控制器

控制器(controller)是負責處理各種客戶請求的控制點，并可以將一定的職能(如用戶認證

等)下放給幫助類。

⑴分派組件(Dispatcher)。?個分派組件主要是用于視圖的管理和瀏覽，為用戶選擇下

一個可以顯示的視圖，并管理相關的顯示資源；分派組件可以在一個控制器內(nèi)運行，或者作

為一個單獨的組件與控制器協(xié)同工作；開發(fā)人員可以在分派組件中實現(xiàn)靜態(tài)的視圖分派技

術，或是復雜的動態(tài)分派。

(2)幫助類(Helper)。幫助類負責幫助一個視圖或控制器來完成其處理工作，因此，幫助

類具有多項職責，包括收集數(shù)據(jù)、存儲中間數(shù)據(jù)模型等；另外，幫助類也可以在保證數(shù)據(jù)完

整性和準確性的情況卜，為不同顯示需求修改數(shù)據(jù)模型；也就是說，根據(jù)用戶的請求，幫助

類可以向視圖提供未經(jīng)處理的原始數(shù)據(jù)，或是已經(jīng)格式化后的Web內(nèi)容，一個視圖同時可

以和多個幫助類協(xié)同工作，而后者通常是由JavaBeans和標簽(tag)實現(xiàn)的。

3、視圖

視圖(view)負責向用戶顯示信息，而幫助類則負責支持視圖的工作，即打包和建立相應

的數(shù)據(jù)模型，下面我們介紹幾種可以實現(xiàn)控制器的方法。

1)基于Servlet前控制器

這種方法建議使用servlet來實現(xiàn)一個控制器，盡管在語法上相差無幾，但是它比使用

JSP來實現(xiàn)要優(yōu)越?些；因為控制器所進行的請求處理，多數(shù)都是與程序運行和控制流動相

關的，這些處理工作雖然與顯示模式相關，但是實際上是邏輯獨立的，所以它們更適合在

servlet中實現(xiàn)，而不是JSP技術中；使用這種方法也存在一些弱點，比如說servlet無法使

用JSP運行環(huán)境的資源，如請求參數(shù)等,但是這個弱點也不是不能解決的，我們可以在servlet

中建立相關的句柄來訪問同樣的資源，當然其代碼會變得繁瑣一點。

2)基于JSP的前控制器

這種方法建議使用JSP頁面實現(xiàn)控制器，盡管語法上相同，但是Servlet方案要比其優(yōu)

越一些；因為控制器所處理的邏輯一般都不是有關顯示模式的，所以在JSP頁面中實現(xiàn)控制

器似乎有點風馬牛不相及；使用這種方法也不利于開發(fā)團隊的角色和職責的分配，即軟件開

發(fā)人員需要在負責顯示邏輯的JSP頁面中修改請求處理的代碼，通常，這種工作都是相當復

雜的，尤其考慮整個JSP頁面的編程、編譯、測試和調(diào)試錯誤。

3)控制器之中的分派組件

如果分派組件沒有較多功能，開發(fā)人員可以在控制器實現(xiàn)該組件。

4)基礎前端

基于使用servlet實現(xiàn)前控制器，這種方案建議實現(xiàn)?個控制器作為基礎類，這樣其他

的控制器可以在其之上擴展；這個基礎類可以包含一些通用的邏輯實現(xiàn)，它的子類就會重載

這些實現(xiàn)代碼，這種方法也有一定的缺陷，當有許多子類繼承這個基礎類，并大量地重用代

碼時，那么就有可能出現(xiàn)?個類的改變會影響到所有子類的情況。

5)用過濾器實現(xiàn)前控制器

過濾器提供了與用戶請求的中心處理相類似的功能，也就是說，控制器的一些功能可以

由過濾器來實現(xiàn)，這種方案的過濾器主要負責處理請求的截取和解釋，而不是請求的處理和

響應的生成;通常可以為應用系統(tǒng)提供一個核心控制點，以處理所有的系統(tǒng)服務和程序邏輯,

核心控制也就表明了所有的請求都可以簡單地被跟蹤和記錄，從而方便各種服務功能的實

施；當然，它也存在一些缺點，一個核心控制點的小問題可能會引發(fā)系統(tǒng)的崩潰，但在應用

系統(tǒng)的實際開發(fā)中，這并不是個問題，因為通常我們都會在同?個層面上實現(xiàn)多個控制器，

從而避免了這個缺陷；在控制器中，開發(fā)人員可以很方便地實現(xiàn)一個檢查安全機制的組件，

從而可以在最外層屏蔽對系統(tǒng)的惡意訪問，另外使用控制器也會提高系統(tǒng)模塊的可重用性，

尤其在控制器同時使用幫助類的時候。

4、視圖幫助

視圖幫助(Viewhelper)是屬于表示層的設計模式，-個視圖幫助可以包含相關視圖中的

數(shù)據(jù)訪問和內(nèi)容顯示的邏輯，并可以精煉簡化視圖；顯示邏輯主要是關于如何格式化頁面上

的數(shù)據(jù)，而訪問邏輯則是關于如何取出數(shù)據(jù)，視圖幫助通常用來顯示數(shù)據(jù)的JSP標記(tag)或

是讀取數(shù)據(jù)的JavaBean。

這種設計模式的出現(xiàn)主要是由于目前的應用系統(tǒng)通常需要實時地開發(fā)顯示內(nèi)容,并且能

處理動態(tài)的程序數(shù)據(jù)。如果這些程序數(shù)據(jù)的訪問邏輯和顯示邏輯的關系過于緊密，則系統(tǒng)的

表示層就會經(jīng)常需要改動，從而系統(tǒng)的靈活性、重用性會大大地受到破壞；同時在相同的模

塊中實現(xiàn)訪問邏輯和顯示邏輯將會影響系統(tǒng)的模塊化，也會使得開發(fā)團隊的任務劃分不清。

一個視圖通常包含格式化信息，并將其處理任務分發(fā)給自己的幫助類，后者通常是用

JavaBeans或標記(tag)來實現(xiàn)的，幫助類同時可以存儲視圖的中間數(shù)據(jù)模型并實現(xiàn)數(shù)據(jù)適配

器的功能，即適當?shù)剞D化數(shù)據(jù)格式；開發(fā)人員可以采用多種方法實現(xiàn)視圖組件，通常，開發(fā)

人員可以使用JSP來實現(xiàn)，并且這也是一種值得推薦的方法。當然，相應地開發(fā)人員也可以

使用Servlet來實現(xiàn)它，將視圖中一定的程序邏輯植入到幫助類中，會有利于應用系統(tǒng)的模

塊化和可重用性。系統(tǒng)可以使用同一個幫助類為不同的用戶顯示不同的數(shù)據(jù)信息，并在不同

的顯示格式下顯示；通常，如果開發(fā)人員發(fā)現(xiàn)視圖的JSP頁面中存在大量的腳本代碼時，就

可以考慮使用視圖幫助這種模式了，因為在這種情況下，基本都是程序邏輯和顯示邏輯具有

過于緊密的聯(lián)系:這時開發(fā)人員可以將?些適用于所有類型的請求的邏輯處理放置到一定的

幫助類中，而根據(jù)需要，也可以將另外一些邏輯處理放置在視圖層上的其他程序模塊中，比

如說以前討論過的截取過濾器。

視圖幫助這種模式的設計理念主要是分離應用系統(tǒng)的邏輯職責，下面我們提供一些圖

示，以方便大家更好地理解這種模式。

圖4以類圖(classdiagram)的形式說明了視圖幫助的系統(tǒng)結構。

圖4視圖幫助類圖

圖5表示了視圖幫助模式的序列圖，它表明了這種模式中的主要成分及互相之間的運行

情況；不過需要說明的是，在很多應用系統(tǒng)中，客戶端和視圖層之間會存在一個控制器加以

適當?shù)恼{(diào)節(jié)。

圖5視圖幫助序列圖

在類圖表中，大家可以發(fā)現(xiàn)，可能存在沒有任何相關幫助類的視圖，這種情況下，通常

代表視圖的JSP頁面會有一些靜態(tài)的或小數(shù)量的腳本代碼。

這里我們對于序列圖中的各個元素加以簡單的介紹：

⑴視圖(view)。視圖負責向用戶展示動態(tài)數(shù)據(jù)信息，而幫助類則負責支持視圖的工作，

即打包和建立相應的數(shù)據(jù)模型。

⑵幫助類(helper)。一個幫助類負責幫助視圖或控制器完成相關的處理工作，包括收集

數(shù)據(jù)、存儲中間模型等；幫助類也可以在保證數(shù)據(jù)完整性和準確性的情況下，為不同顯示需

求修改數(shù)據(jù)模型，也就是說，根據(jù)用戶的請求，幫助類可以向視圖提供未經(jīng)處理的原始數(shù)據(jù),

或是已經(jīng)格式化后的Web內(nèi)容；一個視圖同時可以和多個幫助類協(xié)同工作，而后者通常是

由JavaBeans和標記(tag)實現(xiàn)的。

⑶值bean(ValueBean)。值bean實際上是用于存儲中間數(shù)據(jù)模型的幫助類的另一種叫法,

例如在序列圖5中，businessservice就根據(jù)請求返回了一個值bean。

(4)業(yè)務服務(businessservice)?業(yè)務服務是指用戶試圖得到的，應用系統(tǒng)可以提供的相

關服務；通常來說，業(yè)務服務可以通過一個業(yè)務代表(businessdelegate)來訪問，而后者主要

是提供對于業(yè)務服務的控制和保護。

在應用系統(tǒng)的視圖模塊中使用幫助類可以將不同的程序邏輯很好地分離開來，并在視圖

模塊之外為開發(fā)人員提供設計程序邏輯的空間；基于JavaBean和標記(tag)所開發(fā)的幫助類

通常都可以被多個視圖模塊重用，因此也提高了組件的重用性和可維護性：把顯示邏輯從數(shù)

據(jù)處理邏輯分離出來，也有利于開發(fā)團隊中角色及人物的劃分；比如說，如果各種程序邏輯

過于結合的話，軟件開發(fā)人員可能需要在HTML,網(wǎng)頁中修改代碼而Web設計師則需要在處

理數(shù)據(jù)訪問的JSP中修改頁面布置，這些情況都可能會導致系統(tǒng)設計和開發(fā)中由于不同技術

人員的介入，而產(chǎn)生相關的問題

J2EE的六種范圍類型

大多數(shù)服務器端J2EE應用程序中有六種常用的范圍類型：

Transaction（事務）

Request（請求）

HTTPsession（HTTP會話）

Application（應用程序）

Global（全局）

None（無）

事務范圍

事務范圍覆蓋一個事務的整個生命周期。這個范圍開始于一個事務的開始。這時會創(chuàng)建

一個惟一的范圍鍵。這個范圍結束于提交或回滾事務時。這時，與事務范圍相關聯(lián)的所有對

象被自動釋放回它們的池。

請求范圍

請求范圍與一個servlet請求的范圍對應；在容器調(diào)用servlet來處理請求之后，請求

范圍立即開始。同時會創(chuàng)建一個惟一的范圍鍵。在servlet完成處理之前請求范圍結束。這

時，與這個范圍相關聯(lián)的所有對象被自動釋放回它們的池。

HTTP會話范圍

HTTP會話范圍與一個HTTP會話的生命周期對應。它從創(chuàng)建一個新的HttpSession時

開始。這時會創(chuàng)建一個惟一的范圍鍵。它結束于會話被銷毀或過期時。這時，與這個范圍相

關聯(lián)的所有對象被自動釋放回它們的池。

應用程序范圍

應用程序范圍覆蓋應用程序的整個生命周期。它開始于把一個應用程序部署到應用服務

器時。這時會創(chuàng)建一個惟一的范圍鍵。這個范圍結束于應用程序停止運行或從應用服務器中

刪除時。這時，與這個范圍相關聯(lián)的所有對象被自動釋放回它們的池。

全局范圍

全局范圍是最大的范圍。采用這種范圍的對象不會被釋放。

無范圍

無范圍用于不使用對象池的對象。采用這種范圍的對象每次都通過自己的對象構造函數(shù)

來創(chuàng)建，并由Java垃圾收集器釋放。對象管理器根本不管理它們。

J2EE--關于JAVA的分頁查詢操作技術

Servlet版性能測試

主要考慮的Servlet版運行方式有：

一：Servlet在Web容器中的運行機制

1.單獨一個無狀態(tài)的Servlet實例運行

即Web容器里的多個線程調(diào)用一個Servlet實例的運行方式

2.多個Servlet實例

在Web容器中有多個Servlet實例的對象池，并有多個Web容器線程來分別調(diào)用執(zhí)行

-：Servlet連接數(shù)據(jù)庫的方式

1.一對一

即可每個Servlet實例都有直接的數(shù)據(jù)庫連接。

具體方式有：

1＞在Servlet實例的每個處理方法中每次都調(diào)用數(shù)據(jù)庫連接，然后用此連接進行數(shù)據(jù)庫

的查詢等操作，最后關閉并釋放此連接。

2＞在Servlet實例的初始化操作時就連接一個“長”的數(shù)據(jù)庫連接，直到Servlet實例

在destroy時關閉并釋放此數(shù)據(jù)庫連接。

因為現(xiàn)在的數(shù)據(jù)庫操作主要是查詢，沒有對數(shù)據(jù)庫的增加、修改等操作，多用戶業(yè)務查

詢、Web容器多線程同時對?個Servlet的同一個數(shù)據(jù)庫連接進行操作應該會沒有數(shù)據(jù)操作

同步等問題。

2.使用Web容器的數(shù)據(jù)源

這里主要是使用Web容器的數(shù)據(jù)源一數(shù)據(jù)庫連接池。

在理論上這種方式能提供最佳的性能。這是也是測試各種Web容器產(chǎn)品在數(shù)據(jù)庫連接

池上實現(xiàn)的性能情況。

這里主要看Web容器的在各種應用情況下的最優(yōu)化配置。

Servlet與數(shù)據(jù)源連接的實現(xiàn)方式：

Servlet直接從Web容器配置中取得數(shù)據(jù)源及其連接對象，然后通過此連接對象來操作

數(shù)據(jù)庫。對于數(shù)據(jù)庫連接對象的管理山Web容器來管理。

三：要考慮的問題：

1.大數(shù)據(jù)量傳輸問題

大數(shù)據(jù)量通過Servlet實例從數(shù)據(jù)庫中取得并整理后，如何有效的傳輸?shù)娇蛻舳薎E,并

且Servlet實例如何有效在Web容器中處理這些大數(shù)據(jù)量。

2.對各種JDBC版本的測試

即不同的數(shù)據(jù)庫使用其自己專用的JDBC來連接，在性能上應該要好一些。

這里也可比較WeblogicServer中實現(xiàn)JDBC與各種數(shù)據(jù)庫（MSSQL、Oracle）專用的差

別，從測試的結果看出WeblogicServer的技術實例以及是否真正做到了數(shù)據(jù)庫連接等處理

的優(yōu)化了嗎。

3.WeblogicServer的優(yōu)化配置

3.1對象池配置

包括應用邏輯處理對象的對象池化以及使用數(shù)據(jù)源時的數(shù)據(jù)庫連接對象池在各種具體

應用環(huán)境下的優(yōu)化配置。

3.2線程池配置

以上兩個方面涉及到對象池化和串行化處理的策略。

3.3WeblogicServer的配置的各種參數(shù)的相應情況下的配置

1>JAVAVM（JAVA虛擬機）參數(shù)在各種應用情況下的配置。

2>WeblogicServer本身的各種參數(shù)配置。

鑒于以上的考慮對Servlet版的測試規(guī)劃為以下幾種測試用例：

序號部署包g（*.JAR*.WAR*.EAR等）數(shù)據(jù)源配置WeblogicServer

的配置預期結果說明可能出現(xiàn)的問題和現(xiàn)象

1ServletQueryForPerConn.war在每此業(yè)務處理時創(chuàng)建數(shù)據(jù)庫連接，操作完畢后關閉并

釋放。

通過Web.xml配置文件來配置JDBC的驅動類型和連接。直接部署

ServletQueryForPerConn.jar部署包。

Web容器中只有一個Serverlet實例。

建議配置較多的線程數(shù)量。

性能差。

在每此業(yè)務處理時創(chuàng)建數(shù)據(jù)庫連接，操作完畢后關閉并釋放。

此包中沒有設計到線程同步的有關代碼。數(shù)據(jù)庫很忙（因為數(shù)據(jù)庫要接收頻繁的數(shù)據(jù)

庫連接）。

可能瓶頸在數(shù)據(jù)庫對頻繁的連接處理。

數(shù)據(jù)庫事務方面：由于是在每次處理時就調(diào)用數(shù)據(jù)庫連接并查詢，因此數(shù)據(jù)庫的事務處

理應該是單獨在一個獨立的處理過程中，與并行的其他線程的處理沒有關系。

2ServletQueryForOnceConn.warServlet對象只是的初始化時連接與數(shù)據(jù)庫的一個連接，

在以后的操作中式中使用這個連接。

通過Web.xml配置文件來配置JDBC的驅動類型和連接。直接部署

ServletQueryForOnceConn.jar包；

Web容器只有一個Servlet實例。

建議配置較多的線程數(shù)量。

性能較差。

Servlet對象只是的初始化時連接與數(shù)據(jù)庫的一個連接，在以后的操作中式中使用這個

連接。

此包中沒有設計到線程同步的有關代碼。數(shù)據(jù)庫連接只有一個。

可能瓶頸在Web容器的多個線程對同一個數(shù)據(jù)庫連接對象的同步等處理（這些同步處

理是Web容器自己管理的）。

可能出現(xiàn)查詢的數(shù)據(jù)在多個客戶請求中打亂（因為同時使用同個數(shù)據(jù)庫通信通道）；

并且多個線程（單獨的處理單元）可能會在同?個處理事務中，可能各個處理單元會串

行操作數(shù)據(jù)庫（這要看數(shù)據(jù)庫的具體實現(xiàn)了）。

3ServletQueryForConnPool.war直接使用Web容器的數(shù)據(jù)源和數(shù)據(jù)庫連接池。配置數(shù)

據(jù)源及數(shù)據(jù)庫連接池。

建議根據(jù)實際情況優(yōu)化配置數(shù)據(jù)源和連接池。如可建立多個連接池等配置。性能好。

Servlet實例不管數(shù)據(jù)庫連接，而是直接從Web容器中取得數(shù)據(jù)庫連接。數(shù)據(jù)庫的連接對象

有Web容器全權管理。

此包中沒有設計到線程同步的有關代碼。對Web容器的數(shù)據(jù)庫連接池的配置可能要根

據(jù)具體情況進行有效的調(diào)整（如數(shù)據(jù)庫連接對象個數(shù)和Web容器配額的線程個數(shù)的關系

等）。如果配置不佳可能是性能瓶頸在Web容器或者在數(shù)據(jù)庫方;

4ServletQueryForConnPool.war

（同測試3）同測試3Web容器的數(shù)據(jù)源重新配置為數(shù)據(jù)庫產(chǎn)品專用的JDBC驅動器。

性能好。測試目的是比較各種不同的JDBC數(shù)據(jù)連接驅動器的性能，以便得出根據(jù)不同的數(shù)

據(jù)庫產(chǎn)品選擇最佳的JDBC驅動器。

只測試數(shù)據(jù)庫產(chǎn)品提供的專用JDBC驅動器。

（說明：因為測試3在理論上性能是最好，因此選用測試3。測試方法和測試3一樣，

這樣才有可比性。）同測試3。

5servletQueryDS_Cache.war同測試3同測試3性能一般

使用一變量來緩存查詢的數(shù)據(jù)，用戶以后的分頁查詢查詢操作是直接從此緩存中取得

的。

這種方式對Web容器的內(nèi)存要求高，效果不是很好，對數(shù)據(jù)量查詢小的效果可能會好

些。優(yōu)點：

減少的了對數(shù)據(jù)庫訪問的次數(shù)。

缺點：

需要較大的內(nèi)存。對Weblogic容器的內(nèi)存要求高，對于有大量用戶的查詢操作，并且

查詢的結果集較大時，可能對整個系統(tǒng)的性能是個很大的瓶頸。

對大量數(shù)據(jù)的分頁處理

問題描述：

背景L一客戶通過IE請求Web服務器查詢數(shù)據(jù)，而查詢結果是上千條甚至是上萬條

記錄，要求查詢結果傳送到IE客戶端并分頁顯示。

背景2：一客戶通過IE或者其他方式請求Web服務器查詢數(shù)據(jù)，而查詢結果是上千條

甚至是上萬條記錄，并要求查詢結果把包傳送到客戶的E-mail中。

問：對于這樣的有大量數(shù)據(jù)的結果集，在Web服務器端如何有效的處理？

可能涉及到的問題：

1.內(nèi)存占用

大量數(shù)據(jù)的結果集，可能要

2.傳輸速度及策略

具體的分頁處理技術

序號名稱處理方法針對的數(shù)據(jù)庫例子說明備注

1游標查詢直接使用ResultSet來處理。ResultSet是直接在數(shù)據(jù)庫上建立游標，然后通

過ResultSet的行位置定位接口來獲得指定行位置的記錄。

當用戶第一請求數(shù)據(jù)查詢時，就執(zhí)行SQL語句查詢，獲得的ResultSet對象及其要使用

的連接對象都保存到其對應的會話對象中。

以后的分頁查詢都通過第一次執(zhí)行SQL獲得的ResultSet對象定位取得指定行位置的記

錄。

最后在用戶不再進行分頁查詢時或會話關閉時，釋放數(shù)據(jù)庫連接和ResultSet對象等數(shù)

據(jù)庫訪問資源。

說明：在用例分頁查詢的整個會話期間，?個用戶的分頁查詢就要占用一個數(shù)據(jù)庫連接

對象和結果集的游標，這種方式對數(shù)據(jù)庫的訪問資源占用比較大，并且其利用率不是很高。

所有的數(shù)據(jù)庫產(chǎn)品。優(yōu)點：

減少了數(shù)據(jù)庫連接對象的多次分配獲取，減少了對數(shù)據(jù)庫的SQL查詢執(zhí)行。

缺點：

占用數(shù)據(jù)庫訪問資源一數(shù)據(jù)庫連接對象，并占用了數(shù)據(jù)庫上的資源一游標。而這些資源

都是十分寶貴的有限制的。

結論：

這種的數(shù)據(jù)庫查詢分頁處理方式不是最佳的。一般不適用這種方式。

2定位行集SQL查詢主要是直接使用數(shù)據(jù)庫產(chǎn)品的提供的對查詢的結果集可定位行范

圍的SQL接口技術。

在用戶的分頁面查詢請求中，每次可取得查詢請求的行范圍的參數(shù)，然后使用這些參數(shù)

生產(chǎn)取得指定行范圍的的SQL查詢語句，然后每次請求獲得一個數(shù)據(jù)庫連接對象并執(zhí)行SQL

查詢，把查詢的結果返回給用戶，最后釋放說有的數(shù)據(jù)庫訪問資源。

說明：這種方式需要每次請求時都要執(zhí)行數(shù)據(jù)庫的SQL查詢語句；對數(shù)據(jù)庫的訪問資

源是使用完就立即釋放，不白白占用數(shù)據(jù)庫訪問資源。對特定（提供了對查詢結果集可定

位功能的）的數(shù)據(jù)庫產(chǎn)品。

如：Oracle,DB2,PostgreSQL,mySQL等。（MSSQLServer沒有提供此技術。）如：

1.Oracle數(shù)據(jù)庫使用關鍵字：rowid或rownum

2.DB2:

rowid或rownum（）

3.PostgreSQL使用LIMIT和OFFSET

4.MySQL使用Limit優(yōu)點：

這種技術是直接使用數(shù)據(jù)庫產(chǎn)品自己提供的可對查詢結果集定位行范圍過濾的功能，因

此直接利用了數(shù)據(jù)庫的性能對此分頁查詢的優(yōu)化功能。

對數(shù)據(jù)庫的訪問資源（數(shù)據(jù)庫