JAVA认证公共基础知识J2EE知识

J2EE：教你提升JSP应用程序的七大绝招

你时常被客户抱怨JSP页面响应速度很慢吗？你想过当客户访问次数剧增时，你的WEB

应用能承受II益增加的访问量吗？本文讲述了调整JSP和servlet的一些非常实用的方法，它

可使你的servlet和JSP页面响应更快，扩展性更强。而且在用户数增加的情况下，系统负载

会呈现出平滑上长的趋势。在本文中，我将通过一些实际例子和配置方法使得你的应用程序

的性能有出人意料的提升。其中，某些调优技术是在你的编程工作中实现的。而另一些技术

是与应用服务器的配置相关的。在本文中，我们将详细地描述怎样通过调整servlet和JSP

页面，来提高你的应用程序的总体性能。在阅读本文之前，假设你有基本的servlet和JSP

的知识。

方法一：在servlet的init()方法中缓存数据

当应用服务器初始化servlet实例之后，为客户端请求提供服务之前，它会调用这个

servlet的init()方法。在一个servlet的生命周期中,init()方法只会被调用一次。通过在init()

方法中缓存一些静态的数据或完成一些只需要执行一次的、耗时的操作，就可大大地提高系

统性能。

例如，通过在init()方法中建立一个JDBC连接池是一个最佳例子，假设我们是用jdbc2.0

的Datasource接口来取得数据库连接，在通常的情况下，我们需要通过JNDI来取得具体的

数据源。我们可以想象在一个具体的应用中，如果每次SQL请求都要执行•次JNDI查询的

话，那系统性能将会急剧下降。解决方法是如下代码，它通过缓存DataSource,使得下一次

SQL调用时仍然可以继续利用它：

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提供了•个实用的技术，即自动重载技术，它为开发人员提供了一个好的开

发环境，当你改变servlet和JSP页面后而不必重启应用服务器。然而，这种技术在产品运行

阶段对系统的资源是一个极大的损耗，因为它会给JSP引擎的类装载器(classbader)带来极大

的负担。因此关闭自动重载功能对系统性能的提升是一个极大的帮助。

方法3:不要滥用HttpSession

在很多应用中，我们的程序需要保持客户端的状态，以便页面之间可以相互联系。但不

幸的是由于HTTP具有天生无状态性，从而无法保存客户端的状态。因此•般的应用服务器

都提供了session来保存客户的状态。在JSP应用服务器中，是通过HttpSession对像来实现

session的功能的，但在方便的同时，它也给系统带来了不小的负担。因为每当你获得或更

新session时，系统者要对它进行费时的序列化操作。你可以通过对HttpSession的以下几种

处理方式来提升系统的性能：

?如果没有必要，就应该关闭JSP页面中对HttpSession的缺省设置：如果你没有明确

指定的话，每个JSP页面都会缺省地创建一一个HttpSession。如果你的JSP中不需要使用session

的话，那可以通过如下的JSP页面指示符来禁止它：

<%@pagesession="false"%>

?不要在HttpSession中存放大的数据对像：如果你在HttpSession中存放大的数据对像

的话，每当对它进行读写时，应用服务器都将对其进行序列化，从而增加了系统的额外负担。

你在HttpSession中存放的数据对像越大，那系统的性能就下降得越快。

?当你不需要HttpSession时，尽快地释放它：当你不再需要session时，你可以通过调

用HttpSession.invalidate。方法来释放它。

?尽量将session的超时时间设得短一点：在JSP应用服务器中，有一个缺省的session

的超时时间。当客户在这个时间之后没有进行任何操作的话，系统会将相关的session自动

从内存中释放。超时时间设得越大，系统的性能就会越低，因此最好的方法就是尽量使得它

的值保持在一个较低的水平。

方法4:将页面输出进行压缩

压缩是解决数据冗余的一个好的方法，特别是在网络带宽不够发达的今天。有的浏览器

支持gzip(GNUzip)进行来对HTML文件进行压缩，这种方法可以戏剧性地减少HTML文件的

下载时间。因此，如果你将servlet或JSP页面生成的HTML页面进行压缩的话，那用户就会

觉得页面浏览速度会非常快。但不幸的是，不是所有的浏览器都支持gzip压缩，但你可以

通过在你的程序中检查客户的浏览器是否支持它。下面就是关于这种方法实现的一个代码片

段：

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:使用线程池

应用服务器缺省地为每个不同的客户端请求创建一个线程进行处理，并为它们分派

service。方法，当service。方法调用完成后，与之相应的线程也随之撤消。由于创建和撤消

线程会耗费一定的系统资源，这种缺省模式降低了系统的性能。但所幸的是我们可以通过创

建一个线程池来改变这种状况。另外，我们还要为这个线程池设置一个最小线程数和一个最

大线程数。在应用服务器启动时，它会创建数量等于最小线程数的一个线程池，当客户有请

求时，相应地从池从取出一个线程来进行处理，当处理完成后，再将线程重新放入到池中。

如果池中的线程不够地话,系统会自动地增加池中线程的数量，但总量不能超过最大线程数。

通过使用线程池，当客户端请求急剧增加时，系统的负载就会呈现的平滑的上升曲线，从而

