拜托,别在 agent 中依赖 fastjson 了

ilikevc
发布于 2023-8-25 16:04
浏览
0收藏

一、背景

最近因为增加了一个在 agent 中上报异常的功能,agent 为了在 http 请求时方便把对象转换为 json 格式,增加了一个 fastjson 的依赖,结果搞出来各种问题。

环境:

  • JDK 1.8
  • SpringBoot 2.0.0.RELEASE
  • skywalking agent 8.14.0

二、初现问题

2.1 初步定位

有同事反馈应用在本地能启动,但是到了测试环境(带 agent 启动)就起不来,报错如下:

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

首先还是要确认下是不是应用的依赖冲突问题,​​GenericHttpMessageConverter​​这个类是在 spring-web 这个包下面的, 因为本地打包环境和测试环境有可能不一致,需要确认最终部署到测试环境的包里是否包含了 spring-web 包。经确认包里有 spring-web,排除这个可能。

然后怀疑是 agent 和应用的依赖冲突,临时让这个应用的 agent 下线后重新部署,发现能正常启动,基本确认是 agent 带来的问题。

2.2 进一步排查

为了方便定位问题,我把发现问题时应用部署的包下载到本地,并在本地挂载 agent 启动,问题重现,报错和测试环境一致。至此我就可以在本地 debug 了。

顺便说一下,我一开始用 idea 启动应用(挂载 agent)是没问题的,至于为什么没问题下面会说到。

本地我在​​java.net.URLClassLoader#findClass​​​方法的入口处打了一个条件断点(类名为​​GenericHttpMessageConverter​​的才会进来),启动应用后一会儿进入断点。

idea 这个工具就是好用,从 debug 界面一下子就能看出来,这个 findClass 是调用了 3 次,并且能看到每一次 findClass 是加载的哪个类:

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

从上面的图的最后一行也能看出来,这个类加载最开始的触发是在内部的一个二方库的类​​WebAutoConfig​​中触发的。

这 3 次 findClass 的顺序可以看出, 类的加载顺序为:

BootMessageConverter (二方包)

-> FastJsonHttpMessageConverter (fastjson)

-> GenericHttpMessageConverter (spring-web)

再来看看​​WebAutoConfig​​触发类加载的那段代码:

@Configuration
public class WebAutoConfig implements WebMvcConfigurer {
  
  @Bean
    @ConditionalOnMissingBean
    public HttpMessageConverters httpMessageConverter(){
        BootMessageConverter converter = new BootMessageConverter(); //这一行触发了类加载
    ...
    }
}

public class BootMessageConverter extends FastJsonHttpMessageConverter {
 ...
}

public class FastJsonHttpMessageConverter extends AbstractHttpMessageConverter<Object>
        implements GenericHttpMessageConverter<Object> {
 ...        
}

从上面的代码能看出最开始是因为​​BootMessageConverter​​​的实例化进行了类加载, 而​​BootMessageConverter​​​因为继承了​​FastJsonHttpMessageConverter​​​, 又接着触发了​​FastJsonHttpMessageConverter​​​的类加载, 然后​​FastJsonHttpMessageConverter​​​因为实现了​​GenericHttpMessageConverter​​​接口, 又进一步触发了​​GenericHttpMessageConverter​​的类加载, 这样来看源码和上面 debug 得出的结论是一致的。

分析到这一步,如果你对类加载机制以及 agent 的运行方式非常熟悉的话,基本已经能得出“为什么会报​​GenericHttpMessageConverter​​类找不到的错误”结论了。

那么接下来,我会基于类加载的机制来详细分析一下,为什么会找不到​​GenericHttpMessageConverter​

三、类加载机制

3.1 双亲委派机制

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

上一层类加载器是下一层类加载器的父加载器,除了 Bootstrap ClassLoader 之外,所有的加载器都是有父加载器的。

