Java中隔离容器的实现

Kevin Lynx 2015-09-05 00:00

Java中隔离容器用于隔离各个依赖库环境,解决Jar包冲突问题。

问题

应用App依赖库LibA和LibB,而LibA和LibB又同时依赖LibBase,而LibA和LibB都是其他团队开发的,其中LibA发布了一个重要的修复版本,但是依赖LibBase v2.0,而LibB还没有升级版本,LibBase还不是兼容的,那么此时升级就会面临困难。在生产环境中这种情况往往更恶劣,可能是好几层的间接依赖关系。

隔离容器用于解决这种问题。它把LibA和LibB的环境完全隔离开来,LibBase即使类名完全相同也不互相冲突,使得LibA和LibB的升级互不影响。众所周知,Java中判定两个类是否相同,看的是类名和其对应的class loader,两者同时相同才表示相等。隔离容器正是利用这种特性实现的。

KContainer

这里我实现了一个demo,称为KContainer,源码见github kcontainer。这个container模仿了一些OSGI的东西,这里把LibA和LibB看成是两个bundle,bundle之间是互相隔离的,每个bundle有自己所依赖的第三方库,bundle之间的第三方库完全对外隐藏。bundle可以导出一些类给其他bundle用,bundle可以开启自己的服务。由于是个demo,我只实现关键的部分。

KContainer的目录结构类似:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.
|-- bundle
    |-- test1
        |-- test1.prop
        |-- classes
        |-- lib
            |-- a.jar
            |-- b.jar
    |-- test2
        |-- test2.prop
        |-- classes
|-- lib
    |-- kcontainer.jar
    |-- kcontainer.interface.jar

bundle目录存放了所有会被自动载入的bundle。每一个bundle都有一个配置文件bundle-name.prop,用于描述自己导出哪些类,例如:

1
2
init=com.codemacro.test.B
export-class=com.codemacro.test.Export; com.codemacro.test.Export2

init指定bundle启动时需要调用的类,用户可以在这个类里开启自己的服务;export-class描述需要导出的类列表。bundle之间的所有类都是隔离的,但export-class会被统一放置,作为所有bundle共享的类。后面会描述KContainer如何处理类加载问题,这也是隔离容器的主要内容。

bundle依赖的类可以直接以*.class文件存放到classes目录,也可以作为*.jar放到lib目录。作为extra pratice,我还会把*.jar中的jar解压同时作为类加载的路径。

KContainer本身可以作为一个framework被使用。为了示例,我写了一个入口类,加载启动完所有bundle后就退出了,这个仅作为例子,用不了生产。

隔离的核心实现

隔离的目的是分开各个bundle中的类。利用的语言特性包括:

  • class的区分由class name和载入其的class loader共同决定
  • 当在class A中使用了class B时,JVM默认会用class A的class loader去加载class B
  • class loader中的双亲委托机制
  • URLClassLoader会从指定的目录及*.jar中加载类

KContainer的主要任务,就是为bundle实现一个自定义的class loader。

当KContainer加载一个bundle时,在处理其export-class或init时,都是需要加载bundle中的类的。在这之前,我给每一个bundle关联一个独立的BundleClassLoader。然后用这个class loader去加载bundle中的类,利用class loader传递特性,使得一个bundle中的所有类都是由其关联的class loader加载的,从而实现bundle之间类隔离效果。

实现class loader时,是实现loadClass还是findClass?通过实现loadClass我们可以改变class loader的双亲委托模式,制定加载类的具体顺序。但我的目的仅仅是隔离bundle,想了下其实实现findClass就可以达成目的。关于loadClass和findClass的区别可以参考这里 (实现自己的类加载时,重写方法loadClass与findClass的区别)。简单来说,就是findClass只有在类确实找不到的情况下才会被调用,在此之前,loadClass默认都是走的双亲委托模式。

