“我这个接口为什么这么慢？”

这是后端开发者每天都要面对的灵魂拷问。要回答这个问题，第一步就是要量化——精确地知道是哪个方法、哪段逻辑消耗了多少时间。

最直接的想法，可能就是在方法开头和结尾打印时间戳。但这种“简单粗暴”的方式，真的好吗？

本文将为你系统地梳理从“青铜”到“王者”的 5 种 Java 方法耗时统计方式，剖析它们的优缺点，并给出在不同场景下的最佳实践推荐。

1. “青铜”级：手动埋点 (System.currentTimeMillis())

这是最原始，也是每个开发者都用过的方法。

实现方式：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Service
public class MyService {
    private static final Logger log = LoggerFactory.getLogger(MyService.class);

    public void doSomething() {
        long startTime = System.currentTimeMillis();
        try {
            // --- 核心业务逻辑 ---
            Thread.sleep(100); 
            // --- 核心业务逻辑 ---
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            long costTime = System.currentTimeMillis() - startTime;
            log.info("方法 doSomething() 执行耗时: {} ms", costTime);
        }
    }
}

• • 优点：

  • • 简单直接，无需任何额外依赖。

  • • 足够灵活，可以测量任意代码片段。

• • 缺点：

  • • 代码侵入性极强： 耗时统计的逻辑与业务逻辑严重耦合，污染了代码。

  • • 重复劳动： 每个需要监控的方法，都得重复编写这段样板代码。

  • • 容易出错： 忘记 try-finally 块，可能导致在发生异常时无法统计耗时。

• • 推荐使用场景：

  • • 临时的、一次性的本地调试。

  • • 绝对不推荐在生产代码中大规模使用。

2. “白银”级：StopWatch 工具类

为了解决手动埋点的代码冗余问题，一些工具库提供了 StopWatch（秒表）工具。Spring Framework 和 Google Guava 中都有提供。

实现方式 (以 Spring 的 StopWatch 为例):

import org.springframework.util.StopWatch;

public void doComplexTask() {
    StopWatch sw = new StopWatch("复杂任务耗时分析");

    sw.start("步骤一：查询用户信息");
    // ... task 1 ...
    sw.stop();

    sw.start("步骤二：调用外部API");
    // ... task 2 ...
    sw.stop();

    log.info(sw.prettyPrint()); // 打印出格式化的耗时报告
}

输出示例：

StopWatch '复杂任务耗时分析': running time = 250ms
---------------------------------------------
ms     %     Task name
---------------------------------------------
100    040%  步骤一：查询用户信息
150    060%  步骤二：调用外部API

• • 优点：

  • • API 更友好，代码更具可读性。

  • • 能轻松地对一个方法内的多个子任务进行分段计时。

• • 缺点：

  • • 本质上仍是手动埋点，依然存在代码侵入性问题。

• • 推荐使用场景：

  • • 需要对单个方法内部的复杂流程进行详细性能分析时。

3. “黄金”级：Spring AOP 切面

这是实现无侵入式耗时统计的“质的飞跃”。通过 AOP，我们可以将耗时统计逻辑从业务代码中完全剥离。

实现方式：

1. 1. 定义一个注解 @Timed:

   @Target(ElementType.METHOD)
   @Retention(RetentionPolicy.RUNTIME)
   public @interface Timed {}

2. 2. 创建一个 AOP 切面:

   @Aspect
   @Component
   public class PerformanceAspect {
       private static final Logger log = LoggerFactory.getLogger(PerformanceAspect.class);
   
       // 拦截所有被 @Timed 注解标记的方法
       @Around("@annotation(com.example.annotation.Timed)")
       public Object measureExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
           long startTime = System.currentTimeMillis();
           try {
               return joinPoint.proceed(); // 执行原始方法
           } finally {
               long costTime = System.currentTimeMillis() - startTime;
               log.info("方法 [{}] 执行耗时: {} ms", joinPoint.getSignature().toShortString(), costTime);
           }
       }
   }

3. 3. 在业务方法上使用注解:

   @Service
   public class OrderService {
       @Timed // <-- 只需一个注解
       public void createOrder() {
           // ... 核心业务逻辑，代码非常纯净 ...
       }
   }

