ByteBuddy工具的使用场景有哪些？

ByteBuddy工具的使用场景有哪些？针对这个问题，今天小编总结这篇有关ByteBuddy的文章，可供感兴趣的小伙伴们参考借鉴，希望对大家有所帮助。

创新互联专注于企业成都营销网站建设、网站重做改版、乌拉特中网站定制设计、自适应品牌网站建设、H5高端网站建设、商城网站定制开发、集团公司官网建设、成都外贸网站建设公司、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为乌拉特中等各大城市提供网站开发制作服务。

使用场景1：动态生成JAVA CLASS
这是ByteBuddy最基本但是最有用的USECASE, 比如说，我定义一个SCHEMA，希望根据SCHEMA生成对应的JAVA类并加载到JVM中. 当然你可以用一些模板工具比如VELOCITY之类生成JAVA源代码再进行编译, 但是这样一般需要对项目的BUILD脚本(maven/gradle)进行一些定制. 用ByteBuddy生成类的强大之处在于, 这个类可以通过JAVA代码生成并且可以自动加载到当前的JVM中,这样我可以在application初始化的时候从SCHEMA REGISTRY中读取到SCHEMA定义,通过ByteBuddy生成对应的JAVA类加载到JVM中, 并且一旦SCHEMA发生变化如增加新属性, 不需要做任何改动, 在JVM重启后类定义会自动同步更新. 当然一个限制是你只能用反射的方式访问这个新定义的类. 代码样例如下 (Kotlin语言):

private fun buildSchemaClass(schema: Schema, classLoader: ClassLoader): Class<*> {
        logger.info("Start building schema class for schema={}, version={}", schema.name, schema.version)
        val typeBuilder = ByteBuddy().subclass(Any::class.java).name(className(schema))
        var tempBuilder = typeBuilder
        schema.columns.forEach { column ->
            tempBuilder = tempBuilder
                .defineField(column.name, columnTypeToJavaClassMapping[column.type], Visibility.PRIVATE)
        }
        schema.columns.forEach { column ->
            tempBuilder = tempBuilder.defineMethod(toGet(column.name), columnTypeToJavaClassMapping[column.type], Modifier.PUBLIC)
                .intercept(FieldAccessor.ofBeanProperty())
                .defineMethod(toSet(column.name), Void.TYPE, Modifier.PUBLIC).withParameters(columnTypeToJavaClassMapping[column.type])
                .intercept(FieldAccessor.ofBeanProperty())
        }
        return tempBuilder.make().load(classLoader, ClassLoadingStrategy.Default.WRAPPER).loaded.also {
            logger.info("Success building schema class: {}", it.name)
        }
    }

大家可以看到，定义GET/SET方法完全不需要实现方法体,通过intercept(FieldAccessor.ofBeanProperty) 可以自动将GET/SET方法和对应的属性绑定自动生成方法体.

使用场景2：JAVA AGENT代理.
这是另一个异常强大的功能，可以动态修改类的定义，用于强行修改一些第三方LIB中一些不容易扩展的类，而不需要修改类的源代码和JAR包. 不知道大家有没有用过JAVA 本身的AGENT, 在一些性能监控的工具常常会用到, 需要在JVM启动的时候加agentlib参数，在AGENT中可以对原始JAVA的二进制码做增强埋点. ByteBuddy强大之处是它连agentlib参数都不需要了,侵入性更小. 一个很好的例子是FLYWAY，我们需要在FLYWAY执行数据库脚本的时候将脚本执行到一个额外的数据库(SPANNER). 需要扩展org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor的execute方法执行额外的写操作, 不得不吐槽一下FLYWAY,一大堆的继承接口但是代码基本没法扩展. 这时可以通过ByteBuddy Agent 拦截SqlMigrationExecutor的execute方法,在原始方法执行之后实现额外的数据库写操作. 唯一需要提的一点是ByteBuddy Agent只支持JVM不支持JRE. 代码示例如下:

