注意性能干扰–让非热点区不受影响!
你使用的每一种测量方法似乎都会引起系统性能干扰。一些数据的测量可以被认为“无干扰”(或“忽略不计”)，然而另外一些数据的测量可称得上代价昂贵。非常重要的一点是，要知道你需要BTrace测量什么。因此，你要将这种分析工具对程序的性能干扰减少到最小。关于这点，请参考下面的3条原则：
基于“采样”的度量通常可被认为“无影响”。采样CPU负载、进程CPU负载、内存使用和每5-10秒的线程计数，其带来的额外一两个毫秒的影响可被忽略。在我看来，你应该经常收集这类统计数据，它们对你来说不会有什么损耗。
对长时间运行的任务的测量也可被认为“无影响”。通常，它仅会对每个被测量方法带来1700-2500纳秒的影响。如果你正测量这些对象的执行时间：SQL查询、网络流量、硬盘读写或一个预期范围在40毫秒(磁盘存取)到1秒(Servlet处理)之间的Servlet处理过程，那么对这些对象每个增加额外的2500纳秒左右的时间也是可接受的。
绝对不要对循环内执行的方法进行测量
寻找程序热点区的一个通用规则是不要影响非热点区域。例如，考虑下面的类：
▲图16：需要测量的简单的数据访问接口类
第5行的SQL执行时间可能使readStatFromDatabase方法可能成为一个热点。当查询返回相当多的数据行时，它无疑会成为一个热点，这对13行(程序和数据库服务器之间的网络流量)和14-16行(结果集中每行所需处理)会造成负面影响。如果从数据库返回结果时间过长，该方法也会成为一个热点(在13行)。
方法buildNewStat就其本身来说似乎绝不会成为一个热点。即使被多次执行，每次调用都会在几纳秒内完成。另一方面，若给每次调用增加了2500纳秒的测量采集干扰，则无论SQL何时被执行，都势必会让该方法看起来像个热点。因此，我们要避免测量它。
▲图17：显示上面类哪些部分可以被测量，哪些需要避免
建立完整的运行分析
使用EurekaJ建立一个完整的运行分析，需要以下几个主要部分：
准备需要监测/操纵的程序
BTrace - java代理
告知BTrace如何测量的BTrace脚本
存储BTrace输出的文件系统
将BTrace输出传输到EurekaJ管理器的EurekaJ代理
安装好的EurekaJ管理器(本地安装或可通过互联网访问的远程安装)
▲图18：使用本文所描述工具对程序进行运行分析的概览图
关于这些产品的完整安装手册，请访问EurekaJ项目网站。
总结
这篇文章给我们介绍了一些用于程序运行分析的开源工具，它们不仅能帮我们完成对运行中JVM的深度分析，而且可以帮助我们对开发、测试和程序部署进行多方位的持续监测。
希望你已经开始了解不断收集度量信息的好处和超过阈值后及时报警能力的重要性。