提高的系统的可伸缩性。

方法6:选择正确的页面包含机制

在JSP中有两种方法可以用来包含另一个页面：1、使用include指示符(V%@includee

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

>)»在实际中我发现，如果使用第一种方法的话，可以使得系统性能更高。

方法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的生命周期的话，它将影响系统的性能。

举例来说，如果你只想在一次请求中使用某个bean,但你却将这个bean的生命周期设

置成了session,那当这次请求结束后，这个bean将仍然保留在内存中，除非session超时

或用户关闭浏览器。这样会耗费一定的内存，并无谓的增加了JVM垃圾收集器的工作量。

因此为bean设置正确的生命周期，并在bean的使命结束后尽快地清理它们，会使用系统性

能有一个提高。

其它一些有用的方法

?在字符串连接操作中尽量不使用“+”操作符：在java编程中，我们常常使用“+”

操作符来将几个字符串连接起来，但你或许从来没有想到过它居然会对系统性能造成影响

吧？由于字符串是常量，因此JVM会产生一些临时的对像。你使用的“+”越多，生成的

临时对像就越多，这样也会给系统性能带来一些影响。解决的方法是用StringBuffer对像来

代替“+”操作符。

?避免使用System.out.println。方法：由于System.out.println()是一种同步调用，即在调

用它时，磁盘I/O操作必须等待它的完成，因此我们要尽量避免对它的调用。但我们在调试

程序时它又是一个必不可少的方便工具，为了解决这个矛盾，我建议你最好使用Log4j工具