object SqlMigrationResolverEnhancer {
   fun enhance(inst: Instrumentation) {
        if (!SpannerConfigUtils.enableSpanner) {
            logger.info("Spanner is not enabled!!!!!!!!!!!!!!!!, no intercept will occure")
            return
        }
        val temp = Files.createTempDirectory("tmp").toFile()
        ClassInjector.UsingInstrumentation.of(temp, ClassInjector.UsingInstrumentation.Target.BOOTSTRAP, inst).inject(
                Collections.singletonMap(
                        TypeDescription.ForLoadedType(MigrationResolverInterceptor::class.java),
                        ClassFileLocator.ForClassLoader.read(MigrationResolverInterceptor::class.java!!)
                )
        )
        AgentBuilder.Default()
                .ignore(ElementMatchers.nameStartsWith("net."))
                .ignore(ElementMatchers.nameStartsWith("com."))
                .enableBootstrapInjection(inst, temp)
                .type(ElementMatchers.nameEndsWith("SqlMigrationResolver"))
                .transform { builder, _, _, _ ->
                    builder.method(ElementMatchers.hasMethodName("resolveMigrations"))
                            .intercept(MethodDelegation.to(MigrationResolverInterceptor::class.java))
                }.with(object : AgentBuilder.Listener {
                    override fun onComplete(
                        typeName: String?,
                        classLoader: ClassLoader?,
                        module: JavaModule?,
                        loaded: Boolean
                    ) {
                        // just ignore onComplete
                    }

                    override fun onDiscovery(
                        typeName: String?,
                        classLoader: ClassLoader?,
                        module: JavaModule?,
                        loaded: Boolean
                    ) {
                        // just ignore onDiscovery
                    }

                    override fun onIgnored(
                        typeDescription: TypeDescription?,
                        classLoader: ClassLoader?,
                        module: JavaModule?,
                        loaded: Boolean
                    ) {
                        // just ignore onIgnored
                    }

                    override fun onTransformation(
                        typeDescription: TypeDescription?,
                        classLoader: ClassLoader?,
                        module: JavaModule?,
                        loaded: Boolean,
                        dynamicType: DynamicType?
                    ) {
                        logger.debug("Tranforming class: $typeDescription")
                    }

                    override fun onError(
                        typeName: String?,
                        classLoader: ClassLoader?,
                        module: JavaModule?,
                        loaded: Boolean,
                        throwable: Throwable?
                    ) {
                        logger.error("Error intercepting type: $typeName", throwable)
                    }
                })
                .installOn(inst)
    }
}

class MigrationResolverInterceptor {
    companion object {
        private val logger: Logger = LoggerFactory.getLogger(MigrationResolverInterceptor::class.java)

        @JvmStatic
        @RuntimeType
        fun intercept(@SuperCall delegate: Callable>): Collection {
            val spannerProperties = SpannerProperties(SpannerConfigUtils.projectId, SpannerConfigUtils.instanceId, SpannerConfigUtils.databaseName)
            val originalCol = delegate.call() as MutableList
            logger.info("Intercepting migration resolver method ---------------------------------------- $originalCol")
            return ResolvedMigrationExecutorReplacer.replaceSqlMigrationExecutor(originalCol, spannerProperties)
        }
    }
}

代码并不复杂，通过ElementMatchers先缩小CLASSPATH中扫描包的范围，在通过ElementMatcher类名和方法名指定需要拦截的方法，再指定拦截器的类名. 这里注意的是Agent的enhance方法必须在被拦截的类被JVM加载之前执行，因为一个类在一个CLASSLOADER中只能被加载一次，加载完无法修改了. 注册AgentBuilder.Listener并非必须,但是对排查期望的类方法没有被正确拦截的问题非常有用. 另外注意我们只指定了Interceptor的类名而没有指定方法, 而且Interceptor类中的方法必须是一个Static方法，通过@RuntimeType指定是拦截器需要执行的方法. @SuperCall用于注入原始方法调用的代理. 可以在SpringBoot 主方法的开始调用

SqlMigrationResolverEnhancer.enhance(ByteBuddyAgent.install())

至于ResolveMigrationExecutorReplacer的实现和ByteBuddy无关, 代码仅供参考不再赘述.

object ResolvedMigrationExecutorReplacer {
    private val databaseField = SqlMigrationExecutor::class.java.getDeclaredField("database")
    private val sqlScriptField = SqlMigrationExecutor::class.java.getDeclaredField("sqlScript")

    init {
        databaseField.isAccessible = true
        sqlScriptField.isAccessible = true
    }

    fun replaceSqlMigrationExecutor(migrationList: MutableList, spannerProperties: SpannerProperties): List {
        migrationList.forEach { resolvedMigration ->
            val migrationExecutor = resolvedMigration.executor
            if (migrationExecutor is SqlMigrationExecutor &&
                    resolvedMigration is ResolvedMigrationImpl) {
                val database: Database<*> = databaseField.get(migrationExecutor) as Database<*>
                val sqlScript: SqlScript = sqlScriptField.get(migrationExecutor) as SqlScript
                resolvedMigration.executor = SpannerSqlMigrationExecutor(database, sqlScript, spannerProperties)
            }
        }
        return migrationList
    }
}