所谓的双亲委派机制,指的就是:当一个类加载器收到了类加载的请求的时候,他不会直接去加载指定的类,而是把这个请求委托给自己的父加载器去加载。只有父加载器无法加载这个类的时候,才会由当前这个加载器来负责类的加载。

开个玩笑:这样说来,双亲委派这种说法似乎并不准确,因为有父无母,准确来说应该是“单亲委派”...

3.1.1 类中依赖的其他类是怎么加载的

----------------接下来是重点----------------

我们定义的类一般还会依赖其他类,因此在被类加载器加载时,类加载机制中除了双亲委派机制之外,还有一个重要的机制是:

假设类 A 依赖类 B,那么哪个 ClassLoader 找到了类 A,这个 ClassLoader 也会尝试去加载类 B(当然类 B 的加载过程也遵循双亲委派)。

3.2 springboot 的类加载机制

springboot 项目打包之后的 jar 目录结构如下:

├─BOOT-INF
│  ├─classes
│  │  ├─应用代码
│  └─lib
│     ├─应用依赖的jar包
├─META-INF
│  ├─MANIFEST.MF
└─org
    └─springframework
        └─boot
            └─loader
                │  JarLauncher.class
                │  LaunchedURLClassLoader.class
                │  Launcher.class
                │  ...

其中/META-INF/MANIFEST.MF 是 jar 包运行的关键, 来看一下里面的内容:

...

Main-Class: org.springframework.boot.loader.JarLauncher

Start-Class: com.xxxxxx.DemoApplication

Spring-Boot-Classes: BOOT-INF/classes/

Spring-Boot-Lib: BOOT-INF/lib/

...

首先 jar 包运行都有一个入口类定义了 main 方法,可以看到 springboot 项目打包出来的 jar 定义的入口运行类并不是应用代码中的​​XxxApplication​​​,而是 springboot 中的一个类​​JarLauncher​​​,那么应用代码中的​​XxxApplication​​是怎么运行的呢?

当你运行 java -jar 命令的时候,​​JarLauncher​​会加载 /BOOT-INF/classes 下的类和 /BOOT-INF/lib 下的 jar 包。最后调用 MANIFEST.MF 文件的 Start-Class 属性指定的类的 main 方法来完成应用程序的启动。

问题是 /BOOT-INF/ 并不是标准的 classpath 路径,系统内置的 ClassLoader 是加载不到这些目录的类的,那么这些类是谁来加载的呢?答案就是 springboot 自定义的类加载器:​​LaunchedURLClassLoader​

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

也就是说应用代码中的类以及应用依赖的 jar 都是​​LaunchedURLClassLoader​​负责加载的。

3.3 fastjson 的类到底是怎么找到的

再说回来在第 2.2 节中说到的类加载顺序:

BootMessageConverter (二方包)

-> FastJsonHttpMessageConverter (fastjson)

-> GenericHttpMessageConverter (spring-web)

这里我们重点来分析一下中间那个​​FastJsonHttpMessageConverter​​到底是怎么被加载的。

已知应用依赖了 fastjson 和 spring-web,agent 也依赖了 fastjson 但不依赖 spring-web。

从 Oracle 官方的文档看到,Java 8 的 agent 的 jar 包里的类会添加到 classpath 中,因此会用​​AppClassLoader​​来加载。

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

而二方包的​BootMessageConverter​是应用依赖的 jar, 放在/BOOT-INF/lib 下, 因此是被​LaunchedURLClassLoader​加载的。整体类加载流程如下图:

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

上图说明:

当​​BootMessageConverter​​​被​​LaunchedURLClassLoader​​​加载时, 发现依赖了​​FastJsonHttpMessageConverter​​​, 因此​​LaunchedURLClassLoader​​​会继续尝试去加载​​FastJsonHttpMessageConverter​​​。由于类加载的双亲委派机制,​​LaunchedURLClassLoader​​​会委派它的父加载器​​AppClassLoader​​​来尝试加载,当然​​AppClassLoader​​​会继续往上找父加载器,一直到​​Bootstrap ClassLoader​​。