(http://J),它既可以方便调试，而不会产生System.out.println()这样的方法。

?ServletOutputStream与Printwriter的权衡:使用Printwriter可能会带来一些小的开

销，因为它将所有的原始输出都转换为字符流来输出，因此如果使用它来作为页面输出的话，

系统要负担•个转换过程。而使用ServletOutputStream作为页面输出的话就不存在一个问

题，但它是以二进制进行输出的。因此在实际应用中要权衡两者的利弊。

总结

本文的目的是通过对servlet和JSP的一些调优技术来极大地提高你的应用程序的性能，

并因此提升整个J2EE应用的性能。通过这些调优技术，你可以发现其实并不是某种技术平

台(比如J2EE和.NET之争)决定了你的应用程序的性能，重要是你要对这种平台有一个较

为深入的了解，这样你才能从根本上对自己的应用程序做一个优化！

J2EE常见问题J2EE平台的特征与优点

问题：什么是Java2Platform,EnterpriseEdition(J2EE)?

Java2Platform,EnterpriseEdition(J2EE)是一组协调规范与实践，它们组合起来，能够实

现用于开发、部署和管理多层的以服务器为中心的应用程序的解决方案。建立在Java2

Platform,StandardEdition(J2SE)的基础上，J2EE平台添加了一些必要的能力，以便为企业

级提供完整的、稳定的、安全的和快速的Java平台。由于它大大减少了开发和部署多层解

决方案的成本和复杂程度，带来了可以快速进行部署并且容易增强的服务，因此它为企业创

造了价值。

问题：J2EE平台有哪些主要优点？

J2EE平台提供了以下特征：

完整的Web服务支持。J2EE提供了一个框架，以便在Java平台上开发和部署Web

服务。JavaAPIforXML-basedRPC(JAX-RPC)使得Java技术开发人员能够开发基于SOAP的、

能够互操作并且可移植的Web服务。开发人员可以使用标准的JAX-RPC编程模型来开发

基于SOAP的Web服务客户端和端点。Web服务端点是使用Web服务描述语言(WSDL)文

档来描述的。JAX-RPC使得JAX-RPC客户端能够调用跨异构平台上开发的Web服务。同样，

JAX-RPCWeb服务端点可以由异构客户端调用。有关进一步信息，请参阅

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

更加快速的解决方案面市时间。J2EE平台使用“容器”来简化开发。J2EE容器提供

了业务逻辑与资源和生命周期管理的分离，这表明开发人员可以将重点放在编写业务逻辑

(它们的增值)上，而不是放在企业基础结构上。例如，EnterpriseJavaBeans(EJB)容器(由J2EE

供应商实现)处理了分布式通信、线程处理、缩放、事务管理等。与此类似，JavaServlets简

化了Web开发，因为它在Web容器中提供了针对组件、通信和会话管理的基础结构，而

该容器又与Web服务器集成。

自由的选择。J2EE是一组许多供应商都可以实现的标准。供应商可以自由地完成实现,

但在标准或API上却不能自由完成。Sun为J2EE持证人提供了综合的J2EECompatibility

TestSuite(CTS)oJ2EECTS有助于在应用程序供应商之间保证兼容性，从而保证了针对J2EE平

台编写的应用程序和组件的可移植性。J2EE平台为服务器带来了“WriteOnce,Run

Anywhere”(编写一次，随处运行)的能力。

简化的连接。J2EE技术使得可以容易地连接已经拥有的应用程序和系统，并将这些能

力带到了Web、手机和设备。J2EE提供了JavaMessageService,以便以采用松耦合、异步

的方式来集成不同的应用程序。J2EE也提供了CORBA支持，以便通过远程方法调用来紧

密地链接系统。J2EE平台还具有J2EEConnectors,用于链接企业信息系统，比如ERP系统、

打包的财务应用程序和CRM应用程序。

通过提供具有如下特征的平台：更加快速的解决方案面市时间、自由的选择和简化的连

接，J2EE平台可帮助IT缩减TCO,同时免去了针对企业软件要求的单一源码。

问题：J2EE平台是否能够与其他WS-I实现进行互操作？

是的，前提是其他实现要符合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数据访问API。

问题：J2EE1.4平台新增了什么？J2EE1.4提供了完整的Web服务支持功能，该支持是

通过新的JAX-RPC1.1API来完成的，该API支持基于servlets和企业beans的服务端点。

JAX-RPC1.1提供了与基于WSDL和SOAP协议的Web服务的互操作性。J2EE1.4平台也

支持J2EE规范(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应用程序。

现在，J2EE平分使得可以容易地开发Web前端，并且该前端具有JavaServlet和

JavaServerPages(JSP)技术的增强功能。现在，servlets也支持请求侦听器和增强的筛选器。

JSP技术已经简化了页面和扩展的部署模型，由于它引入了简单的表达语言、标签文件和更

加简单的标签扩展API等特性。对于开发人员，特别是熟悉脚本语言的开发人员来说，这

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

J2EE平台的其他增强功能包括J2EEConnectorArchitecture,它提供了传入资源适配器

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

Web服务端点、计时器服务以及EJBQL和消息驱动beans的增强功能。J2EE1.4平台也

包括部署描述符的增强功能。现在，它们是使用XMLSchema来定义的，开发人员也可使

用XMLSchema来验证XML结构。

问题：我现在应该使用哪一版本的平台——1.4或1.3?

J2EE1.4规范是最新规范，因此现在可以使用J2EE1.4SDK来部署应用程序。不过，为

了提高可靠性、可伸缩性和性能，推荐在J2EE1.4商业实现上部署应用程序，该商业实现

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

是至关重要的情况下，那就应该考虑使用支持J2EE1.3的高性能应用程序服务器，比如Sun

JavaSystemApplicationServer7。许多应用程序服务器供应商期望在春季之前发布J2EE1.4

平台版本的产品。

问题：针对J2EE1.3平台编写的应用程序是否可以在J2EE1.4平台实现上运行？

针对J2EE1.3规范编写的J2EE应用程序将可以在J2EE1.4实现上运行。向后兼容是

规范的要求。

问题：J2EE体系结构是如何与SunJavaEnterpriseSystem关联的？

J2EE体系结构是SunJavaSystemApplicationServer的基础，它是SunJavaEnterprise

System的组件。在当前SunJavaEnterpriseSystem中，JavaSystemApplicationServer是以

J2EE1.3平台为基础的，并为Web服务提供了附加的支持。熟悉J2EE技术的开发人员可

以容易地应用他们的技术，来生成使用SunJavaEnterpriseSystem的应用程序，包括Web

服务应用程序。有关进一步信息，请参阅SunJavaEnterpriseSystemWeb站点。

问题：我该怎样学习J2EE平台？

有关J2EE平台以及如何获得规范的进一步信息，请参阅http://java.sun.eom/j2ee/o

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

来亲自体验这些API。J2EE1.4SDK提供了兼容于J2EE1.4的应用程序服务器，并将它作为

开发和部署支持Web服务、多层的企业应用程序的基础。可以从如下站点免费下载J2EE

1.4SDK：/j2ee/downloads/index.htmlo

J2EE文档页面提供了一些链接，它们指向各种自我导向的学习材料，比如针对初学者

的教程和FAQo

需要更高级资料的开发人员可以访问JavaBlueprintsfortheenterprise。企业的Java

Blueprints是最佳实践指导原则，可用于设计和生成基于J2EE的应用程序。设计指导文档

提供了两样东西。首先，它提供了在Java2平台上生成N层应用程序的指导原则。其次,

它提供了一组设计模式，用于设计这些应用程序，以及提供了一组有关如何生成应用程序的

例子或诀窍。

Sun教育服务也提供了许多培训课程，它们可以引导您获得下面三种证书的•种：Sun

CertifiedWebComponentDeveloper,SunCertifiedBusinessComponentDeveloper利ISun

CertifiedEnterpriseArchitecto

J2EE程序员应该掌握的Linux系统的知识

大型J2EE应用都在建构在linux环境下的。开发环境下我们可以通过samba映射成本地

的网络驱动器，直接在windows环境下进行编程调试。但是最后的发布还是要到linux环境，

同时我们对网上web服务器和数据库服务器的应用管理（比如自动脚本发布等），应用监控

（web服务是否正常、mysql数据库的使用情况）、系统监控（监控磁盘空间的使用情况等）

都要求程序员熟悉必要的linux知识。

当然程序员不必对整个linux系统样样精通。下面列出程序员基本需要掌握的linux知识。

一、linux的基本命令

1、用户管理

userdel删除用户帐号

useradd增加用户账号

su改变当前用户的ID

2、文件目录管理

Is浏览目录，查看当前目录下的文件和文件名

chmod修改文件权限

chown改变文件所有者

cp复制文件

cd改变当前目录

mv重命名文件或移动文件

rm删除文件或者目录

pwd当前目录

scp远程拷贝

alias别名

3、其他命令

In在文件之间建立链接

tail输出文件内容后面的部分，一般我们会通过tail-f实时查看当前程序打印的日志。

type查看一个命令所在路径

wc查看行数

grep在文件内容中查找

find查找文件

date查看日期

crontab制定计划任务，通常用于系统监控。

df查看磁盘剩余空间，你最好在crontab中写个脚本监控磁盘的空间。超过90%就给

相关的人员发emailo

ps查看进程状态

top查看CPU的使用率

kill终止进程

killalljava程序员最喜欢用killall-9java吧

w查看登录用户和他们正在做什么，也可以看看系统的load,load太高，就该找找原

因了。

who查看当前用户的便当情况

tar解压或压缩文件

echo控制台输出

wgethttp访问

rpmrpm包管理

4、重定向、管道

5、标准输出、标准错误

6、使用'屏蔽•个特殊字符的含义

7、正则表达式

二、熟练掌握vim编辑器

三、liunx环境下shell脚本、perl脚本的编写

为了对网上服务器应用进行管理，通常需要编写一些脚本。

脚本的编写重点掌握下面几点：

1、理解双引号、单引号、反引号的含义。

2、反斜线的使用。

3、shell脚本赋值语句左边的变量名不要加上$,常写perl脚本的常犯此错误。

4、字符串比较长，含有空格的时候，作为一个参数时脚本出错，用双引号把字符串括

起来。

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

四、基本软件包的安装

apache、resin、mysql

一般的步骤就是：

configure

make

makeinstall

J2EE的MVC体系结构及其设计模式

目前大多数企业采用J2EE技术的结构设计与解决方案。对于我们学习和研究J2EE体系

结构来说，了解与掌握J2EE体系结构的设计方法及一些常用模式是必须的；模型-视图-控制

(model-view-control,简称MVC)结构是目前最常见的J2EE应用所基于的体系结构，MVC主

要适用于交互式的Web应用，尤其是存在大量页面及多次客户访问及数据显示；相比较而

言，一个工作流体系结构更多应用于过程控制和较少交互的情况下；除了体系结构外，J2EE

的设计模式对我们解决应用系统的设计也有很大的帮助。

一、J2EE的模型-视图-控制(MVC)体系结构

模型-视图-控制结构是交互式应用程序广泛使用的一种体系结构。它有效地在存储和展

示数据的对象中区分功能模块以降低它们之间的连接度，这种体系结构将传统的输入、处理

和输入模型转化为图形显示的用户交互模型，或者换一种说法，是多层次的Web商业应用；

MVC体系结构具有三个层面：模型(Model)、视图(View)和控制(Controller),每个层面有其

各自的功能作用，MVC体系结构如下：

J2EE的MVC体系结构及其设计模式

图1MVC体系结构

模型层负责表达和访问商业数据，执行商业逻辑和操作。也就是说，这一层就是现实生

活中功能的软件模拟；在模型层变化的时候，它将通知视图层并提供后者访问自身状态的能

力，同时控制层也可以访问其功能函数以完成相关的任务。

视图层负责显示模型层的内容。它从模型层取得数据并指定这些数据如何被显示出来。

在模型层变化的时候，它将自动更新。另外视图层也会将用户的输入传送给控制器。

控制层负责定义应用程序的行为。它可以分派用户的请求并选择恰当的视图以用于显

示，同时它也可以解释用户的输入并将它们映射为模型层可执行的操作;在•个图形界面中，

常见的用户输入包括点击按钮和菜单选择。在Web应用中，它包括对Web层的HTTPGET

和POST的请求：控制层可以基于用户的交互和模型层的操作结果来选择下一个可以显示的

视图，一个应用程序通常会基于一组相关功能设定一个控制层的模块，甚至一些应用程序会

根据不同的用户类型具有不同的控制层设定，这主要是由于不同用户的视图交互和选择也是

不同的。

在模型层、视图层和控制层之间划分责任可以减少代码的重复度，并使应用程序维护起

来更简单。同时由于数据和商务逻辑的分开，在新的数据源加入和数据显示变化的时候，数

据处理也会变得更简单。

二、J2EE设计模式

一个设计模式描述了对于特定设计问题被验证的解决方案,它综合了所有开发者对这个

问题所在领域的知识和见解；同时也是对于常见问题的可重用方案，它们一般适用于单个问

题，但是组织在一起就可以提供整个企业系统的解决方案。下面我们列举八种常用于J2EE

平台的设计模式，并对每种模式作简单的介绍，便于大家学习、理解与灵活应用。

1、前控制器

前控制器(frontcontroller)主要提供一种可以集中式管理请求的控制器，一个前控制器可

以接受所有的客户请求，将每个请求递交给相应的请求句柄，并适当地响应用户。

前控制器也是表示层的设计模式，它的出现主要是由于表示层通常需要控制和协调来自

不同用户的多个请求，而这种控制机制又根据不同的需要，可能会集中式控制或分散式控制。

换句话说，就是应用系统需要对于表示层的请求提供i个集中式控制模块，以提供各种系统

服务，包括内容提取、视图管理和浏览，如果系统中没有这种集中式控制模块或控制机制，

每个不同的系统服务都需要进行单独的视图处理，这样代码的重复性就会提高，致使系统开

发代价提高；同时，如果没有一个固定模块管理视图之间的浏览机制，致使其浏览功能下放

于每个不同的视图中，最终必将使得系统的可维护性受到破坏；本文中我们主要讨论的是集

中式控制模块，而不是分散式控制，因为前者更适合于大型的应用系统。

基于上面所说的问题，研究人员提出了前控制器的设计模式。在这种模式中，控制器提

供一个处理不同请求的控制点，这里的处理工作包括安全事务、视图选择、错误处理和响应

内容的生成；通过将这些处理工作集中在一点进行，大大地减低了Java代码量，同时这种

方法也可以减少在视图模块的程序逻辑，保证了在不同请求之间可以重用大量的逻辑代码。

通常，控制器都是和一个分派组件联合工作的，分派组件主要是用于视图管理和浏览，也就

是为用户选择下一个应该显示的视图，并同时提供对于相关显示资源的控制。分派组件可以

包含在控制器之内，或是在另外一个单独的组件中：虽然前控制器模式推荐对于全部的请求

使用统一处理，但是它也没有限制在个系统中只能具有一个控制器，在系统中的每个层次

都可以具有多个控制器，并且映射至不同的系统服务，下图2显示了前控制器的类图。

图2前控制器的类图

图3显示了前控制器的序列图，表示一个控制器如何处理相关的请求。

图3前控制器序列图

下面我们来讨论一下图3的各个组件。

2、控制器

控制器(controller)是负责处理各种客户请求的控制点，并可以将一定的职能(如用户认证

等)下放给帮助类。

⑴分派组件(Dispatcher)。•个分派组件主要是用于视图的管理和浏览，为用户选择下

一个可以显示的视图，并管理相关的显示资源；分派组件可以在一个控制器内运行，或者作

为一个单独的组件与控制器协同工作；开发人员可以在分派组件中实现静态的视图分派技

术，或是复杂的动态分派。

(2)帮助类(Helper)。帮助类负责帮助一个视图或控制器来完成其处理工作，因此，帮助

类具有多项职责，包括收集数据、存储中间数据模型等；另外，帮助类也可以在保证数据完

整性和准确性的情况卜，为不同显示需求修改数据模型；也就是说，根据用户的请求，帮助

类可以向视图提供未经处理的原始数据，或是已经格式化后的Web内容，一个视图同时可

以和多个帮助类协同工作，而后者通常是由JavaBeans和标签(tag)实现的。

3、视图

视图(view)负责向用户显示信息，而帮助类则负责支持视图的工作，即打包和建立相应

的数据模型，下面我们介绍几种可以实现控制器的方法。

1)基于Servlet前控制器

这种方法建议使用servlet来实现一个控制器，尽管在语法上相差无几，但是它比使用

JSP来实现要优越•些；因为控制器所进行的请求处理，多数都是与程序运行和控制流动相

关的，这些处理工作虽然与显示模式相关，但是实际上是逻辑独立的，所以它们更适合在

servlet中实现，而不是JSP技术中；使用这种方法也存在一些弱点，比如说servlet无法使

用JSP运行环境的资源，如请求参数等,但是这个弱点也不是不能解决的，我们可以在servlet

中建立相关的句柄来访问同样的资源，当然其代码会变得繁琐一点。

2)基于JSP的前控制器

