java多类加载器类冲突案例分析

众所周知,jvm类加载机制采用双亲委派机制。但在有些框架中,常常为了提供某种形式的“隔离和沙盒”,自定义一种称为ChildFirst的了类加载器,简单的说就是破坏了双亲委派,由自定义子类加载器优先加载类,而不是先委派给父加载器。由于同一个类可以在不同的类加载器中分别加载,使用ChildFirst机制,可以让类加载器形成一个“沙盒”,在程序中同时运行两个相同但不同版本的类。

但是,笔者遇到一个罕见的类加载冲突的案例,根因与ChildFirst机制有关。

起因

程序在flink平台上运行,将数据写入es,而某平台在开启了安全机制后,整个平台包括es都需要基于kerberos认证来访问。基于先验的结论,需要替换魔改的elasticsearch-rest-client,其中使用GSSAPI登录了kerberos,并基于SENGPO协议,通过http发送了类token,还有一个独立的线程对token进行刷新。由于是个private jar,在工程中使用非常不友好,所以考虑在打包job的时候用maven-shade-plugin排除原先依赖的elasticsearch-rest-clientelasticsearch-rest-highlevel-client,而将定制版jar放到flink/lib目录下。

报错

提交作业后,Task Manager报错退出如下:

java.lang.LinkageError: loader constraint violation: when resolving method "org.elasticsearch.client.RestClient.builder([Lorg/apache/http/HttpHost;)Lorg/elasticsearch/client/RestClientBuilder;" the class loader (instance of org/apache/flink/util/ChildFirstClassLoader) of the current class, org/apache/flink/streaming/connectors/elasticsearch6/Elasticsearch6ApiCallBridge, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for the method's defining class, org/elasticsearch/client/RestClient, have different Class objects for the type [Lorg/apache/http/HttpHost; used in the signature

错误描述的意思是:

org/apache/http/HttpHost同时在ChildFirstClassLoaderAppClassLoader中加载,在调用org.elasticsearch.client.RestClient.builder的时候传入org/apache/http/HttpHost实例的时候发现,方法签名(形参)中的类org/apache/http/HttpHost属于AppClassLoader,而实参的org/apache/http/HttpHost却属于ChildFirstClassLoader,造成了冲突。

下面这两篇文章可以参考一下:

https://www.cnblogs.com/deepnighttwo/archive/2011/08/31/2160990.html

https://bigzuo.github.io/2017/03/19/java-LinkageError-loader-constraint-violation-error/

原因分析

基于下面这些事实:

  1. job包中把HttpHost类打进去了。
  2. flink的tm进程启动的时候会将hadoop下的httpcore.x.x.x.jar加到classpath
  3. AppClassLoader负责加载classpath参数里面的类
  4. ChildFirstClassLoader负责加载job包中的类

事发代码

image.png

分析:

实参 httpHosts 是序列化到tm上的List,也是Elasticsearch6ApiCallBridge这个类(在job包中)的私有属性。这意味着实参 httpHosts的类 优先由 ChildFirstClassLoader加载,且基于事实1,ChildFirstClassLoader能加载到HttpHost

RestClient类位于elasticsearch-rest-client,即在flink/lib目录,由于我们打包的时候不会将elasticsearch-rest-client打进来,所以ChildFirstClassLoader无法加载到这个类,只能由AppClassLoader加载,而且由于事实2,AppClassLoader也能加载到HttpHost

这么一来,就会出现上面报错

解决方案

最初我们通过将flink改为parent-first,能解决。经过分析:这是因为ParentFirstClassLoader不会先从job包中加载HttpHost,转而由AppClassLoader加载HttpHost,这样就不会有冲突。

从上述根因分析,还有一个方案是将elasticsearch-rest-client等相关jar也打包到job里面,这样保证全部由ChildFirstClassLoader加载。不过这样引入private jar,造成了版本管理的混乱。

flink支持classloader.parent-first-patterns.additional,在child-first的前提下,对某些类做parent-first,实测配置有效,但由于类加载连带关系复杂,无法穷举,所以作罢。

你可能感兴趣的:(java多类加载器类冲突案例分析)