如何知道整个系统每个方法的执行时间

发布时间：2021-10-19 11:19:56 作者：iii
来源：亿速云阅读：183

# 如何知道整个系统每个方法的执行时间

## 引言

在软件开发过程中，性能优化是永恒的话题。当系统出现性能瓶颈时，开发人员需要快速定位到耗时较长的代码段。了解每个方法的执行时间是性能调优的基础工作之一。本文将详细介绍多种获取方法执行时间的方案，涵盖日志埋点、AOP、APM工具、字节码增强等主流技术，并分析各自的优缺点和适用场景。

---

## 一、基础方案：手动埋点计时

### 1.1 核心实现原理
```java
long start = System.currentTimeMillis();
try {
    // 业务代码
} finally {
    long cost = System.currentTimeMillis() - start;
    System.out.println("methodA executed in " + cost + "ms");
}

1.2 优缺点分析

优点： - 实现简单，无需引入第三方依赖 - 可精确控制需要监控的代码段

缺点： - 代码侵入性强，需要修改每个方法 - 大量重复代码难以维护 - 输出分散，需要额外收集分析

1.3 适用场景

临时性调试
小型项目快速验证

二、面向切面编程（AOP）方案

2.1 Spring AOP 实现

@Aspect
@Component
public class TimeMonitorAspect {
    
    @Around("execution(* com.yourpackage..*.*(..))")
    public Object monitor(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.currentTimeMillis();
        try {
            return pjp.proceed();
        } finally {
            System.out.println(pjp.getSignature() + " cost: " + 
                (System.currentTimeMillis() - start) + "ms");
        }
    }
}

2.2 技术要点

切入点表达式配置
- * com.yourpackage..*.*(..) 监控指定包下所有方法
- 支持更细粒度的过滤条件
性能数据输出方式
- 日志文件（建议异步写入）
- 消息队列（如Kafka）
- 时序数据库（如InfluxDB）

2.3 优缺点对比

优势： - 非侵入式实现 - 集中化管理监控逻辑 - 支持动态开关

局限性： - 无法监控非Spring管理的对象 - 对private方法无效 - 存在代理开销（约5-15%性能损耗）

三、APM全链路监控方案

3.1 主流工具对比

工具名称	公司	核心特性	开源协议
SkyWalking	Apache	分布式追踪、JVM监控	Apache 2.0
Pinpoint	Naver	全自动探针、调用拓扑	Apache 2.0
Arthas	Alibaba	运行时诊断、热修复	GPLv3

3.2 SkyWalking 部署示例

# docker-compose.yml 配置片段
skywalking-oap:
  image: apache/skywalking-oap-server:9.4.0
  ports:
    - "11800:11800"
    - "12800:12800"

skywalking-ui:
  image: apache/skywalking-ui:9.4.0
  ports:
    - "8080:8080"

3.3 数据采集原理

字节码增强技术（Byte Buddy）
探针自动注入方法计时逻辑
上下文传播实现调用链关联

四、JVM 内置方案

4.1 JFR（Java Flight Recorder）

# 启动记录
jcmd <pid> JFR.start duration=60s filename=recording.jfr

# 分析结果
jfr print --events jdk.ExecutionSample recording.jfr

4.2 关键事件类型

事件类型	说明
jdk.ExecutionSample	方法执行采样
jdk.CPULoad	CPU使用情况
jdk.GCHeapSummary	堆内存统计

4.3 注意事项

需要商业授权（JDK11+已开源）
采样间隔影响精度（默认10ms）
建议生产环境持续录制

五、字节码增强方案

5.1 Java Agent 实现

public class TimingAgent {
    public static void premain(String args, Instrumentation inst) {
        inst.addTransformer(new TimingTransformer());
    }
}

class TimingTransformer implements ClassFileTransformer {
    public byte[] transform(ClassLoader loader, String className, 
                          Class<?> classBeingRedefined,
                          ProtectionDomain protectionDomain,
                          byte[] classfileBuffer) {
        // 使用ASM修改字节码
    }
}

5.2 关键技术点

ASM字节码操作框架
方法进入/退出指令插入
类加载过滤机制

5.3 性能影响评估

操作类型	额外耗时
方法进入记录	50-100ns
上下文保存	200-500ns
异步上报	1-5ms（网络）

六、生产环境实践建议

6.1 监控策略

分层采样：
- 核心服务：全量采集
- 普通服务：1%采样率
分级报警：
- >500ms：立即报警
- 100-500ms：每日报告
趋势分析：
- 同比/环比变化监控
- 版本发布对比

6.2 数据可视化

推荐Grafana看板配置：

SELECT 
  method_name,
  avg(duration) 
FROM method_metrics
WHERE time > now() - 1h
GROUP BY method_name
ORDER BY avg DESC
LIMIT 20

6.3 性能优化闭环

发现瓶颈 -> 2. 优化代码 ->
基准测试 -> 4. 上线验证 ->
持续监控

结论

获取方法执行时间有多种技术路线，建议根据实际场景选择： - 开发阶段：使用Arthas实时诊断 - 测试环境：AOP+日志分析 - 生产环境：APM全链路监控 - 深度优化：JFR+字节码增强

随着云原生技术的发展，eBPF等新技术正在改变性能监控的格局，但基本原理仍然相通。良好的监控体系应该像汽车的仪表盘，既能实时反映运行状态，又能为长期优化提供数据支撑。

本文示例代码仓库：https://github.com/example/method-timing-demo “`

（注：实际文章约2500字，此处展示核心框架和关键技术点。完整版应包含更多配置示例、性能数据图表和案例分析。）