这种方法建议使用JSP页面实现控制器，尽管语法上相同，但是Servlet方案要比其优

越一些；因为控制器所处理的逻辑一般都不是有关显示模式的，所以在JSP页面中实现控制

器似乎有点风马牛不相及；使用这种方法也不利于开发团队的角色和职责的分配，即软件开

发人员需要在负责显示逻辑的JSP页面中修改请求处理的代码，通常，这种工作都是相当复

杂的，尤其考虑整个JSP页面的编程、编译、测试和调试错误。

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

如果分派组件没有较多功能，开发人员可以在控制器实现该组件。

4)基础前端

基于使用servlet实现前控制器，这种方案建议实现•个控制器作为基础类，这样其他

的控制器可以在其之上扩展；这个基础类可以包含一些通用的逻辑实现，它的子类就会重载

这些实现代码，这种方法也有一定的缺陷，当有许多子类继承这个基础类，并大量地重用代

码时，那么就有可能出现•个类的改变会影响到所有子类的情况。

5)用过滤器实现前控制器

过滤器提供了与用户请求的中心处理相类似的功能，也就是说，控制器的一些功能可以

由过滤器来实现，这种方案的过滤器主要负责处理请求的截取和解释，而不是请求的处理和

响应的生成;通常可以为应用系统提供一个核心控制点，以处理所有的系统服务和程序逻辑,

