构建高性能J2EE应用的十个技巧

日期: 2011-05-11 来源:TechTarget中国 英文

  构建高性能的J2EE应用不但需要了解常用的实施技巧。下面介绍最常用的10种有效方法,可帮助架构设计师们快速成为这方面的专家。

  Java性能的基础—内存管理

  任何Java应用,单机的或J2EE的性能基础都可归结到你的应用是如何管理内存的问题。Java的内存管理包括两个重要任务:内存的分配和内存的 回收。在内存的分配中,目标是要减少需要创建的对象。

  内存回收是导致性能下降的普遍原因。也就是说,内存中的对象越多,垃圾回收越困难。所以我们对创建对象的态度应该越保守越好。

  在J2EE应用中常见的两个内存有关的问题是:游离的对象(也被称为内存泄露)和对象循环(指大量频繁创建和删除-在Java中体现为解除引用—对 象)。

  我们应注意确保所有可到达的对象实际是活的,即这些对象不但在内存中,而且也要在执行的代码中是存在的。当对象在应用中已经没有用了,而我们却忘记 了删除对该对象的引用时,游离的对象就出现了。

  我们知道垃圾回收会占用CPU时间。短期对象的大量创建增加了垃圾回收的频率会造成性能下降。

  不要在Servlet中实现业务逻辑

  在构建J2EE应用时,架构工程师通常会使用到J2EE的基本部分——Servlet。如果架构师不使用Session Beans, Entity Beans, 或 Message Beans, 那么改进性能的方法就很少。只能采用增加CPU或更多的物理服务器等方法。EJB使用了缓存(cache)和资源池等方法可以提高性能和扩展性。

  尽可能使用本地接口访问EJB

  在早期的J2EE(遵循EJB1.X规范)应用中,访问EJB是通过RMI使用远程接口实现的。随着EJB2.0的出现,可以通过本地接口访问EJB,不再使用RMI, 在同一个JVM中使用远程方法已经少多了。但是现在还是有一些使用EJB1.X实现的应用和不知道使用本地接口的一些EJB新手。为说明这点,我们作个比 较:

  1、客户端应用调用本地Stub

  2、该Stub装配参数

  3、该Stub传到skeleton

  4、该skeleton分解参数

  5、该skeleton调用EJB对象

  6、EJB对象执行容器服务

  7、EJB对象调用企业BEAN实例

  8、企业BEA执行操作

  9、执行组装/分解步骤然后返回

  与远程接口处理相比较,本地接口的EJB方法是:

  1、客户端调用本地对象

  2、本地对象执行容器服务

  3、本地对象调用企业Bean实例

  4、企业Bean实例执行操作

  5、没有其他返回步骤!

  如果你不需要从远程的客户端访问一个特殊EJB,就应该使用本地方法。

  在实现Session Bean的服务中封装对实体EJB的访问

  从Servlet访问实体EJB不但效率低而且难于维护。使用Session Facade(会话外观)模式可把对实体EJB的访问封装在会话EJB中,在该会话EJB中通过使用本地接口访问实体EJB而避免过多的远程调用。

  这项技术会有额外的性能和扩展方面的好处,这是因为会话和实体EJB可以使用缓存和资源池技术来进行改进。另外,由于负载的需要,会话和实体EJB 可被扩展部署到其他硬件设备上,这比将Servlet层复制扩展到其他硬件设备上要简单的多。

  尽量粗粒度访问远程EJB

  当访问远程EJB时,调用set/get方法将产生过多的网络请求,同时也导致远程接口处理的过载。为避免这种情况,可考虑将数据属性集中在一个对 象中,这样通过一次对远程EJB的调用就可以传递所有数据。这项技术就是数据传输对象(Data Transfer Object)模式。

  优化SQL

  J2EE的架构设计工程师和开发人员通常不是SQL专家或经验丰富的数据库管理员。首先应该确保SQL使用了数据库提供的索引支持。在某些情况下,将数据库的索引 和数据分开存放会提高性能。但要知道,增加额外的索引可以提高SELECT性能但也会降低INSERT的性能。对于某些数据库,关联表之间的排序会严重影 响性能。可以多向数据库管理员咨询。

  避免在实体EJB中过多执行SQL

  有时候,通过实体EJB访问数据会执行多个SQL语句。根据J2EE 规范,第一步,将调用实体Bean的find(发现)方法;第二步,在第一次调用实体EJB的业务方法时,容器会调用ejbLoad()从数据库中获得信 息。

  很多CMP(容器管理持久性)在调用发现方法时就缓存了实体数据,所以在调用ejbLoad()时就不再访问数据库了。应该避免使用 BMP(Bean管理的持久性)或者自己实现缓存算法避免二次访问数据库。

  使用Fast Lane Reader模式访问只读数据

  J2EE应用经常要以只读方式访问大量长时间不变的数据,而不是访问单个实体,例如浏览在线产品目录。在这种只读情况下,使用实体EJB访问数据会导致严重过载并 且实现很麻烦。实体EJB 适合于对单个实体的粗粒度访问,访问大量的列表只读数据时效率不高。不管是使用CMP还是BMP,一定需要编写代码操作多个实体EJB及其关联。这将导致 访问多个数据库并存在大量的也是不必要的事务开销。

  利用Java Messaging Servce(消息服务)

  J2EE规范在JMS中提供了内置的异步处理服务。当涉及到系统需求时,应该了解在什么情况下应该采用JMS进行异步处理的设计。一旦确定要执行一 些异步处理,那么同步处理的任务就应该越少越好,将数据库密集的操作安排在稍后的异步处理中完成。

  缓存JNDI Lookup查找

  很多操作在进行JNDI查找时要消耗大量资源。通常应该缓存JNDI资源避免网络调用和某些处理的过载。可以缓存的JNDI查找包括:

  • EJB Home Interfaces
  • Data Sources
  • JMS Connection Factories
  • MS Destinations/Topics

  一些JNDI包实现了缓存功能。但是调用对EJB主接口的narrow方法时,这种功能作用有限。缓存查找的设计应该使用共享的 IntialContext 实例,尽管构建它很麻烦。这是因为需要访问多种数据源,包括应用资源文件JNDI.properties,系统属性的各项参数,传入到构造函数的各项参 数。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