BundleClassLoader派生于URLClassLoader,默认的parent class loader就是system class loader(app class loader)。这使得KContainer中的bundle类加载有三层选择:自己的class path;其他bundle共享的classes;jvm的class path。通过实现findClass,在默认路径都无法加载到类时,才尝试bundle共享的class,优先级最低。

其实现大概为:

public class BundleClassLoader extends URLClassLoader {
  public BundleClassLoader(File home, SharedClassList sharedClasses) {
    // getClassPath将bundle目录下的classes和各个jar作为class path传给URLClassLoader
    super(getClassPath(home)); 
    this.sharedClasses = sharedClasses;
  }

  @Override
  protected Class<?> findClass(String name) throws ClassNotFoundException {
    logger.debug("try find class {}", name);
    Class<?> claz = null;
    try {
      claz = super.findClass(name);
    } catch (ClassNotFoundException e) {
      claz = null;
    }
    if (claz != null) {
      logger.debug("load from class path for {}", name);
      return claz;
    }
    claz = sharedClasses.get(name);
    if (claz != null) {
      logger.debug("load from shared class for {}", name);
      return claz;
    }
    logger.warn("not found class {}", name);
    throw new ClassNotFoundException(name);
  }
}

完整代码参看BundleClassLoader.java

创建bundle时,会为其创建自己的class loader,并使用这个class loader来载入export-class和init-class:

public static Bundle create(File home, String name, SharedClassList sharedClasses, 
      BundleConf conf) {
    BundleClassLoader loader = new BundleClassLoader(home, sharedClasses);
    List<String> exports = conf.getExportClassNames();
    if (exports != null) {
      logger.info("load exported classes for {}", name);
      loadExports(loader, sharedClasses, exports);
    }
    return new Bundle(name, conf.getInitClassName(), loader);
  }
  
  private static void loadExports(ClassLoader loader, SharedClassList sharedClasses,
      List<String> exports) {
      for (String claz_name: exports) {
        try {
          Class<?> claz = loader.loadClass(claz_name); // 载入class
          sharedClasses.put(claz_name, claz);
        } catch (ClassNotFoundException e) {
          logger.warn("load class {} failed", claz_name);
        }
      }
  }

以上。

扩展

扩展的地方有很多,例如支持导出package,导出一个完整的jar。当然可能需要实现loadClass,以改变类加载的优先级,让共享类的优先级高于jvm class path的优先级。

其他

线程ContextClassLoader

提到class loader,我们看下最常接触的几类:

  • XX.class.getClassLoader,获取加载类XX的class loader
  • Thread.currentThread().getContextClassLoader(),获取当前线程的ContextClassLoader
  • ClassLoader.getSystemClassLoader(),获取system class loader

system class loader的parent就是ext class loader,再上面就是bootstrap class loader了 (不是java类,实际获取不到)。默认情况下以上三个class loader都是一个:

System.out.println(ClassLoader.getSystemClassLoader());
System.out.println(Main.class.getClassLoader());
System.out.println(Thread.currentThread().getContextClassLoader());

Output:

1
2
3
sun.misc.Launcher$AppClassLoader@157c2bd
sun.misc.Launcher$AppClassLoader@157c2bd
sun.misc.Launcher$AppClassLoader@157c2bd

创建线程时,新的线程ContextClassLoader就是父线程的ContextClassLoader。在载入一个新的class时,推荐优先使用线程context class loader,例如框架Jodd中包装的。关于线程context class loader和Class.getClassLoader这里有个解释算是相对合理:ContextClassLoader浅析

即,当你把一个对象A传递到另一个线程中,这个线程由对象B创建,A/B两个对象对应的类关联的class loader不同,在B的线程中调用A.some_method,some_method加载资源或类时,如果使用了Class.getClassLoader或Class.forName时,实际使用的是A的class loader,而这个行为可能不是预期的。这个时候就需要将代码改为Thread.currentThread().getContextClassLoader()。

完。

原文地址:http://codemacro.com/2015/09/05/java-lightweight-container/
written byKevin Lynx posted athttp://codemacro.com

[返回] [原文链接]