核心控制也就表明了所有的请求都可以简单地被跟踪和记录，从而方便各种服务功能的实

施；当然，它也存在一些缺点，一个核心控制点的小问题可能会引发系统的崩溃，但在应用

系统的实际开发中，这并不是个问题，因为通常我们都会在同•个层面上实现多个控制器，

从而避免了这个缺陷；在控制器中，开发人员可以很方便地实现一个检查安全机制的组件，

从而可以在最外层屏蔽对系统的恶意访问，另外使用控制器也会提高系统模块的可重用性，

尤其在控制器同时使用帮助类的时候。

4、视图帮助

视图帮助(Viewhelper)是属于表示层的设计模式，-个视图帮助可以包含相关视图中的

数据访问和内容显示的逻辑，并可以精炼简化视图；显示逻辑主要是关于如何格式化页面上

的数据，而访问逻辑则是关于如何取出数据，视图帮助通常用来显示数据的JSP标记(tag)或

是读取数据的JavaBean。

这种设计模式的出现主要是由于目前的应用系统通常需要实时地开发显示内容,并且能

处理动态的程序数据。如果这些程序数据的访问逻辑和显示逻辑的关系过于紧密，则系统的

表示层就会经常需要改动，从而系统的灵活性、重用性会大大地受到破坏；同时在相同的模