• • 优点：

  • • 零侵入: 业务代码与监控代码完全解耦。

  • • 声明式: 只需一个注解即可应用，非常方便。

  • • 可复用: 一个切面可以服务于整个应用的所有方法。

• • 缺点：

  • • AOP 自身存在一些限制（如著名的“同类方法调用失效”问题）。

  • • 只能作用于 Spring 管理的 Bean。

• • 推荐使用场景：

  • • 绝大多数 Spring/Spring Boot 应用中，进行方法级耗时监控的最佳实践。

4. “钻石”级：Java Agent 字节码增强

这是 APM (应用性能监控) 系统（如 SkyWalking, New Relic）所使用的“黑科技”。

实现方式：
Java Agent 是一种特殊的 JAR 包，它可以在 JVM 启动时（或运行时）挂载到目标 Java 进程上。它利用 Java 的 Instrumentation API，可以在加载类文件时，动态地修改其字节码。

工作流程：

1. 1. 开发者编写一个 Agent，定义一个 ClassFileTransformer。

2. 2. 这个 Transformer 负责找到目标类和方法（例如 com.example.service.OrderService.createOrder）。

3. 3. 使用 ASM 或 ByteBuddy 等字节码操作库，在目标方法的字节码之前插入“记录开始时间”的指令，在之后插入“计算并上报耗时”的指令。

4. 4. 应用在启动时，通过 -javaagent:/path/to/agent.jar 参数来加载这个 Agent。

• • 优点：

  • • 完全无侵入: 对业务代码是“零感知”，甚至无需任何注解。

  • • 能力强大: 可以监控任何 Java 代码，包括第三方库甚至 JDK 的内部方法。

• • 缺点：

  • • 实现复杂度极高: 编写和调试 Java Agent 的门槛远高于 AOP。

  • • 部署更复杂: 需要修改应用的启动脚本。

• • 推荐使用场景：

  • • 开发通用的、与具体应用无关的 APM 监控产品。

  • • 需要对无法修改源码的第三方库进行深度监控时。

5. “王者”级：标准化度量 Starter (AOP + Micrometer)

这是我们在之前文章中探讨过的**“标准化应用度量 Starter”**，它是 AOP 方案的终极进化形态。

实现方式：
它与“黄金级”的 AOP 方案类似，但核心区别在于处理结果的方式。它不再是简单地将耗时打印到日志文件，而是将耗时作为一个结构化的度量 (Metric)，通过 Micrometer 库上报给监控系统（如 Prometheus）。

// 切面逻辑的变化
// ...
finally {
    long duration = System.nanoTime() - startTime;
    // 不再是 log.info(...)，而是上报给 MeterRegistry
    Timer.builder("method.execution.time")
            .tag("class", joinPoint.getSignature().getDeclaringTypeName())
            .tag("method", joinPoint.getSignature().getName())
            .register(meterRegistry)
            .record(duration, TimeUnit.NANOSECONDS);
}

• • 优点：

  • • 具备 AOP 的所有优点（零侵入、声明式）。

  • • 数据结构化: 产生的是可聚合、可查询、可告警的时序数据，而不仅仅是文本日志。

  • • 与可观测性体系打通: 指标可以与 Grafana 大盘、Prometheus 告警规则、甚至容量规划模型联动。

• • 缺点：

  • • 需要搭建和维护一套 Metrics 监控体系。

• • 推荐使用场景：

  • • 所有现代化的、面向生产环境的微服务应用的最终选择。

总结与推荐

姿势	侵入性	复杂度	适用场景
青铜级 (手动埋点)	极高	极低	临时本地调试
白银级 (StopWatch)	高	低	单方法内部分段分析
黄金级 (Spring AOP)	无 (注解)	中等	大多数应用级监控的标准实践
钻石级 (Java Agent)	无 (外部)	极高	APM 产品开发，监控第三方库
王者级 (Metrics Starter)	无 (注解)	中等	现代生产级微服务的终极方案

对于绝大多数业务开发者来说，“黄金级”的 Spring AOP 是最实用、性价比最高的选择。而如果你正在构建一个需要长期维护、对可观测性有高要求的系统，那么**“王者”级的标准化度量 Starter** 则是你迈向 SRE 和平台工程的必经之路。