在项目开发维护时，经常会对处理耗时较长的代码进行重构，那么该如何知道方法处理用了多长时间呢？到底该怎么实现呢？
心中有没有答案？不卖关子啦，通过本次分享，能让你轻松 get 如下几点。
a）简单的统计方法耗时； b）优雅的统计方法耗时； c）一分钟学会使用 SLF4J 的 Profiler 进行性能分析； d）SLF4J 的 Profiler 性能分析器刨根问底；
1. 简单的实现方法耗时
假如要对图中的两个方法用时进行统计，最简单的方式莫过于定义方法执行前记录一下时间，方法执行后记录一下时间，然后取时间差就可以啦。
代码语言：javascript复制long begin = ....//执行方法 ... ...
long end = ....//统计方法耗时，end - begin代码实现如下。
绝对能满足需求，只是代码上略显冗余，重复的代码写了 2 遍，要是方法有 N 个呢？冗余的代码将不敢想象，用行话就是一坨又一坨，该咋办？
估计多数朋友就想到了重构，把重复的代码抽取出来封装成工具类不就妥啦，于是就诞生了稍微优雅点的实现方式。
2. 优雅的实现方法耗时
换汤不换药，稍微解释一下上面的代码。
代码语言：javascript复制标注 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 可以改吧改吧放到项目中直接使用，其实和咱们开篇写的简单工具类差不太多。