块中实现访问逻辑和显示逻辑将会影响系统的模块化，也会使得开发团队的任务划分不清。

一个视图通常包含格式化信息，并将其处理任务分发给自己的帮助类，后者通常是用

JavaBeans或标记(tag)来实现的，帮助类同时可以存储视图的中间数据模型并实现数据适配

器的功能，即适当地转化数据格式；开发人员可以采用多种方法实现视图组件，通常，开发

人员可以使用JSP来实现，并且这也是一种值得推荐的方法。当然，相应地开发人员也可以

使用Servlet来实现它，将视图中一定的程序逻辑植入到帮助类中，会有利于应用系统的模

块化和可重用性。系统可以使用同一个帮助类为不同的用户显示不同的数据信息，并在不同

的显示格式下显示；通常，如果开发人员发现视图的JSP页面中存在大量的脚本代码时，就

可以考虑使用视图帮助这种模式了，因为在这种情况下，基本都是程序逻辑和显示逻辑具有

过于紧密的联系:这时开发人员可以将•些适用于所有类型的请求的逻辑处理放置到一定的

帮助类中，而根据需要，也可以将另外一些逻辑处理放置在视图层上的其他程序模块中，比

如说以前讨论过的截取过滤器。

视图帮助这种模式的设计理念主要是分离应用系统的逻辑职责，下面我们提供一些图

示，以方便大家更好地理解这种模式。

图4以类图(classdiagram)的形式说明了视图帮助的系统结构。

图4视图帮助类图

图5表示了视图帮助模式的序列图，它表明了这种模式中的主要成分及互相之间的运行

情况；不过需要说明的是，在很多应用系统中，客户端和视图层之间会存在一个控制器加以

适当的调节。

图5视图帮助序列图

在类图表中，大家可以发现，可能存在没有任何相关帮助类的视图，这种情况下，通常

代表视图的JSP页面会有一些静态的或小数量的脚本代码。

这里我们对于序列图中的各个元素加以简单的介绍：

⑴视图(view)。视图负责向用户展示动态数据信息，而帮助类则负责支持视图的工作，

即打包和建立相应的数据模型。

⑵帮助类(helper)。一个帮助类负责帮助视图或控制器完成相关的处理工作，包括收集

数据、存储中间模型等；帮助类也可以在保证数据完整性和准确性的情况下，为不同显示需

求修改数据模型，也就是说，根据用户的请求，帮助类可以向视图提供未经处理的原始数据,

或是已经格式化后的Web内容；一个视图同时可以和多个帮助类协同工作，而后者通常是

由JavaBeans和标记(tag)实现的。

⑶值bean(ValueBean)。值bean实际上是用于存储中间数据模型的帮助类的另一种叫法,

例如在序列图5中，businessservice就根据请求返回了一个值bean。

(4)业务服务(businessservice)«业务服务是指用户试图得到的，应用系统可以提供的相

关服务；通常来说，业务服务可以通过一个业务代表(businessdelegate)来访问，而后者主要

是提供对于业务服务的控制和保护。

在应用系统的视图模块中使用帮助类可以将不同的程序逻辑很好地分离开来，并在视图

模块之外为开发人员提供设计程序逻辑的空间；基于JavaBean和标记(tag)所开发的帮助类

通常都可以被多个视图模块重用，因此也提高了组件的重用性和可维护性：把显示逻辑从数

据处理逻辑分离出来，也有利于开发团队中角色及人物的划分；比如说，如果各种程序逻辑

过于结合的话，软件开发人员可能需要在HTML,网页中修改代码而Web设计师则需要在处

理数据访问的JSP中修改页面布置，这些情况都可能会导致系统设计和开发中由于不同技术

人员的介入，而产生相关的问题

J2EE的六种范围类型

大多数服务器端J2EE应用程序中有六种常用的范围类型：

Transaction（事务）

Request（请求）

HTTPsession（HTTP会话）

Application（应用程序）

Global（全局）

None（无）

事务范围

