陷阱与非常好的实践

　　很多监控应用的方法，不论是针对性能、稳定性还是语义正确性，都无法最有效的体现它们的意图。要么生成了太多的信息以至于难以分析这些数据，要么在需要信息的地方却得不到关键的数据。虽然所有的监控都需要一些额外的开销，但是性能监控应该对这些引入的开销格外小心。以下建议可以帮助你最大限度地利用 Perf4J，同时又将副作用降到最低：

　　1.在判断需要分析哪些方法和代码块时，首先把重点放在关键点上。在企业应用中，每当遇到性能瓶颈时，都会存在很多“通常的疑点”：数 据库调用、运程方法调用、磁盘I/O、针对大型数据集的计算操作。因此，你应该首先集中分析这些类型的操作。同时，因为这些操作花费几十甚至几百毫秒的时 间，Perf4J所带来的额外开销相对于本地执行时间来说微不足道，在实践中可以忽略不计。事实上，这也是Perf4J故意使用System.currentTimeMillis(而不是System.nanoTime)计时代码块的原因之一：纳秒的粒度在这种企业应用代码块中意 义并不大。

　　2.Perf4J把性能分析的工作委托给独立的线程或者进程。当使用AsyncCoalescingStatisticsAppender时，执行线程把日志事件推入到一个内存中的队列，由另外一个独立的线程发送这些日志 消息到下游appender。因此，即使那些下游appender做了大量敏感的工作，如建立图表、更新MBean属性或者存储到数据库中，对计时的代码 块的影响微乎其微，而且与这些下游appender做的工作多少无关。类似的，当把计时日志写入文件用于解析和分析时(例如，使用Unix tail命令)，对于计时进程的影响也只与它写日志所花费的时间有关，与log分析器的时间无关。

　　3.不要忘记性能回归测试的好处。除了监测运行时的性能瓶颈，Perf4J非常适合创建性能回归测试以判断代码更改是否对性能有显著影响(不论是积极或消极的)。通过创建一个原始代码的基准，你很快就能发现新代码对性能产生了何种影响。

　　4.利用@Profiled注解和AspectJ的加载时编织来决定哪些方法应该在部署时计时。如果使用了 @Profiled 注解，你可以自由的在方法调用周围添加计时，然后决定在使用AspectJ的aop.xml配置文件进行部署时需要对哪些方法进行计时。没有计时的方法不 会被关注。虽然那些被计时的方法比直接在代码中使用StopWatches存在一些细微的额外开销(事实上AspectJ在计时方法的周围建立了一个闭 包)，这些开销相对于那些需要花费几毫秒的方法来说是微不足道的。

　　5.不要忘记应用程序中JVM之外执行的部分。举例来说，很多Web 2.0应用的大部分都是通过运行在客户端浏览器中的JavaScript实现，虽然Perf4J可以用于衡量运行在服务器端的方法(响应AJAX远程调用)，但如果JavaScript执行性能下降，你仍然需要其他的客户端调试工具。

　　展望Perf4J

　　Perf4J目前正在积极的发展，新的功能层出不穷。举例来说，凭借新版本的Perf4J，我们可以通过单独的配置文件指定要分析的方法，这样即使 无法获得某些方法的源代码也可以对其进行计时。我们始终将用户的反馈和需求放在第一位，如果你想打造它未来的功能，那现在就来尝试Perf4J吧。更重要 的是，Perf4J在Apache 2协议下完全开源，代码都充分文档化，你可以随意扩展。

　　现在就下载Perf4J吧，告诉我们你的想法!