很显然,​​Bootstrap ClassLoader​​​和​​ExtClassLoader​​​都无法找到​​FastJsonHttpMessageConverter​​​,但是​​AppClassLoader​​​可以找到(因为 agent 包中存在 fastjson 的类)。然后,这一步是关键,​​AppClassLoader​​​找到了​​FastJsonHttpMessageConverter​​​之后发现它依赖了​​GenericHttpMessageConverter​​​,因此由找到了​​FastJsonHttpMessageConverter​​​的​​AppClassLoader​​​继续尝试加载​​GenericHttpMessageConverter​​​,但是​​GenericHttpMessageConverter​​​只有应用依赖的 spring-web.jar 中才有,而这个 jar 在/BOOT-INF/lib 下,只能被​​LaunchedURLClassLoader​​​加载。双亲委派机制只能由子加载器往父加载器委托而反过来是不行的,而​​GenericHttpMessageConverter​​​没办法被​​AppClassLoader​​​以及它的父加载器加载到,因此​​AppClassLoader​​​抛出了找不到​​GenericHttpMessageConverter​​的错误。

----------------划重点----------------

这里的关键就在于​​LaunchedURLClassLoader​​​本身是能找到 fastjson 类的(在/BOOT-INF/lib), 但是因为双亲委派机制, 在加载 fastjson 类的时候, 被​​AppClassLoader​​截胡了,以至于丧失了后面依赖的类加载主动权。

说到这里,就可以回答之前的那个问题了:为什么用 idea 启动应用(挂载 agent)是没问题的?因为 idea 是直接运行应用的 XxxApplication 类的 main 方法,不是通过 springboot 的​​JarLauncher​​​启动的,而在运行时所有的依赖都是通过指定 classpath 来做的,因此 idea 运行过程中,所有的类都能通过​​AppClassLoader​​加载到,也就不存在上面这种冲突问题了。

四、解决方案一:maven-shade-plugin

知道问题的根因了,那么思路就是怎么样可以让 fastjson 类被​​LaunchedURLClassLoader​​​找到而不要被​​AppClassLoader​​找到。这里的思路是把 agent 中依赖的 fastjson 的 package 给重命名一下。

maven-shade-plugin在 maven 官方网站中提供的一个插件,官方文档中定义其功能如下:

This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.

简单来说就是将依赖的包在 package 阶段一起打入 jar 包中,以及对依赖的 jar 包进行重命名从而达到隔离的作用。接下来就把这个 maven 插件引入 agent 中。

maven 配置:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.2.1</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <shadedArtifactAttached>false</shadedArtifactAttached>
                <createDependencyReducedPom>true</createDependencyReducedPom>
                <createSourcesJar>true</createSourcesJar>
                <shadeSourcesContent>true</shadeSourcesContent>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <manifestEntries>
                            <Premain-Class>xxxxxx.AgentStarter</Premain-Class>
                            <Can-Redefine-Classes>true</Can-Redefine-Classes>
                            <Can-Retransform-Classes>true</Can-Retransform-Classes>
                        </manifestEntries>
                    </transformer>
                </transformers>
                <!-- 这段是package重命名的关键配置 -->
                <relocations>
                    <relocation>
                        <pattern>com.alibaba.fastjson</pattern>
                        <shadedPattern>shade.com.alibaba.fastjson</shadedPattern>
                    </relocation>
                </relocations>
            </configuration>
        </execution>
    </executions>
</plugin>

package 之后的效果:

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

可以看到在 agent 包中,fastjson 类的 package 都已经加上了一个前缀​​shade.​​​,这样的话,应用中加载正常的 fastjson 类的时候,肯定不会找到 agent 里面来了,以此避免了类加载被​​AppClassLoader​​截胡的情况。