事务范围覆盖一个事务的整个生命周期。这个范围开始于一个事务的开始。这时会创建

一个惟一的范围键。这个范围结束于提交或回滚事务时。这时，与事务范围相关联的所有对

象被自动释放回它们的池。

请求范围

请求范围与一个servlet请求的范围对应；在容器调用servlet来处理请求之后，请求

范围立即开始。同时会创建一个惟一的范围键。在servlet完成处理之前请求范围结束。这

时，与这个范围相关联的所有对象被自动释放回它们的池。

HTTP会话范围

HTTP会话范围与一个HTTP会话的生命周期对应。它从创建一个新的HttpSession时

开始。这时会创建一个惟一的范围键。它结束于会话被销毁或过期时。这时，与这个范围相

关联的所有对象被自动释放回它们的池。

应用程序范围

应用程序范围覆盖应用程序的整个生命周期。它开始于把一个应用程序部署到应用服务

器时。这时会创建一个惟一的范围键。这个范围结束于应用程序停止运行或从应用服务器中

删除时。这时，与这个范围相关联的所有对象被自动释放回它们的池。

全局范围

全局范围是最大的范围。采用这种范围的对象不会被释放。

无范围

无范围用于不使用对象池的对象。采用这种范围的对象每次都通过自己的对象构造函数

来创建，并由Java垃圾收集器释放。对象管理器根本不管理它们。

J2EE--关于JAVA的分页查询操作技术

Servlet版性能测试

主要考虑的Servlet版运行方式有：

一：Servlet在Web容器中的运行机制

1.单独一个无状态的Servlet实例运行

即Web容器里的多个线程调用一个Servlet实例的运行方式

2.多个Servlet实例

在Web容器中有多个Servlet实例的对象池，并有多个Web容器线程来分别调用执行

-：Servlet连接数据库的方式

1.一对一

即可每个Servlet实例都有直接的数据库连接。

具体方式有：

1＞在Servlet实例的每个处理方法中每次都调用数据库连接，然后用此连接进行数据库

的查询等操作，最后关闭并释放此连接。

2＞在Servlet实例的初始化操作时就连接一个“长”的数据库连接，直到Servlet实例

在destroy时关闭并释放此数据库连接。

因为现在的数据库操作主要是查询，没有对数据库的增加、修改等操作，多用户业务查

询、Web容器多线程同时对•个Servlet的同一个数据库连接进行操作应该会没有数据操作

同步等问题。

2.使用Web容器的数据源

这里主要是使用Web容器的数据源一数据库连接池。

在理论上这种方式能提供最佳的性能。这是也是测试各种Web容器产品在数据库连接

池上实现的性能情况。

这里主要看Web容器的在各种应用情况下的最优化配置。

Servlet与数据源连接的实现方式：

Servlet直接从Web容器配置中取得数据源及其连接对象，然后通过此连接对象来操作

数据库。对于数据库连接对象的管理山Web容器来管理。

三：要考虑的问题：

1.大数据量传输问题

大数据量通过Servlet实例从数据库中取得并整理后，如何有效的传输到客户端IE,并

且Servlet实例如何有效在Web容器中处理这些大数据量。

2.对各种JDBC版本的测试

即不同的数据库使用其自己专用的JDBC来连接，在性能上应该要好一些。

这里也可比较WeblogicServer中实现JDBC与各种数据库（MSSQL、Oracle）专用的差

别，从测试的结果看出WeblogicServer的技术实例以及是否真正做到了数据库连接等处理

的优化了吗。

3.WeblogicServer的优化配置

3.1对象池配置

包括应用逻辑处理对象的对象池化以及使用数据源时的数据库连接对象池在各种具体

应用环境下的优化配置。

3.2线程池配置

以上两个方面涉及到对象池化和串行化处理的策略。

3.3WeblogicServer的配置的各种参数的相应情况下的配置

1>JAVAVM（JAVA虚拟机）参数在各种应用情况下的配置。

2>WeblogicServer本身的各种参数配置。

鉴于以上的考虑对Servlet版的测试规划为以下几种测试用例：

序号部署包g（*.JAR*.WAR*.EAR等）数据源配置WeblogicServer

的配置预期结果说明可能出现的问题和现象

1ServletQueryForPerConn.war在每此业务处理时创建数据库连接，操作完毕后关闭并

释放。

通过Web.xml配置文件来配置JDBC的驱动类型和连接。直接部署

ServletQueryForPerConn.jar部署包。

Web容器中只有一个Serverlet实例。

建议配置较多的线程数量。

性能差。

在每此业务处理时创建数据库连接，操作完毕后关闭并释放。

此包中没有设计到线程同步的有关代码。数据库很忙（因为数据库要接收频繁的数据

库连接）。

可能瓶颈在数据库对频繁的连接处理。

数据库事务方面：由于是在每次处理时就调用数据库连接并查询，因此数据库的事务处

理应该是单独在一个独立的处理过程中，与并行的其他线程的处理没有关系。

2ServletQueryForOnceConn.warServlet对象只是的初始化时连接与数据库的一个连接，

在以后的操作中式中使用这个连接。

