|
构建高性能J2EE应用的10个技巧 |
作者：佚名 发布时间：2005-04-02 来源：不详
|
构建高性能的J2EE应用
可帮助架构设计师们快速成
|
不但需要了解常用的实施技巧。
为这方面的专家。
|
下面介绍最常用的10种有效方法，
|
任何Java应用，单机的
Java的内存管理包括两个重
少需要创建的对象。 内存
垃圾回收越困难。所以我们
|
或J2EE的性能基础都可归结到你
要任务：内存的分配和内存的回
回收是导致性能下降的普遍原因
对创建对象的态度应该越保守越
|
的应用是如何管理内存的问题。
收。在内存的分配中，目标是要减
。也就是说，内存中的对象越多，
好。
|
在J2EE应用中常见的两
环（指大量频繁创建和删除
|
个内存有关的问题是：游离的对
-在Java中体现为解除引用---对
|
象（也被称为内存泄露）和对象循
象）。
|
我们应注意确保所有可到达的对象实
行的代码中是存在的。当对象在应用中已
，游离的对象就出现了。
|
际是活的，即这些对象不但在内存中，而且也要在执
经没有用了，而我们却忘记了删除对该对象的引用时
|
我们知道垃圾回收会占用CPU时间。
能下降。
|
短期对象的大量创建增加了垃圾回收的频率会造成性
|
在构建J2EE应用时，架
|
构工程师通常会使用到J2EE的基
|
本部分，Servlet。
|
如果架构师不使用Session Beans, E
方法就很少。只能采用增加CPU或更多的
池等方法可以提高性能和扩展性。
|
ntity Beans, 或 Message Beans, 那么改进性能的
物理服务器等方法。EJB使用了缓存（cache）和资源
|
在早期的J2EE （遵循E
着EJB2.0的出现，可以通过
经少多了。但是现在还是有
。为说明这点，我们作个比
|
JB1.X规范）应用中，访问EJB是
本地接口访问EJB，不再使用RMI
一些使用EJB1.X实现的应用和不
较：
|
`通过RMI使用远程接口实现的。随
，在同一个JVM中使用远程方法已
知道使用本地接口的一些EJB新手
|
| 如果你不需要从远程的客户端访问一个特殊EJB，就应该使用本地方法。 |
| 在实现Session Bean的服务中封装对实体EJB的访问 |
从Servlet访问实体EJB
可把对实体EJB的访问封装
免过多的远程调用。
|
不但效率低而且难于维护。使用
在会话EJB中，在该会话EJB中通
|
Session Facade（会话外观）模式
过使用本地接口访问实体EJB而避
|
这项技术会有额外的性
源池技术来进行改进。另外
上，这比将Servlet层复制
|
能和扩展方面的好处，这是因为
，由于负载的需要，会话和实体
扩展到其他硬件设备上要简单的
|
会话和实体EJB可以使用缓存和资
EJB可被扩展部署到其他硬件设备
多。
|
当访问远程EJB时，调用set/get方法
过载。为避免这种情况，可考虑将数据属
用就可以传递所有数据。这项技术就是数
|
将产生过多的网络请求，同时也导致远程接口处理的
性集中在一个对象中，这样通过一次对远程EJB的调
据传输对象（Data Transfer Object）模式。
|
J2EE的架构设计工程师和开发人员通
该确保SQL使用了数据库提供的索引支持
提高性能。但要知道，增加额外的索引可
些数据库，关联表之间的排序会严重影响
|
常不是SQL专家或经验丰富的数据库管理员。首先应
。在某些情况下，将数据库的索引和数据分开存放会
以提高SELECT性能但也会降低INSERT的性能。对于某
性能。可以多向数据库管理员咨询。
|
有时候，通过实体EJB
实体Bean的find(发现)方法
ejbLoad()从数据库中获得
|
访问数据会执行多个SQL语句。
；第二步，在第一次调用实体EJ
信息。
|
根据J2EE 规范，第一步，将调用
B的业务方法时，容器会调用
|
很多CMP(容器管理持久
时就不再访问数据库了。应
次访问数据库。
|
性)在调用发现方法时就缓存了
该避免使用BMP(Bean管理的持久
|
实体数据，所以在调用ejbLoad()
性)或者自己实现缓存算法避免二
|
| 使用Fast Lane Reader 模式访问只读数据 |
J2EE应用经常要以只读方式访问大量
在线产品目录。在这种只读情况下，使用
实体EJB 适合于对单个实体的粗粒度访问
CMP还是BMP，一定需要编写代码操作多个
大量的也是不必要的事务开销。
|
长时间不变的数据，而不是访问单个实体，例如浏览
实体EJB访问数据会导致严重过载并且实现很麻烦。
，访问大量的列表只读数据时效率不高。不管是使用
实体EJB及其关联。这将导致访问多个数据库并存在
|
| 利用Java Messaging Servce(消息服务) |
J2EE规范在JMS中提供
况下应该采用JMS进行异步
就应该越少越好，将数据库
|
了内置的异步处理服务。当涉及
处理的设计。一旦确定要执行一
密集的操作安排在稍后的异步处
|
到系统需求时，应该了解在什么情
些异步处理，那么同步处理的任务
理中完成。
|
很多操作在进行JNDI查
处理的过载。可以缓存的JN
|
找时要消耗大量资源。通常应该
DI查找包括：
|
缓存JNDI资源避免网络调用和某些
|
一些JNDI包实现了缓存功能。但是调
。
|
用对EJB主接口的narrow方法时，这种功能作用有限
|
缓存查找的设计应该使
访问多种数据源，包括应用
的各项参数。
|
用共享的IntialContext实例，
资源文件JNDI.properties,系统
|
尽管构建它很麻烦。这是因为需要
属性的各项参数,传入到构造函数
| | |
| |
|
|
|