用重新 package 的 agent 包启动之前应用, 应用正常启动, 至此问题解决。

五、再现问题

本以为问题已经解决,没想到几天后另一个应用又报了类找不到的错误:

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

有了上次的经验, 这次还算顺利, 排查过程跟上次的差不多。

最后发现是应用依赖的 jersey 这个三方库,而 jersey 通过 SPI 的方式会去找所有 classpath 中\META-INF\services\目录下的​​javax.ws.rs.ext.MessageBodyReader​​​这个文件,由于 agent 依赖了 fastjson,而 fastjson 也实现了这个 SPI 的扩展,结果 jersey 就找到了 agent 包的\META-INF\services\目录下的​​javax.ws.rs.ext.MessageBodyReader​​​文件,而​​javax.ws.rs.ext.MessageBodyReader​​文件中的内容如下:

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

可以看到 maven-shade-plugin 把这里的类 package 也改掉了。然后 jersey 读取到这个文件后,根据类名去加载了​​shade.com.alibaba.fastjson.support.jaxrs.FastJsonProvider​​​这个类,结果肯定是找到了 agent 包里的这个类,而这个类依赖的​​MessageBodyReader​​类是在 jsr311-api.jar 里的, 这个 jar 包只在应用中依赖, agent 并不依赖这个 jar 包, 因此就抛出了找不到类的错误。

依赖冲突真是让人防不胜防~

六、决定:干掉 fastjson

本来我查了下 maven-shade-plugin 似乎是可以在 agent 打包时把\META-INF\services\这个目录排除掉的,这样的话上面的问题也能解决掉,但是连续两次踩了这个坑还是让我静下来好好思考了一下。

这两次的依赖冲突从根本上来看,都是因为 fastjson 做的太重,第一次是因为 fastjson 依赖了 spring,第二次是因为 fastjson 实现了 jsr311-api,而在 agent 中去依赖 fastjson 并没有那么多的需求,只是为了做一个纯粹的转换工作:Java 对象和 Json 串之间的互相转换。所以找一个纯粹的轻量级的 Json 转换库是我的本质需求。否则 fastjson 下次可能又遇到其他的依赖冲突问题,我还得改。

如何考量是否轻量级呢?我主要从两方面着手:

  1. 看这个三方库的 pom.xml 中有没有依赖其他三方库
  2. 看这个三方库的\META-INF\services\目录有没有多余的 SPI 实现

最终我选择了 Google 的 gson 作为 agent 依赖的 Json 转换库。

拜托,别在 agent 中依赖 fastjson 了-鸿蒙开发者社区

可以看到 fastjson 的“罪行”可谓罄竹难书,而 gson 除了 junit 之外没有任何依赖,且 gson 不存在\META-INF\services\目录,完全满足我的需求。

顺便给 fastjson 也提个建议:目前的包耦合这么严重,是不是可以考虑拆成多个,比如 fastjson-core,fastjson-spring 等,让使用者按需依赖是不是更好呢。

七、总结

  1. 在 agent 研发中尽量用 JDK 内置的类去做功能,减少第三方库的依赖。
  2. 如果依赖了第三方库,可以用 maven-shade-plugin 来进行 package 重命名,以此达到和应用依赖类的隔离效果。
  3. 小心 SPI 机制,agent 依赖第三方库后,需要确认\META-INF\services\目录下的内容,如有必要可以进行排除或换成其他干净的依赖。

最后感谢能抽空看到这里,如果你能​​点赞​​​、​​在看​​​、​​分享​​,我会更加感激不尽~


文章转载自公众号:捉虫大师

分类
标签
已于2023-8-25 16:04:07修改
1
收藏
回复
举报
1条回复
按时间正序
/
按时间倒序
wx6659a4bbd5a65
wx6659a4bbd5a65

大佬太NB了,学习了

回复
2024-5-31 18:22:46
回复
    相关推荐