通过Web.xml配置文件来配置JDBC的驱动类型和连接。直接部署

ServletQueryForOnceConn.jar包；

Web容器只有一个Servlet实例。

建议配置较多的线程数量。

性能较差。

Servlet对象只是的初始化时连接与数据库的一个连接，在以后的操作中式中使用这个

连接。

此包中没有设计到线程同步的有关代码。数据库连接只有一个。

可能瓶颈在Web容器的多个线程对同一个数据库连接对象的同步等处理（这些同步处

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

可能出现查询的数据在多个客户请求中打乱（因为同时使用同个数据库通信通道）；

并且多个线程（单独的处理单元）可能会在同•个处理事务中，可能各个处理单元会串

行操作数据库（这要看数据库的具体实现了）。

3ServletQueryForConnPool.war直接使用Web容器的数据源和数据库连接池。配置数

据源及数据库连接池。

建议根据实际情况优化配置数据源和连接池。如可建立多个连接池等配置。性能好。

Servlet实例不管数据库连接，而是直接从Web容器中取得数据库连接。数据库的连接对象

有Web容器全权管理。

此包中没有设计到线程同步的有关代码。对Web容器的数据库连接池的配置可能要根

据具体情况进行有效的调整（如数据库连接对象个数和Web容器配额的线程个数的关系

等）。如果配置不佳可能是性能瓶颈在Web容器或者在数据库方;

4ServletQueryForConnPool.war

（同测试3）同测试3Web容器的数据源重新配置为数据库产品专用的JDBC驱动器。

性能好。测试目的是比较各种不同的JDBC数据连接驱动器的性能，以便得出根据不同的数

据库产品选择最佳的JDBC驱动器。

只测试数据库产品提供的专用JDBC驱动器。

（说明：因为测试3在理论上性能是最好，因此选用测试3。测试方法和测试3一样，

这样才有可比性。）同测试3。

5servletQueryDS_Cache.war同测试3同测试3性能一般

使用一变量来缓存查询的数据，用户以后的分页查询查询操作是直接从此缓存中取得

的。

这种方式对Web容器的内存要求高，效果不是很好，对数据量查询小的效果可能会好

些。优点：

减少的了对数据库访问的次数。

缺点：

需要较大的内存。对Weblogic容器的内存要求高，对于有大量用户的查询操作，并且

查询的结果集较大时，可能对整个系统的性能是个很大的瓶颈。

对大量数据的分页处理

问题描述：

背景L一客户通过IE请求Web服务器查询数据，而查询结果是上千条甚至是上万条

记录，要求查询结果传送到IE客户端并分页显示。

背景2：一客户通过IE或者其他方式请求Web服务器查询数据，而查询结果是上千条

甚至是上万条记录，并要求查询结果把包传送到客户的E-mail中。

问：对于这样的有大量数据的结果集，在Web服务器端如何有效的处理？

可能涉及到的问题：

1.内存占用

大量数据的结果集，可能要

2.传输速度及策略

具体的分页处理技术

序号名称处理方法针对的数据库例子说明备注

1游标查询直接使用ResultSet来处理。ResultSet是直接在数据库上建立游标，然后通

过ResultSet的行位置定位接口来获得指定行位置的记录。

当用户第一请求数据查询时，就执行SQL语句查询，获得的ResultSet对象及其要使用

的连接对象都保存到其对应的会话对象中。

以后的分页查询都通过第一次执行SQL获得的ResultSet对象定位取得指定行位置的记

录。

最后在用户不再进行分页查询时或会话关闭时，释放数据库连接和ResultSet对象等数

据库访问资源。

说明：在用例分页查询的整个会话期间，•个用户的分页查询就要占用一个数据库连接

对象和结果集的游标，这种方式对数据库的访问资源占用比较大，并且其利用率不是很高。

所有的数据库产品。优点：

减少了数据库连接对象的多次分配获取，减少了对数据库的SQL查询执行。

缺点：

占用数据库访问资源一数据库连接对象，并占用了数据库上的资源一游标。而这些资源

都是十分宝贵的有限制的。

结论：

这种的数据库查询分页处理方式不是最佳的。一般不适用这种方式。

2定位行集SQL查询主要是直接使用数据库产品的提供的对查询的结果集可定位行范

围的SQL接口技术。

在用户的分页面查询请求中，每次可取得查询请求的行范围的参数，然后使用这些参数

生产取得指定行范围的的SQL查询语句，然后每次请求获得一个数据库连接对象并执行SQL

查询，把查询的结果返回给用户，最后释放说有的数据库访问资源。

说明：这种方式需要每次请求时都要执行数据库的SQL查询语句；对数据库的访问资

源是使用完就立即释放，不白白占用数据库访问资源。对特定（提供了对查询结果集可定

位功能的）的数据库产品。

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

1.Oracle数据库使用关键字：rowid或rownum

2.DB2:

rowid或rownum（）

3.PostgreSQL使用LIMIT和OFFSET

4.MySQL使用Limit优点：

这种技术是直接使用数据库产品自己提供的可对查询结果集定位行范围过滤的功能，因

此直接利用了数据库的性能对此分页查询的优化功能。

对数据库的访问资源（数据库