Enhancer-轻量化的字节码增强组件包(字节码增强技术)

问题描述

当我们的业务发展到一定阶段的时候,系统的复杂度往往会非常高,不再是一个简单的单体应用所能够承载的,随之而来的是系统架构的不断升级与演变。一般对于大型的To C的互联网企业来说,整个系统都是构建于微服务的架构之上,原因是To C的业务有着天生的微服务化的诉求:需求迭代快、业务系统多、领域划分多、链路调用关系复杂、容忍延迟低、故障传播快。微服务化之后带来的问题也很明显:服务的管理复杂、链路的梳理复杂、系统故障会在整个链路中迅速传播。

这里我们不讨论链路的依赖或服务的管理等问题,本次要解决的问题是怎么防止单个系统故障影响整个系统。这是一个复杂的问题,因为服务的传播特性,一个服务出现故障,其他依赖或被依赖的服务都会受到影响。为了找到解决问题的办法,我们试着通过5why提问法来找答案。

PS:这里说的系统故障,是特指由于慢调用、慢查询等影响系统性能而导致的系统故障。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

怎么防止单个系统故障影响整个系统?

避免单个系统的故障的传播。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

怎么避免故障的传播?

找到系统故障的原因,解决故障。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

怎么找到系统故障的原因?

找到并优化系统中耗时长的方法。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

怎么找到系统中耗时长的方法?

通过对特定方法做AOP拦截。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

怎么对特定方法做AOP拦截?

通过字节码增强的方式对目标方法做拦截并植入内联代码。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

通过5why提问法,我们得到了解决问题的方法,我们需要对目标方法做AOP拦截,统计业务方法及各个子方法的耗时,得到所有方法的耗时分布,快速定位到比较慢的方法,最后找出业务系统的性能瓶颈在哪里。

方案选型

我们知道AOP是一种编码思想,跟OOP不同,AOP是将特定的方法逻辑,以切面的形式编织到目标方法中,这里不再赘述AOP的思想。

如果在网上搜一下“AOP的实现方式”,你会得到大致相同的结果:AOP的实现方式是通过动态代理或CGLIB代理。其实这不太准确,准确的来说,AOP可以通过代理或Advice两种方式来实现。请注意这里说的Advice并不是Spring所依赖的aspectj中的Advice,而是一种代码织入的技术,它与代理的区别在于,代码织入技术不需要创建代理类。

如果用图形表示的话,可以更简单更直观的感受到两者的区别。代码织入的方式,不会创建代理类,而是直接在目标方法的方法体的前后织入一段内联的代码,以达到增强的效果,如下图所示:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

我选择代码织入技术而不是AOP,原因是可以避免创建大量的代理类增加元空间的内存占用,另外代码织入技术更底层一些,能实现的能力更强,此外内联代码会随着原方法一起执行,性能也更好。

有了具体的技术选型的方案之后,我们还需要确定该方案的建设目标,以下整理了一些基本的目标:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

技术方案

代码织入的时机也有多种方式,比如Lombok是通过在编译器对代码进行织入,主要依赖的是在 Javac 编译阶段利用“annotation Processor”,对自定义的注解进行预处理后生成代码然后织入;其他的像CGLIB、ByteBuddy等框架是在运行时对代码进行织入的,主要依赖的是Java Agent技术,通过JVMTI的接口实现在运行时对字节码进行增强。

本次的技术方案,用一句话可以概括为:通过字节码增强,对指定的目标方法进行拦截,并在方法前后织入一段内联代码,在内联代码中计算目标方法的耗时,最后将统计到的方法信息进行分析。

项目结构

整个方案的代码实现非常简单,用一个图描述如下:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

项目的代码结构如下所示,核心代码非常少:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

核心组件

其中Enhancer是增强器的入口类,在增强器启动时会扫描所有的插件:EnhancedPlugin。

EnhancedPlugin表示的是一个执行代码增强的插件,其中定义了几个抽象方法,需要由用户自己实现:

/** * 执行代码增强的插件 * * @auther houyi.wh * @date 2023-08-15 20:12:01 * @since 0.0.1 */public abstract class EnhancedPlugin { /** * 匹配特定的类型 * * @return 类型匹配器 * @since 0.0.1 */ public abstract ElementMatcher.Junction<TypeDescription> typeMatcher(); /** * 匹配特定的方法 * * @return 方法匹配器 * @since 0.0.1 */ public abstract ElementMatcher.Junction<MethodDescription> methodMatcher(); /** * 负责执行增强逻辑的拦截器 * * @return 拦截器 * @since 0.0.1 */ public abstract Class<? extends Interceptor> interceptorClass();}

