将数据访问与业务逻辑分离，提高业务 增加应用的复杂性。但是ＭＶＣ可以轻 中，在很大程度上减少了系统的耦合， 精度，降低代码之间的耦合，模型层又 松地实现程序代码与ＨＴＭＬ的分离，细分为ＤＡＯ层与业务层，ＤＡＯ全称为 而且ＭＶＣ的三个模块相互独立，可以 Ｄａｔａ Ａｃｃｅｓｓ Ｏｂ ｅｃｔ（数据访问对象）， 提高了可复用性。 ‘（３１数据层。为了实现数据库访问细 为了使系统具有较好的可维护性、 思想，以搭建一个逻辑清楚、功能明 ２．工作流程 构造良好的松耦合构件，提高应用系 节与业务层的分离，引入持久化层。将数据库访问代码封闭起来，Ｈｉｂｅｒｎａｔｅ 统的可维护性、可扩展性、可移植性 向其他层暴露；业务层是整个系统最 使用ＭＶ Ｃ设计框架。 核心也最具价值的一层，该层封装应 用程序的业务逻辑，处理数据，关注 了一定的改进。 ＡＰＩ也在此封装，不再出现在其他层或 和可复用性。从长远的应用考虑，应 可移植性和可复用性，采用以上的设计 本系统在传统的Ｂ／ｓ三层结构上作 确、模块化程度高的元数据管理系统。 客户需求，在业务处理过程中会访问 原始数据或产生新数据，或者需要持 久化数据，ＤＡＯ层提供的ＤＡＯ类能很 好地帮助业务层完成数据处理，业务 层本身则侧重于对客户需求的理解和 业务规则的适应，自然也包括大部分 的计算，总体说来，ＤＡＯ不处理业务 逻辑，只为业务层提供辅助，获取原 始数据或持久化数据等操作。Ｖｉｅｗ￣Ｏ 视图层，为最终用户提供一个友好的 交互界面，用户可以查看请求结果， 也可以通过表单等交互手段实现数据 录入。Ｃｏｎｔｒｏｌｌｅｒ层即控制器，控制 器是Ｍｏｄｅｌ与Ｖｉｅｗ的桥梁，将二者很 好的衔接，通过Ｖｉｅｗ接收用户数据， Ｃｏｎｔｒｏｌｌｅｒ将数据传输给Ｍｏｄｅｌ，Ｍｏｄｅｌ 对数据进行处理；或者Ｍｏｄｅｌ读取数 据后，Ｃｏｎｔｒｏｌｌｅｒ将数据传递给Ｖｉｅｗ， Ｖｉｅｗ向用户展示数据。一来一往， Ｃｏｎｔｒｏｌｌｅｒ成了Ｍｏｄｅｌ与Ｖｉｅｗ之间的快 乐使者。 三、ＪａｖａＥＥ数据管理系统的设计 与实现 （一）元数据管理系统的设计 使用本系统的各部门实际情况不 同，系统可能被部署到不同的平台上， 而且需要对该系统进行一定的扩展和改 进。所以在系统设计上，需要充分考虑 到系统的可移植性和可扩展性。 １．系统设计 本系统基于Ｊ２ＥＥ平台，是一个 浏览器／服务器（Ｂ／Ｓ）结构的系统， 具有Ｊ２ ＥＥ平台可以跨系统使用的 特性，采用ＭＶＣ（Ｍｏｄｅｌ—Ｖｉｅｗ— Ｃｏｎｔｒｏｌｌｅｒ）应用框架。ＭＶＣ设计框架 的内部原理比较复杂，将ＭＶＣ运用到 应用程序中会带来大量的额外工作， 一１ ２一 问文’ 辱・９／２０１２ （１）表现层。在该层使用Ｓｔｒｕｔｓ框 架。Ｓｔｒｕｔｓ是一个ＭＶＣ模式的表现层应 用框架。浏览器向Ｗｅｂ服务器提出请 求后，ｗｅｂ服务器会把请求交给控制 器处理。ＡｃｔｉｏｎＳｅｒｖｌｅｔ控制器根据请求 的不同，将它们转发给不同的Ａｃｔｉｏｎ实 例。Ａｃｔｉｏｎ实例在这里充当了用户请 求与业务处理逻辑之间的适配器，它 只负责控制整个程序的流程，不关心 具体业务的实现，实现了请求与业务 逻辑的分开。本系统使用一个高效的 Ａｃｔｉｏｎ类——ＤｉｓＤａｔｃｈＡｃｔｉｏｎ类。只要 继承该类，就可以在一个Ａｃｔｉｏｎ中集 成多个业务方法，有利于系统的维护。 在视图显示方面，其大量使用了Ｓｔｒｕｔｓ标 签，用来控制显示的逻辑和内容。由于 不同平台采取的编码方式不同，在进行 系统移植时很容易出现中文乱码问题。 在这里使用一个可插拔式的过滤器，实 现对请求和响应的预处理及后处理，很 好地解决了字符编码问题，使系统可以 在不同的平台上进行移植。 （２）业务层。它处理用户请求和 应用逻辑。在处理之前，将所有涉及 到表现层的数据结构替换成更加通 用的数据结构类型；使用通用的、 与表现层无关的数据结构在这两层 之间传递参数。表现层方法提交的 参数类型主要是ＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔ和 ＨｔｔｐＳｅｒｖｌｅｔＲｅｓｐｏｎｓｅ；使用这样的参数 会增加系统的耦合性，不利于代码的重 用，所以要将它们处理成通用的数据类 型，如数组。这一过程在Ａｃｔｉｏｎ适配器 进行转发之前完成，提供给业务层的参 数是通用的数据类型。业务层方法之间 的通信也通过通用的参数类型进行，使 得每个业务方法均独立存在于系统之 用户通过浏览器（ＩＥ／Ｎｅｔｓｃａｐｅ）向 服务器提交请求，请求经过过滤器处理 后再提交给控制器ＡｃｔｉｏｎＳｅｒｖｌｅｔ；控制 器根据请求的类别将它们转发给不同的 ＤｉｓｐａｔｃｈＡｃｔｉｏｎ类。该类中的方法对参数 进行处理后调用不同的业务逻辑对请求 进行分析处理，处理后得到的信息通过 视图显示在用户浏览器上。 （二）基于Ｊ２ＥＥ的元数据管理系统的 实现 一个元数据管理系统——基于Ｊ２ＥＥ 的小城镇元数据管理平台。本实例以 Ｊ２ＥＥ平台为基础，Ｔｏｍｃａｔ ５．０为服务 器，可以使用Ｏｒａｃｌｅ ９ｉ、ＳＱＬ Ｓｅｒｖｅｒ ２０００、ＭｙＳＱＬ数据库，使用了ＯＲＭ （Ｏｂｊｅｃｔ－－Ｒｅｌａｔｉｏｎ Ｍａｐｐｉｎｇ）模式的持 久化层中间件Ｈｉｂｅｒｎａｔｅ，以Ｅｃｌｉｐｓｅ ３．０ 为开发平台。在系统实现过程中，使用 了以Ｊ２ＥＥ平台为基础的各项技术，遵循 Ｊａｖａ２标准平台的编码标准，注重系统的 可扩展性和可维护性。系统的ＸＭＬ引擎 采用了Ｄ０Ｍ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅ１） 和ＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ）。ＤＣ｝Ｍ 负责ＸＭＬ文档的生成和修改；ＳＡＸ对 ＸＭＬ进行解析。 四、ＪａｖａＥＥ应用程序在Ｇｌａｓｓｆｉｓｈ上 的性能调优案例分析 Ｊａｖａ ＥＥ应用的性能问题对严肃的项 目和产品来说是一个非常重要的问题。 特别是企业级的应用，并发用户多，数 据传输量大，业务逻辑复杂，占用系统 资源多，因此性能问题在企业级应用变 得至关重要，它和系统的稳定性有着直 接的联系。更加重要的是，性能好的应 用在完成相同任务的条件下，能够占用 更少的资源，获得更好的用户体验，换 句话说，就是能够节省费用和消耗，获 怠技术煎凫《《《 得更高的利润。ＪａｖａＥＥ应用性能调优不 具发现进程并没有被杀死或挂起，而 时候，请求响应时间比较慢，通过操 仅仅和Ｇｌａｓｓｆｉｓｈ有关，Ｊａｖａ语言有关， ＣＰＵ使用率几乎为零。那么是什么原 作系统的工具（ｍｐｓｔａｔ）发现ＣＰＵ使用 还要和操作系统以及硬件都有关系，需 因导致系统停止响应用户请求呢？我 率比较高。并且系统占用绝大多数的 要调优者有综合的知识和技能。这些不 们利用Ｊａｖａ虚拟机的工具（ｋｉｌ１．３ ｐｉｄ） 同层面的方法需要综合纵效，结合在一 将当前的所有线程状态ＤＵＭＰ出来， 瓶颈。下面是一些具体的案例分析： ＣＰＵ资源而不是应用本身。这是个不正 常的现象，通常情况下用户应用的ＣＰＵ 起灵活使用，才能快速有效的定位性能 发现ＪａｖａＥＥＹＪ￣务器的大部分处理线程 占用率应该占主要地位，才能说明系统 都在等待数据库连接池的连接，而那 是正常工作。通过Ｓｏｌａｒｉｓ １０的Ｄｔｒａｃｅ脚 些已经获得数据库连接的线程却处于 本，我们查看当前情况下哪些系统调用 （一）内存泄漏问题 某个ＪａｖａＥＥ应用运行在８颗ＣＰＵ的 阻塞状态。数据库管理员应要求检查 花费了最多的ＣＰＵ资源，竟然发现最花 服务器上。上线运行发现性能不稳定。 性能随着时间的增加而越来越慢。通过 操作系统的工具（ｍｐｓｔａｔ），发现在系 统很慢的时候，只有一颗ＣＰＵ很忙，其 他的ＣＰＵ都很空闲。因此怀疑是Ｊａｖａ虚 拟机经常进行内存回收，因为虚拟机在 内存回收的时候，有的回收算法通常只 能运行在一个ＣＰＵ上。通过Ｊａｖａ虚拟机 的工具‘＇ｊｓｔａｔ”可以清楚的看到，Ｊａｖａ虚 拟机进行内存回收的频率非常高，几乎 每５秒中就有一次，每次回收的时间为２ 秒钟。另外，通过‘＇ｊｓｔａｔ”的输出还发现 每次回收释放的内存非常有限，大多数 对象都无法回收。这种现象很大程度上 暗示着内存泄漏。使用Ｊａｖａ虚拟机的工 具‘＇ｊｍａｐ”来获得当前的一个内存映象。 发现有很多（超过１００００）个的ｓｅｓｓｉｏｎ 对象。这是不正常的一个现象。一般来 说，ｓｅｓｓｉｏｎ对应于一个用户的多次访 问，当用户退出的时候，ｓｅｓｓｉｏｎ就应该 失效，对象应该被回收。当我们和这个 系统的开发工程师了解有关ｓｅｓｓｉｏｎ的 设置，发现当他们部署应用的时候，竟 然将ｓｅｓｓｉｏｎ的ｔｉｍｅｏｕｔ时间设置为５０分 钟，并且没有提供ｌｏｇｏｕｔ的接口。这样 的设置下，每个ｓｅｓｓｉｏｎ的数据都会保 存５０分钟才会被回收。根据我们的建 议，系统提供了ｌｏｇｏｕｔ的链接，并且告 诉用户如果退出应用，应该点击这个 ｌｏｇｏｕｔ的链接；并且将ｓｅｓｓｉｏｎ的ｔｉｍｅｏｕｔ 时间修改为５分钟。通过几天的测试， 证明泄漏的问题得到解决。 （－－）数据库连接池问题 某财务应用运行在ＪａｖａＥＥ｝］￣务器 上，后台连接Ｏｒａｃｌｅ数据库。并发用户 数量超过１００人左右的时候系统停止响 应。通过操作系统层面的进程监控工 了数据库的状态，发现所有的连接的 ｓｅｓｓｉｏｎ都处于死锁状态。显然，这是 因为数据库端出现了死锁的操作，阻 塞了那些有数据库操作的请求，占用 了所有数据库连接池中的连接。后续 的请求如果还要从连接池中获取连 接，就会阻塞在连接池上。当解决数 据库死锁的问题之后，性能问题迎刃 而解。 （三）大对象缓存问题 电信应用运行在６４位Ｊａｖａ虚拟机 上，系统运行得很不稳定，系统经常 停止响应。使用进程工具查看，发现 进程并没有被杀死或挂起。利用Ｊａｖａ 虚拟机的工具发现系统在长时间的进 行内存回收，内存回收的时间长达１５ 分钟，整个系统在内存回收的时候就 像挂起一样。另外还观察到系统使用 了１２Ｇ的内存（因为是６４位虚拟机所 以突破了４（３内存的限制）。从开发人 员那里了解到，这个应用为了提高性 能，大量使用了对象缓存，但是事与 愿违，在Ｊａｖａ中使用过多的内存，虽 然在正常运行的时候能够获得很好的 性能，但是会大大增加内存回收的时 间。特别是对象缓存，本系统使用了 ８Ｇ的缓存空间，共缓存了６０００多万个 对象，对这些对象的遍历导致了长时 间的内存回收。根据我们的建议，将 缓存空间减少到１Ｇ，并调整回收算法 （使用增量回收的算法），使得系统 由于内存回收而造成的最大停顿时间 减少到４秒，基本满足用户的需求。 （四）外部命令问题 数字校园应用运行在４ ＣＰＵ的 Ｓｏｌａｒｉｓ１Ｏ服务器上，中间件为ＪａｖａＥＥ 服务器。系统在做大并发压力测试的 费ＣＰＵ的系统调用是“ｆｂｒｋ”。众所周知， “ｆｂｒｋ”系统调用是用来产生新的进程，在 Ｊａｖａ￣拟机中只有线程的概念，绝不会有 进程的产生。这是个非常异常的现象。 通过本系统的开发人员，我们找到了答 案：每个用户请求的处理都包含执行一 个外部ｓｈｅｌｌ脚本，来获得系统的一些信 息。这是通过Ｊａｖａ的“Ｒｕｎｔｉｍｅ．ｇｅｔＲｕｎｔｉｍｅ ｒ）．ｅｘｅｃ”来完成的，但是这种方法在Ｊａｖａ 中非常消耗资源。Ｊａｖａ虚拟机执行这个命 令的方式是：首先克隆一个和当前虚拟 机一样的进程，再用这个新的进程去执 行外部命令，最后再退出这个进程。如 果频繁执行这个操作，系统的消耗会很 大，不仅在ＣＰＵ，内存操作也很重。用 户根据建议去掉这个ｓｈｅｌｌ脚本执行的语 句，系统立刻回复了正常。 基于Ｊ２ＥＥ的元数据管理平台，具 有良好的跨平台特性；解决了多源异 构数据的融合、遥感数据的存储、数 据持久化和用户控制访问问题；在设 计和实现过程中遵循Ｊ２ＥＥ的设计模 式，具有良好的扩展性和维护性；功 能模块具有低耦合的特点，极大地提 高了代码的可复用性；可对元数据进 行有效管理，实现信息的共享发布， 广泛地应用在各个领域。在如何提高 系统的安全性方面还有待于对其进行 进一步的研究。 参考文献： ［１］杨浮群，邹利艳，徐丽．ＪａｖａＥＥ开发环境下Ｓｑｌ Ｓｅｒｖｅ￣据库优化Ⅱ】ｌ电脑知识－９技术，２０１１，３１． 【２】ＪａｖａＥＥ）￣用系统设计与开发课程培训．２０１１，１１． ［３］刘世贵，郭文龙，姜惠娟．基于Ｊａｖａ ＥＥ架构的 多层软件的测试研究－９实现Ｕ】．电脑知识－９技 术，２０１０，１７． 闷轰 辱・９／２０１２ —１３—