构建可扩展的Java EE应用（一） - 编程入门网

回到Java应用在給予更多的内存时是否可以扩展的问题上，答案是有些时候是 的。太小的内存会导致gc频繁的执行，足够的内存则保证JVM花费更多的时间来执 行业务逻辑，而不是进行gc。

但它并不一定是这样的，在我们实验室中出现的真实例子是一个构建在64位 JVM上的电信系统。使用64位JVM，应用可以突破32位JVM中4GB内存的限制，测试 时使用的是一台4 CPU/16G内存的服务器，其中12GB的内存分配给了java应用使用 ，为了提高性能，他们在初始化时就缓存了超过3,000,000个的对象到内存中，以 免在运行时创建如此多的对象。这个产品在第一个小时的测试中运行的非常快， 但突然，系统差不多停止运行了30多分钟，经过检测，发现是因为gc导致了系统 停止了半个小时。

gc是从那些不再被引用的对象回收内存的过程。不被引用的对象是指应用中不 再使用的对象，因为所有对于这些对象的引用都已经不在应用的范围中了。如果 一堆巨大的活动的对象存在在内存中（就像3,000,000个缓存的对象），gc需要花 费很长的时间来检查这些对象，这就是为什么系统停止了如此长乃至不可接受的 时间。

在我们实验室中测试过的以内存为中心的Java应用中，我们发现具备有如下特 征：

1、每个请求的处理过程需要大量和复杂的对象；

2、在每个会话的HttpSession对象中保存了太多的对象；

3、HttpSession的timeout时间设置的太长，并且HttpSession没有显示的 invalidated；

4、线程池、EJB池或其他对象池设置的太大；

5、对象的缓存设置的太大。

这样的应用是不好做扩展的，当并发的用户数增长时，这些应用所使用的内存 也会大幅度的增长。如果大量的活动对象无法被及时的回收，JVM将会在gc上消耗 很长的时间，另外，如果給予了太大的内存（在64位JVM上），在运行了相对较长 的时间后，jvm会花费相当长的一段时间在 gc上，因此结论是如果给jvm分配了太 多的内存的话，java应用将不可扩展。在大部分场合下，给jvm分配3G内存(通 过"-Xmx"属性)是足够 (在windows和linux中，32位的系统最多只能分配2G的内存 )的。如果你拥有更多的内存，请将这些内存分配给其他的应用，或者就将它留给 OS 使用，许多OS都会使用空闲的内存来作为数据的缓冲和缓存来提升IO性能。实 时JVM(JSR001)可以让开发人员来控制内存的回收，应用基于此特性可以告诉JVM ：“这个巨大的内存空间是我的缓存，我将自己来管理它，请不要自动对它进行 回收”，这个功能特性使得Java应用也能够扩展来支持大量的内存资源，希望JVM 的提供者们能将这个特性在不久的将来带入到免费的JVM版本中。

为了扩展这些以内存为中心的java应用，你需要多个jvm实例或者多台机器节 点。

其他垂直扩展的问题

有些Java EE应用的扩展性问题并不在于其本身，有些时候外部系统的限制会 成为系统扩展能力的瓶颈，这些瓶颈可能包括：

数据库系统：这在企业应用和web 2.0应用中是最常见的瓶颈，因为数据库通 常是jvm线程中共享的资源。因此数据库执行的效率、数据库事务隔离的级别将会 很明显的影响系统的扩展能力。我 们看到很多的项目将大部分的业务逻辑以存储 过程的方式放在数据库中，而web层则非常的轻量，只是用来执行下数据的过滤等 ，这样的架构在随着请求数的增长 后会出现很多的扩展性问题。

磁盘IO和网络IO。

操作系统：有些时候系统扩展能力的瓶颈可能会出现在操作系统的限制上，例 如，在同一个目录下放了太多的文件，导致文件系统在创建和查找文件时变得非 常的慢；

同步logging：这是一个可扩展性的常见问题。在有些案例中，可以通过采用 Apache log4j来解决，或者采用jms消息来将同步的logging转为异步执行。

这些不仅仅是Java E

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!