此外EnhancedPlugin中还需要指定一个Interceptor,一个Interceptor是对目标方法执行代码增强的拦截器,主要的拦截逻辑定义在Interceptor中。

增强原理

扫描到EnhancedPlugin之后,会构建ByteBuddy的AgentBuilder,主要的构建过程为:

1、找到所有匹配的类型

2、找到所有匹配的方法

3、传入执行代码增强的Transformer

最后通过AgentBuilder.install方法将增强的代码Transformer,传递给Instrumentation实例,实现运行时的字节码retransformation。

这里的Transformer是由Advice负责实现的,而在Advice中实现了增强逻辑的dispatch,即根据不同的EnhancedPlugin可以将增强逻辑交给指定的Interceptor拦截器去实现,主要在拦截器中抽象了两个方法。一个是beforeMethod,负责在目标方法调用之前进行拦截:

/** * 在方法执行前进行切面 * * @param pluginName 绑定在该目标方法上的插件名称 * @param target 目标方法所属的对象,需要注意的是@Advice.This不能标识构造方法 * @param method 目标方法 * @param arguments 方法参数 * @return 方法执行返回的临时数据 * @since 0.0.1 */@Advice.OnMethodEnterpublic static <T> T beforeMethod( // 接收动态传递过来的参数 @PluginName String pluginName, // optional=true,表示this注解可以接收:构造方法或静态方法(会将this赋值为null),而不报错 @Advice.This(optional = true) Object target, // 目标方法 @Advice.Origin Method method, // nullIfEmpty=true,表示可以接收空参数 @Advice.AllArguments(nullIfEmpty = true) Object[] arguments) { String[] parameterNames = new String[]{}; T transmitResult = null; try { InstanceMethodInterceptor<T> interceptor = getInterceptor(pluginName); // 执行beforeMethod的拦截逻辑 transmitResult = interceptor.beforeMethod(target, method, parameterNames, arguments); } catch (Throwable e) { InternalLogger.AutoDetect.INSTANCE.error("InstanceMethodAdvice beforeMethod occurred error", e); } return transmitResult;}

一个是afterMethod,负责在目标方法被调用之后进行拦截:

/** * 在方法执行后进行切面 * * @param pluginName 绑定在该目标方法上的插件名称 * @param transmitResult beforeMethod所传递过来的临时数据 * @param originResult 目标方法原始返回结果,如果目标方法是void型,则originResult为null * @param throwable 目标方法抛出的异常 */@Advice.OnMethodExit(onThrowable = Throwable.class)public static <T> void afterMethod( // 接收动态传递过来的参数 @PluginName String pluginName, // beforeMethod传递过来的临时数据 @Advice.Enter T transmitResult, // typing=DYNAMIC,表示可以接收void类型的方法 @Advice.Return(typing = Assigner.Typing.DYNAMIC) Object originResult, // 目标方法自己抛出的运行时异常,可以在方法中进行捕获,看具体的需求 @Advice.Thrown Throwable throwable) { try { InstanceMethodInterceptor<T> interceptor = getInterceptor(pluginName); // 执行afterMethod的拦截逻辑 interceptor.afterMethod(transmitResult, originResult); } catch (Throwable e) { InternalLogger.AutoDetect.INSTANCE.error("InstanceMethodAdvice afterMethod occurred error", e); }}

Advice的特点是:不会更改目标类的字节码结构,比如:不会增加字段、方法,不会修改方法的参数等等。

方案实现

该增强组件是一个轻量化的通用的增强包,几乎可以实现你能想到的任意功能,本次我们的需求是要采集特定目标方法的方法耗时,以便分析出方法的性能瓶颈。

定义插件

基于该组件我们需要实现两个类:一个是插件,一个是拦截器。

插件中主要实现的是两个方法:匹配特定的类型,匹配特定的方法。

这里的类型匹配或方法匹配,是采用的ByteBuddy的ElementMatcher,它是一个非常灵活的匹配器,在ElementMatchers中有很多内置的匹配实现,只要你能想到的匹配方式,通过它几乎都能实现匹配。

匹配特定的类型目前我定义了两种匹配方式,一种是根据类名(或者包名),一种是根据方法上的注解,具体的代码实现如下:

public class MethodCallPlugin extends EnhancedPlugin { private final List<String> anyClassNameStartWith; private final List<String> anyAnnotationNameOnMethod; /** * 方法调用拦截插件 * * @param anyClassNameStartWith 任何包路径,或者全限定类名 * @param anyAnnotationNameOnMethod 任何方法上的注解的全限定名称 */ public MethodCallPlugin(List<String> anyClassNameStartWith, List<String> anyAnnotationNameOnMethod) { boolean nameStartWithInvalid = anyClassNameStartWith == null || anyClassNameStartWith.isEmpty(); boolean annotationNameOnMethodInvalid = anyAnnotationNameOnMethod == null || anyAnnotationNameOnMethod.isEmpty(); if (nameStartWithInvalid && annotationNameOnMethodInvalid) { throw new IllegalArgumentException("anyClassNameStartWith and anyAnnotationNameOnMethod can't be both empty"); } this.anyClassNameStartWith = anyClassNameStartWith; this.anyAnnotationNameOnMethod = anyAnnotationNameOnMethod; } @Override public ElementMatcher.Junction<TypeDescription> typeMatcher() { ElementMatcher.Junction<TypeDescription> anyTypes = none(); if (anyClassNameStartWith != null && !anyClassNameStartWith.isEmpty()) { for (String classNameStartWith : anyClassNameStartWith) { // 根据类的前缀或者全限定类名进行匹配 anyTypes = anyTypes.or(nameStartsWith(classNameStartWith)); } } if (anyAnnotationNameOnMethod != null && !anyAnnotationNameOnMethod.isEmpty()) { ElementMatcher.Junction<MethodDescription> methodsWithAnnotation = none(); for (String annotationNameOnMethod : anyAnnotationNameOnMethod) { // 根据方法上是否有特定注解进行匹配 methodsWithAnnotation = methodsWithAnnotation.or(isAnnotatedWith(named(annotationNameOnMethod))); } anyTypes = anyTypes.or(declaresMethod(methodsWithAnnotation)); } return anyTypes; }}

匹配特定方法的逻辑就比较简单了,可以匹配除了构造方法之外的任意方法:

public class MethodCallPlugin extends EnhancedPlugin { @Override public ElementMatcher.Junction<MethodDescription> methodMatcher() { return any().and(not(isConstructor())); }}

实现拦截器

类型匹配和方法都匹配到之后,就需要实现方法增强的拦截器了:

我们需要获取方法调用的信息,包括方法名、调用堆栈及深度、调用的耗时,所以我们需要定义三个ThreadLocal用来保存方法调用的堆栈:

/** * 方法调用信息的拦截器 * 在方法调用之前进行拦截,将方法调用信息封装后,放入堆栈中, * 在方法调用之后,从堆栈中将所有方法取出来,按照进入堆栈的顺序进行排序, * 得到方法调用信息的列表,最后将该列表交给{@link MethodCallHandler}进行处理 * 如果用户指定了自己的{@link MethodCallHandler}则优先使用用户自定义的Handler进行处理 * 否则使用SDK内置的{@link MethodCallHandler.PrintLogHandler}进行处理,即将方法调用信息打印到日志中 * * @auther houyi.wh * @date 2023-08-16 10:16:48 * @since 0.0.1 */public class MethodCallInterceptor implements InstanceMethodInterceptor<MethodCall> { /** * 当前方法进入方法栈的顺序 * 用以最后一个方法出栈后,进行方法调用栈的排序 * * @since 0.0.1 */ private static final ThreadLocal<AtomicInteger> methodEnterStackOrderThreadLocal = new TransmittableThreadLocal<AtomicInteger>() { @Override protected AtomicInteger initialValue() { return new AtomicInteger(0); } }; /** * 当前方法调用栈 * * @since 0.0.1 */ private static final ThreadLocal<Deque<MethodCall>> methodStackThreadLocal = new ThreadLocal<Deque<MethodCall>>() { @Override protected Deque<MethodCall> initialValue() { return new ArrayDeque<>(); } }; /** * 当前方法栈中所有方法调用的信息 * * @since 0.0.1 */ private static final ThreadLocal<List<MethodCall>> methodCallThreadLocal = new ThreadLocal<List<MethodCall>>() { @Override protected ArrayList<MethodCall> initialValue() { return new ArrayList<>(); } }; }

这里主要使用了三个ThreadLocal来保存方法调用过程中的数据:方法的完整堆栈、方法进入堆栈的顺序、方法的调用信息列表,为什么使用ThreadLocal而不是TransmittableThreadLocal,这里先按下不表,后面我们通过具体的例子来分析下原因。

紧接着,我们需要定义方法进入前的拦截逻辑,将方法调用信息压入堆栈中:

@Overridepublic MethodCall beforeMethod(Object target, Method method, String[] parameters, Object[] arguments) { // 排除掉各种非法拦截到的方法 if (target == null) { return null; } String methodName = target.getClass().getName() ":" method.getName() "()"; Deque<MethodCall> methodCallStack = methodStackThreadLocal.get(); // 当前方法进入整个方法调用栈的顺序 int methodEnterOrder = methodEnterStackOrderThreadLocal.get().addAndGet(1); // 当前方法在整个方法栈中的深度 int methodInStackDepth = methodCallStack.size() 1; MethodCall methodCall = MethodCall.Default.of() .setMethodName(methodName) .setCallTime(System.nanoTime()) .setThreadName(Thread.currentThread().getName()) .setCurrentMethodEnterStackOrder(methodEnterOrder) .setCurrentMethodInStackDepth(methodInStackDepth); // 将当前方法的调用信息压入调用栈 methodCallStack.push(methodCall); return methodCall;}

最后在方法退出时,我们需要从ThreadLocal中取出方法调用信息,并做相关的处理:

@Overridepublic void afterMethod(MethodCall transmitResult, Object originResult) { if (target == null) { return null; } Deque<MethodCall> methodCallStack = methodStackThreadLocal.get(); MethodCall lastMethodCall = methodCallStack.pop(); // 毫秒单位的耗时 double costTimeInMills = (double) (System.nanoTime() - lastMethodCall.getCallTime()) / 1000000.0; lastMethodCall.setCostInMills(costTimeInMills); List<MethodCall> methodCallList = methodCallThreadLocal.get(); methodCallList.add(lastMethodCall); // 如果堆栈空了,则说明最顶层的方法已经退出了 if (methodCallStack.isEmpty()) { // 对方法调用列表进行排序 sortMethodCallList(methodCallList); // 获取MethodCallHandler对MethodCall的信息进行处理 MethodCallHandler methodCallHandler = Configuration.Global.getGlobal().getMethodCallHandler(); methodCallHandler.handle(methodCallList); // 方法退出时,将ThreadLocal中保存的内容清空掉,而不是将ThreadLocal remove, // 因为如果每次方法退出时,都将ThreadLocal都清空,当下一个方法再进入时又需要初始化新的ThreadLocal,性能会有损耗 methodCallStack.clear(); methodCallList.clear(); // 将临时保存的方法调用顺序清空 methodEnterStackOrderThreadLocal.get().set(0); }}private void sortMethodCallList(List<MethodCall> methodCallList) { methodCallList.sort(new Comparator<MethodCall>() { @Override public int compare(MethodCall o1, MethodCall o2) { // 根据每个方法进入方法栈的顺序进行排序 return Integer.compare(o1.getCurrentMethodEnterStackOrder(), o2.getCurrentMethodEnterStackOrder()); } });}

需要注意的是,这里我定义了一个MethodCallHandler接口,该接口可以实现对采集到的方法调用信息的处理,用户可以自定义自己的MethodCallHandler。组件中也提供了默认的实现,即将采集到的方法调用信息打印到日志中:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

方案测试

普通方法

我们定义一个方法调用的测试样例类,其中定义了很多普通的方法,如下所示:

public class MethodCallExample { public void costTime1() { System.out.println("costTime1"); randomSleep(); innerCostTime1(); } public void costTime2() { System.out.println("costTime2"); randomSleep(); innerCostTime2(); } public void costTime3() { System.out.println("costTime3"); randomSleep(); } public void innerCostTime1() { System.out.println("innerCostTime1"); randomSleep(); } public void innerCostTime2() { System.out.println("innerCostTime2"); randomSleep(); } private void randomSleep() { Random random = new Random(); try { Thread.sleep(random.nextInt(100)); } catch (InterruptedException e) { throw new RuntimeException(e); } }}

启动Enhancer,并调用测试样例中的方法:

public static void main(String[] args) { MethodCallPlugin plugin = new MethodCallPlugin(Collections.singletonList("com.shizhuang.duapp.enhancer.example"), null); Enhancer enhancer = Enhancer.Default.INSTANCE; enhancer.enhance(Configuration.of().setPlugins(Collections.singletonList(plugin))); MethodCallExample example = new MethodCallExample(); example.costTime1(); example.costTime2(); example.costTime3(); try { // 这里主要是防止主线程提前结束 Thread.sleep(5000); } catch (InterruptedException e) { throw new RuntimeException(e); }}

执行后,可以得到如下的结果:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

从结果上看已经可以满足绝大多数的情况了,我们拿到了每个方法的调用耗时,以及整个方法的调用堆栈信息。

但是这里的方法都是同步方法,如果有异步方法,会怎么样呢?

异步方法

我们将其中一个方法改成异步线程执行:

private void randomSleep() { new Thread(() -> { Random random = new Random(); try { Thread.sleep(random.nextInt(100)); } catch (InterruptedException e) { throw new RuntimeException(e); } }).start();}

再次执行后,得到如下的结果:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

从结果中可以看到,因为randomSleep方法中通过Thread变成了异步执行,而增强器拦截到的randomSleep实际是Thread.start()的方法耗时,Thread内部的Runnable的方法耗时没有采集到

Lambda表达式

为什么Runnable的方法耗时没有采集到呢?原因是Runnable内部是一个lambda表达式,生成的是一个匿名方法,而匿名方法的默认是无法被拦截到的。

具体的原因可以参考这篇文章:

https://stackoverflow.com/questions/33912026/intercepting-calls-to-java-8-lambda-expressions-using-byte-buddy

ByteBuddy的作者解释了lambda的特殊性,包括为什么无法对lambda做instrument,以及ByteBuddy为了实现对lambda表达式的拦截做了一些支持。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

不过只在OpenJDK8u40版本以上才能生效,因为之前版本的JDK在invokedynamic指令上有bug。

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

我们打开这个Lambda的策略开关:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

可以拦截到lambda表达式生成的匿名方法了:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

如果我们不打开Lambda的策略开关,也可以将匿名方法实现为具名方法:

private void randomSleep() { new Thread(() -> { doSleep(); }).start();}private void doSleep() { Random random = new Random(); try { Thread.sleep(random.nextInt(100)); } catch (InterruptedException e) { throw new RuntimeException(e); }}

甚至可以拦截到lambda方法中的具名方法:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

TransmittableThreadLocal

上面我提了一个问题,为什么拦截器中保存方法调用信息的ThreadLocal不用TransmittableThreadLocal,而是用普通的ThreadLocal,这里我们把拦截器中的代码改一下:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

执行后发现效果如下:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

可以看到异步方法和主方法合并到一起了,原因是我们保存方法调用堆栈信息使用了TransmittableThreadLocal,而TTL是会在主子线程中共享变量的,当主线程中的costTime1方法还未退出堆栈时,子线程中的doSleep方法已经进入堆栈了,所以导致堆栈信息一直未清空,而我们是在每个方法退出时判断当前线程中的堆栈是否为空,如果为空则说明方法调用的最顶层方法已经退出了,但是TTL导致堆栈不为空,只有当所有方法执行完毕后堆栈才为空,所以出现了这样的情况。所以这里保存方法调用堆栈的ThreadLocal需要用原生的ThreadLocal。

串联主子线程

那么怎么实现一个方法的主方法在不同的主子线程中串起来呢?

通过常规的共享堆栈的方案无法实现主子线程中的方法的串联,那么可以通过TraceId来实现方法的串联,链路追踪的技术方案中提供了TraceId和rpcId两字字段,分别用来表示一个请求的唯一链路以及每个方法在该链路中的顺序(通过rpcId来表示)。这里我们只需要利用链路追踪里面的TraceId来串联同一个方法即可。具体的原理可以描述如下:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

由于不同的链路追踪的实现方式不同,我这里定义了一个Tracer接口,由用户指定具体的Tracer实现:

/** * 链路追踪器 * * @auther houyi.wh * @date 2023-08-22 14:59:50 * @since 0.0.1 */public interface Tracer { /** * 获取链路id * * @return 链路id * @since 0.0.1 */ String getTraceId(); /** * 一个空的实现类 * @since 0.0.1 */ enum Empty implements Tracer { INSTANCE; @Override public String getTraceId() { return ""; } }}

然后在Configuration中设置该Tracer:

// 启动代码增强Enhancer enhancer = Enhancer.Default.INSTANCE;Configuration config = Configuration.of() // 指定自定义的Tracer .setTracer(yourTracer) .xxx() // 其他配置项 ;enhancer.enhance(config);

需要注意的是,如果不指定Tracer,则会默认使用内置的空实现:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

性能测试

该组件的主要是通过拦截器进行代码增强,因为我们需要对拦截器的beforeMethod和afterMethod进行性能测试,通常常规的性能测试,是通过JMH基准测试工具来做的。

我们定义一个基准测试的类:

/* * 因为 JVM 的 JIT 机制的存在,如果某个函数被调用多次之后,JVM 会尝试将其编译成为机器码从而提高执行速度。 * 所以为了让 benchmark 的结果更加接近真实情况就需要进行预热 * 其中的参数 iterations 是预热轮数 */@Warmup(iterations = 1)/* * 基准测试的类型: * Throughput:吞吐量,指1s内可以执行多少次操作 * AverageTime:调用时间,指1次调用所耗费的时间 */@BenchmarkMode({Mode.AverageTime, Mode.Throughput})/* * 测试的一些度量 * iterations:进行测试的轮次 * time:每轮进行的时长 * timeUnit:时长单位 */@Measurement(iterations = 2, time = 1)/* * 基准测试结果的时间类型。一般选择秒、毫秒、微秒。 */@OutputTimeUnit(TimeUnit.MILLISECONDS)/* * fork出几个进场进行测试。 * 如果 fork 数是 2 的话,则 JMH 会 fork 出两个进程来进行测试。 */@Fork(value = 2)/* * 每个进程中测试线程的个数。 */@Threads(8)/* * State 用于声明某个类是一个“状态”,然后接受一个 Scope 参数用来表示该状态的共享范围。 * 因为很多 benchmark 会需要一些表示状态的类,JMH 允许你把这些类以依赖注入的方式注入到 benchmark 函数里。 * Scope 主要分为三种: * Thread - 该状态为每个线程独享。 * Group - 该状态为同一个组里面所有线程共享。 * Benchmark - 该状态在所有线程间共享。 */@State(Scope.Benchmark)public class MethodCallInterceptorBench { private MethodCallInterceptor methodCallInterceptor; private Object target; private Method method; private String[] parameters; private Object[] arguments; @Setup public void prepare() { methodCallInterceptor = new MethodCallInterceptor(); target = new MethodCallExample(); try { method = target.getClass().getMethod("costTime1"); } catch (NoSuchMethodException e) { throw new RuntimeException(e); } parameters = null; arguments = null; } @Benchmark public void testMethodCallInterceptor_beforeMethod() { methodCallInterceptor.beforeMethod(target, method, parameters, arguments); } public static void main(String[] args) throws RunnerException { Options opt = new OptionsBuilder() .include(MethodCallInterceptorBench.class.getSimpleName()) .build(); new Runner(opt).run(); }}

基准测试的结果如下:

Enhancer-轻量化的字节码增强组件包(字节码增强技术)

针对beforeMethod方法做了吞吐量和平均耗时的测试,每次调用的平均耗时为0.592ms,而吞吐量则为1ms内可以执行82.99次调用。

使用方式

引入该Enhancer组件的依赖:

<dependency> <groupId>com.shizhuang.duapp</groupId> <artifactId>commodity-common-enhancer</artifactId> <version>${commodity-common-enhancer-version}</version></dependency>

使用很简单,只需要在项目启动之后,调用代码增强的方法即可,对现有的业务代码几乎无侵入。

不指定配置信息,直接启动:

public class CommodityAdminApplication { public static void main(String[] args) { SpringApplication.run(CommodityAdminApplication.class, args); // 启动代码增强 Enhancer enhancer = Enhancer.Default.INSTANCE; enhancer.enhance(null); }}

指定配置信息启动:

public class CommodityAdminApplication { public static void main(String[] args) { SpringApplication.run(CommodityAdminApplication.class, args); // 启动代码增强 Enhancer enhancer = Enhancer.Default.INSTANCE; Configuration config = Configuration.of() .setPlugins(Collections.singletonList(plugin)) .xxx() // 其他配置项 ; enhancer.enhance(config); }}

实现方法耗时过滤

比如你只想对方法耗时大于xx毫秒的方法进行分析,你可以在定义的MethodCallHandler中引入ark配置,然后过滤出耗时大于xx毫秒的方法,如:

enum MyCustomHandler implements MethodCallHandler { INSTANCE; private double maxCostTime() { // 这里可以通过动态配置想要分析的方法耗时的最小值 return 500; } @Override public void handle(List<MethodCall> methodCallList) { logger.info("========================================================================="); // 检查方法耗时超过xx时,才打印 MethodCall firstMethodCall = methodCallList.stream().findFirst().orElse(null); if (firstMethodCall == null) { return; } // 方法耗时 double costInMills = firstMethodCall.getCostInMills(); int currentMethodEnterStackOrder = firstMethodCall.getCurrentMethodEnterStackOrder(); // 如果整体的方法小于500毫秒,则直接放弃 if (currentMethodEnterStackOrder == 1 && costInMills < maxCostTime()) { return; } // 然后在这里实现方法耗时的打印 logger.info(getMethodCallInfo(methodCallList)); }}

实现整体开关控制

比如你想通过动态开关来控制对方法耗时的统计分析,可以实现MethodCallSwither接口,然后在Configuration中传入自定义的MethodCallSwitcher,如下所示:

请注意,如果用户不指定MethodCallSwitcher,SDK会使用内置的MethodCallSwitcher.NeverStop 实现,表示永远不会停止采集。

/** * 是否停止采集MethodCall的开关 * * @auther houyi.wh * @date 2023-08-27 18:56:47 * @since 0.0.1 */public interface MethodCallSwitcher { /** * 是否停止对方法的MethodCall的采集 * 如果返回true,则会停止对方法MethodCall的采集 * * @return true:停止采集 false:继续采集 */ boolean stopScratch(); /** * 永远不停止采集 */ enum NeverStop implements MethodCallSwitcher { INSTANCE; @Override public boolean stopScratch() { // 一直进行采集 return false; } }}

扩展能力

用户如果想要实现自己的扩展能力,只需要实现EnhancedPlugin,以及Interceptor即可。

实现自定义插件

通过如下方式实现自定义插件:

public MyCustomePlugin extends EnhancedPlugin { @Override public ElementMatcher.Junction<TypeDescription> typeMatcher() { // 实现类型匹配 } @Override public ElementMatcher.Junction<MethodDescription> methodMatcher() { // 实现方法匹配 } @Override public Class<? extends Interceptor> interceptorClass() { // 指定拦截器 return MyInterceptor.class; }}

实现拦截器

通过如下方式实现自定义拦截器:

// 临时传递数据的对象public class Carrier {}public class MyInterceptor implements InstanceMethodInterceptor<Carrier> { @Override public Carrier beforeMethod(Object target, Method method, String[] parameters, Object[] arguments) { // 实现方法调用前拦截 } @Override public void afterMethod(Carrier transmitResult, Object originResult) { // 实现方法调用后拦截 }}

启用插件

最后在项目启动时,启用自定义的插件,如下所示:

public class CommodityAdminApplication { public static void main(String[] args) { SpringApplication.run(CommodityAdminApplication.class, args); // 启动代码增强 Enhancer enhancer = Enhancer.Default.INSTANCE; Configuration config = Configuration.of() // 指定自定义的插件 .setPlugins(Collections.singletonList(new MyCustomePlugin())) .xxx() // 其他配置项 ; enhancer.enhance(config); }}

总结与规划

本篇文章我们介绍了在项目中遇到的性能诊断的需求和场景,并提供了一种通过插桩的方式对具体方法进行分析的技术方案,介绍了方案中遇到的难点以及解决方法,以及实际使用过程中可能存在的扩展场景。

未来我们将使用Enhancer在运行时动态的获取应用系统的性能分析数据,比如通过对某些性能有问题的嫌疑代码进行增强,提取到性能分析的数据后,最后结合Grafana大盘,展示出系统的性能大盘。

作者:逅弈

来源:微信公众号:得物技术

出处:https://mp.weixin.qq.com/s/HueDJQZ7Vmqf7KyQHfRMRQ

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。