使用场景3：AOP切面
和场景2类似，但有时我们不需要改变原始类的实现，而是希望产生一个新的类对原始类的某些行为做增强. AOP本质是生成一个新的PROXY代理类替换原有的实现. JAVA本身提供了基于InvocationHandler的DynamicProxy, 但是有几个比较大的限制. 1. 被拦截的类必须实现一个接口. 2. InvocationHandler 只提供了一个方法: public Object invoke(Object proxy, Method method, Object[] args) throws Throwable. 假设被拦截的接口有很多个方法, 如java.sql.PreparedStatement, 需要对某些方法进行特殊处理，那需要基于方法名写一大堆的If/else逻辑，代码不够优雅. Spring提供了基于AspectJ的AOP, 但是这个强依赖于Spring体系必须是在Spring容器中受管理的Bean. 而ByteBuddy则可通过灵活的匹配模式指定需要代理的方法，其他方法则可默认为原始类的实现不改变行为. 并且类似于ASPECTJ, 切面的实现可以独立出来. 一个使用场景是代理java.sql.DataSource/Connection/PreparedStatement/ResultSet. 指标统计，分库分表等实现都需要. 这里实现了一个简单通用的代理织入器，可以对某个类的某一组方法应用一个Advisor拦截器，返回一个被增强的原始类的子类.

object DelegateAgent {
    fun  buildDelegateClass(sourceClass: Class, methodNames: List,
                           advisorClass: Class<*>): Class {
        val builder = ByteBuddy().subclass(sourceClass, ConstructorStrategy.Default.IMITATE_SUPER_CLASS)
        val methodMatchers = getMethodMachers(methodNames)
        return builder.method(methodMatchers)
            .intercept(MethodDelegation.to(advisorClass))
            .make().load(
                DelegateAgent::class.java.classLoader
            ).loaded
    }

    private fun getMethodMachers(methodNames: List): ElementMatcher {
        var methodMatcher =
            ElementMatchers.none()
        if (methodNames.isEmpty()) {
            return ElementMatchers.any()
        }
        methodNames.forEach {methodName ->
           methodMatcher = methodMatcher.or(ElementMatchers.named(methodName))
        }
        return methodMatcher
    }
}

注意ByteBuddy().subclass(sourceClass, ConstructorStrategy.Default.IMITATE_SUPER_CLASS), 这样生成的子类自动拥有父类所有的Constructor. 无需重新定义. 使用的例子如下:

object DataSourceAdvisor {
    @JvmStatic
    @RuntimeType
    fun onMethodExecution(
        @This sourceObj: Any,
        @Origin method: Method
        @AllArguments arguments: Array): Any {
        //just for demo purpose
                println("Current method is: " + method.name)
        return method.invoke(sourceObj, * arguments)
    }
}

fun testAgent() {
        val config = HikariConfig().apply {
            this.jdbcUrl = "jdbc:MySQL://xxxx"
            this.driverClassName = "org.postgresql.Driver"
            this.username = "postgres"
            this.password = "postgres"
            this.maximumPoolSize = 1
        }
        val resultDsClass = DelegateAgent.buildDelegateClass(HikariDataSource::class.java, listOf("getConnection"),
            DataSourceAdvisor::class.java)
        val newDs = resultDsClass.getConstructor(HikariConfig::class.java).newInstance(config)
        println(newDs.connection)

    }

这里的拦截器仅仅打印了方法名. 和场景二的非常相似，拦截器的实现也是一个类的静态方法，唯一的区别是原始对象，参数列表等使用的Annotation不同，场景2中应该使用net.bytebuddy.asm.Advice中的annotation. 场景3应该使用的是net.bytebuddy.implementation.bind.annotation包中的annotation

使用ByteBuddy中的碰到一些问题：

场景2 Agent实现中如果方法的参数签名和拦截器的参数不完全匹配，则需要使用@RuntimeType annotation. 否则可能遇到以下错误:
```
java.lang.IllegalArgumentException: None of [interceptor methods]  allows for delegation from [target method]
at net.bytebuddy.implementation.bind.MethodDelegationBinder$Processor.bind(MethodDelegationBinder.java:1096)
```
关于ByteBuddy工具的使用场景就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

文章题目：ByteBuddy工具的使用场景有哪些？
本文URL：http://dzwzjz.com/article/jogeeo.html

大橙子网站建设，新征程启航

ByteBuddy工具的使用场景有哪些？

其他资讯