项目中这样统计方法耗时不香吗？

在项目开发维护时，经常会对处理耗时较长的代码进行重构，那么该如何知道方法处理用了多长时间呢？到底该怎么实现呢？

心中有没有答案？不卖关子啦，通过本次分享，能让你轻松 get 如下几点。

a）简单的统计方法耗时； b）优雅的统计方法耗时； c）一分钟学会使用 SLF4J 的 Profiler 进行性能分析； d）SLF4J 的 Profiler 性能分析器刨根问底；

1. 简单的实现方法耗时

假如要对图中的两个方法用时进行统计，最简单的方式莫过于定义方法执行前记录一下时间，方法执行后记录一下时间，然后取时间差就可以啦。

long begin = ....

//执行方法 ... ...
long end = ....//统计方法耗时，end - begin

代码实现如下。

绝对能满足需求，只是代码上略显冗余，重复的代码写了 2 遍，要是方法有 N 个呢？冗余的代码将不敢想象，用行话就是一坨又一坨，该咋办？

估计多数朋友就想到了重构，把重复的代码抽取出来封装成工具类不就妥啦，于是就诞生了稍微优雅点的实现方式。

2. 优雅的实现方法耗时

换汤不换药，稍微解释一下上面的代码。

标注 1 代码：定义开始时间；
标注 2 代码：定义 一个 getCost 方法，进行统计方法耗时，逻辑很简单，方法耗时是结束时间与开始时间取差值，其中 msg 就是想输出的日志信息；
标注 3 代码：考虑到多处复用，那么开始时间就要进行重置，refresh 方法主要提供重置开始时间的功能。

统计方法耗时的工具写好了，用起来就相当简单。

程序输出如下，有没有很简单。

pay ...

【共耗时-11-毫秒】

payquery ...

【共耗时-23-毫秒】query

此时，估计很多朋友能想到灵活运用代理模式或者 AOP 的思想赋予其中，有想法是鼎好的，但不是本次讨论的重点，接下来要重点介绍一下如何借助 SLF4J 提供的 Profiler API 来统计方法耗时。

3. 一分钟学会使用 SLF4J 的 Profiler 进行性能分析。

SLF4J 提供的扩展包 slf4j-ext.jar 提供了性能分析的支持，包中的 Profiler 类，对于开发者快速定位耗时较长的代码，提供强有力的帮助。

Talk is cheap. Show me the code.

程序跑起来，效果还可以（前提要引入 slf4j-ext 的 jar 包，千万别忘记！）。

鉴于生产环境上 Console 的日志是不推荐开启的，所以 Profiler 分析器也可以与 Logger 日志记录器绑定到一起，把信息记录到日志文件中。

Talk is cheap. Show me the code.

日志文件输出如下，效果还可以。

用法很简单，和自己实现的用法也相差不大（低调的笑）。

会用而后模仿，是程序猿的进阶之路，所以还是要好奇的要看看 Profiler 的源码。

4. SLF4J 的 Profiler 分析器刨根问底

按照 Profiler 的使用步骤，首先创建 Profiler 类的实例时，内部会启动一个全局秒表。

当调用 start 方法启动一个新的秒表时（子秒表），会停止上一个启动的秒表（子秒表）。

当调用 stop 方法时，首先停止启动的子秒表，然后停止全局秒表。

接着就是调用 print 方法进行打印啦，实现也很简单，计算耗时而已。

当结合日志记录器使用时，调用 log 方法进行记录信息，与 print 方法差别不大，多了一些日志级别的校验，只有当 DEBUG 级别的时候才输出性能分析信息。

源码就分析到这儿，好的程序猿抄，伟大的程序猿偷，所以要敲摸的告诉你，在不引入 slf4j-ext 扩展包的情况下，StopWatch 可以改吧改吧放到项目中直接使用，其实和咱们开篇写的简单工具类差不太多。