AOP@Work: 用AspectJ进行性能监视，第1部分

AOP@Work: 用AspectJ进行性能监视，第1部分2011-09-07 IBM Ron Bodkin用AspectJ和JMX深入观察Glassbox Inspector

简介：随着 Ron Bodkin 介绍如何把 AspectJ 和 JMX 组合成灵活而且模块化的性能监视方式，就可以对散乱而纠缠不清的代码说再见了。在这篇文章（共分两部分）的第一部分中，Ron 用来自开放源码项目 Glassbox Inspector 的代码和想法帮助您构建一个监视系统，它提供的相关信息可以识别出特定问题，但是在生产环境中使用的开销却足够低。

现代的 Java™ 应用程序通常是采用许多第三方组件的复杂的、多线程的、分布式的系统。在这样的系统上，很难检测（或者分离出）性能问题或可靠性问题的根本原因，尤其是生产中的问题。对于问题容易重现的情况来说， profiler 这类传统工具可能有用，但是这类工具带来的开销造成在生产环境、甚至负载测试环境中使用它们是不现实的。

监视和检查应用程序和故障常见的一个备选策略是，为性能的关键代码提供有关调用，记录使用情况、计时以及错误情况。但是，这种方式要求在许多地方分散重复的代码，而且要测量哪些代码也需要经过许多试验和错误才能确定。当系统变化时，这种方式既难维护，也很难深入进去。这造成日后要求对性能需求有更好理解的时候，添加或修改应用程序的代码变得很困难。简单地说，系统监视是经典的横切关注点，因此任何非模块化的实现都会让它混乱。

学习这篇分两部分的文章就会知道，面向方面编程（AOP）很自然地适合解决系统监视问题。AOP 允许定义切入点，与要监视性能的许多连接点进行匹配。然后可以编写建议，更新性能统计，而在进入或退出任何一个连接点时，都会自动调用建议。

在本文的这半部分，我将介绍如何用 AspectJ 和 JMX 创建灵活的、面向方面的监视基础设施。我要使用的监视基础设施是开放源码的 Glassbox Inspector 监视框架（请参阅参考资料）的核心。它提供了相关的信息，可以帮助识别特定的问题，但是在生产环境中使用的开销却足够小。它允许捕捉请求的总数、总时间以及最差情况性能之类的统计值，还允许深入请求中数据库调用的信息。而它做的所有这些，仅仅是在一个中等规模的代码基础内完成的！

在这篇文章和下一篇文章中，我将从构建一个简单的 Glassbox Inspector 实现开始，并逐渐添加功能。图 1 提供了这个递增开发过程的最终系统的概貌。请注意这个系统的设计是为了同时监视多个 Web 应用程序，并提供合并的统计结果。

图 1. 带有 JConsole JMX 客户端的 Glassbox Inspector