并行类加载与OSGI类加载

这回来分析一下OSGI的类加载机制。

先说一下OSGI能解决什么问题吧。

记得在上家公司的时候，经常参与上线。上线一般都是增加了一些功能或者修改了一些功能，然后将所有的代码重新部署。过程中要将之前的服务关掉，而且不能让客户访问。虽然每回的夜宵都不错，但还是感觉这个过程很麻烦，很别扭。

为什么明明只修改了一部分代码，却都要重新来一遍。

OSGI架构里面，很重要的一个理念就是分模块(bundle)。如果你只是修改了一个模块，就可以只热替换这个模块，不影响其它模块。想想就很有吸引力。要实现这种功能，类加载的委派模型必须大改。像AppClassLoader --》ExtClassLoader --》BootstrapClassLoader这种固定的树形结构，明显不能扩展，不能实现需求。

OSGI的规范要求每个模块都有自己的类加载器，而模块之间的依赖关系，就形成了各个类加载器之间的委派关系。这种委派关系是动态的，是自由恋爱，而不是指腹为婚。。。。。。

当然，委派是要依据规则的。这也好理解啊，谈婚论嫁时，女方的家长肯定会问，有房吗、有车吗、有几块腹肌啊。哎，又扯远了。

当一个模块(bundle)的类加载器遇到需要加载某个类或查找某个资源的请求时，规则步骤如下：

1）如果在以java.*开头的package中，那么这个请求需要委派给父类加载器

2）如果在父类委派清单所列明的package中，还是委派给父类加载器

3）如果在import-package标记描述的package中，委派给导出这个包的bundle的类加载器

4）如果在require-bundle导入的一个或多个bundle的包中，就好安装require-bundle指定的bundle清单顺序逐一委派给对应bundle的类加载器

5 ）搜索bundle内部的classpath

6）搜索每个附加的fragment bundle的classpath

7）如果在某个bundle已经声明导出的package中，或者包含在已经声明导入（import-package或require-bundle）的package中，搜索终止

8）如果在某个使用dynamicimport-package声明导入的package中，尝试在运行时动态导入这个package

9）如果可以确定找到一个合适的完成动态导入的bundle，委派给该bundle的类加载器

上面这部分完全照抄周志明的著作《深入理解OSGI》。规则里面的父类加载器、bundle等概念，读者都可以从书中找到完整的讲解，我这里就不展开了。

根据这个规则，所有的bundle之间的类加载形成了错综复杂的网状结构，不再是一沉不变的单一的树状结构。

但是网状结构，会有一个致命的问题。在jdk1.6包括之前，ClassLoader的类加载方法是synchronized。

protected synchronized Class<?> loadClass(String name, boolean resolve)

我们想象一个场景：bundle A 和 bundle B 互相引用了对方的package。这样在A加载B的包时，A在自己的类加载器的loadClass方法中，会最终调用到B的类加载器的loadClass方法。也就是说，A首先锁住自己的类加载器，然后再去申请B的类加载器的锁；当B加载A的包时，正好相反。这样，在多线程下，就会产生死锁。你当然可以让所有的类加载过程在单线程里按串行的方式完成，安全是安全，但是效率太低。

由此，引出了本文的另一个主题---并行类加载。

synchronized方法锁住的是当前的对象，在这种情况下，调用loadClass方法去加载一个类的时候，锁住的是当前的类加载器，也就不能再用这个类加载器去加载别的类。效率太低，而且容易出现死锁。

于是设计jdk的大牛，对这种模式进行了改进。大牛就是大牛！！！

看看jdk1.6之后的loadClass方法：

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

synchronized移到了方法内的代码块中，也就是说不再是简单的锁定当前类加载器，而是锁定一个生成的对象。

那么这个充当锁的对象是如何生成的？

    protected Object getClassLoadingLock(String className) {
        Object lock = this;
        if (parallelLockMap != null) {
            Object newLock = new Object();
            lock = parallelLockMap.putIfAbsent(className, newLock);
            if (lock == null) {
                lock = newLock;
            }
        }
        return lock;
    }

parallelLockMap是一个ConcurrentHashMap，putIfAbsent(K, V)方法查看K和V是否已经对应，是的话返回V，否则就将K，V对应起来，返回null。

第一个if判断里面的逻辑，一目了然：对每个className关联一个锁，并将这个锁返回。也就是说，将锁的粒度缩小了。只要类名不同，加载的时候就是完全并行的。这与ConcurrentHashMap实现里面的分段锁，目的是一样的。

我这里有2个问题希望读者思考一下：

1）为什么不直接用className这个字符串充当锁对象  

2）为什么不是直接new一个Object对象返回，而是用一个map将className和锁对象缓存起来

上面的方法中还别有洞天，为什么要判断parallelLockMap是否为空，为什么还有可能返回this，返回this的话不就是又将当前类加载器锁住了吗。这里返回this，是为了向后兼容，因为以前的版本不支持并行。有疑问就看源码，

    // Maps class name to the corresponding lock object when the current
    // class loader is parallel capable.
    // Note: VM also uses this field to decide if the current class loader
    // is parallel capable and the appropriate lock object for class loading.
    private final ConcurrentHashMap<String, Object> parallelLockMap;



    private ClassLoader(Void unused, ClassLoader parent) {
        this.parent = parent;
        if (ParallelLoaders.isRegistered(this.getClass())) {
            parallelLockMap = new ConcurrentHashMap<>();
            package2certs = new ConcurrentHashMap<>();
            domains =
                Collections.synchronizedSet(new HashSet<ProtectionDomain>());
            assertionLock = new Object();
        } else {
            // no finer-grained lock; lock on the classloader instance
            parallelLockMap = null;
            package2certs = new Hashtable<>();
            domains = new HashSet<>();
            assertionLock = this;
        }
    }

可见，对于parallelLockMap的处理一开始就分成了2种逻辑：如果将当前类加载器注册为并行类加载器，就为其赋值；否则就一直为null。

ParallelLoaders是ClassLoader的内部类

    /**
     * Encapsulates the set of parallel capable loader types.
     */
    private static class ParallelLoaders {
        private ParallelLoaders() {}

        // the set of parallel capable loader types
        private static final Set<Class<? extends ClassLoader>> loaderTypes =
            Collections.newSetFromMap(
                new WeakHashMap<Class<? extends ClassLoader>, Boolean>());
        static {
            synchronized (loaderTypes) { loaderTypes.add(ClassLoader.class); }
        }

        /**
         * Registers the given class loader type as parallel capabale.
         * Returns {@code true} is successfully registered; {@code false} if
         * loader's super class is not registered.
         */
        static boolean register(Class<? extends ClassLoader> c) {
            synchronized (loaderTypes) {
                if (loaderTypes.contains(c.getSuperclass())) {
                    // register the class loader as parallel capable
                    // if and only if all of its super classes are.
                    // Note: given current classloading sequence, if
                    // the immediate super class is parallel capable,
                    // all the super classes higher up must be too.
                    loaderTypes.add(c);
                    return true;
                } else {
                    return false;
                }
            }
        }

        /**
         * Returns {@code true} if the given class loader type is
         * registered as parallel capable.
         */
        static boolean isRegistered(Class<? extends ClassLoader> c) {
            synchronized (loaderTypes) {
                return loaderTypes.contains(c);
            }
        }
    }

原来，一个类加载器想要成为一个并行类加载器，是需要自己注册的，看看注册方法

    @CallerSensitive
    protected static boolean registerAsParallelCapable() {
        Class<? extends ClassLoader> callerClass =
            Reflection.getCallerClass().asSubclass(ClassLoader.class);
        return ParallelLoaders.register(callerClass);
    }

最终还是调用了内部类的注册方法。源码在上面，可以看到，一个类加载器要想注册，它的父类必须已经注册了，也就是说从继承路径上的所有父类都必须是并行类加载器。而且一开始，就把ClassLoader这个类注册进去了。

我有个疑问，这里有父类的什么事呢，光注册自己这个类就好了呀。想了半天，还是不明白，是有关于安全吗？哎，大牛就是大牛，哈哈。读者如有明白的，请直言相告。

最后，来看看并行类加载在Tomcat上的应用。原本WebappClassLoader没有注册，只能串行加载类。后来，是阿里意识到了这个问题，解决方案被Tomcat采纳。

    static {
        // Register this base class loader as parallel capable on Java 7+ JREs
        Method getClassLoadingLockMethod = null;
        try {
            if (JreCompat.isJre7Available()) {
                final Method registerParallel =
                        ClassLoader.class.getDeclaredMethod("registerAsParallelCapable");
                AccessController.doPrivileged(new PrivilegedAction<Void>() {
                    @Override
                    public Void run() {
                        registerParallel.setAccessible(true);
                        return null;
                    }
                });
                registerParallel.invoke(null);
                getClassLoadingLockMethod =
                        ClassLoader.class.getDeclaredMethod("getClassLoadingLock", String.class);
            }
        } catch (Exception e) {
            // ignore
        }

这段代码出现在WebappClassLoader类的父类WebappClassLoaderBase里，通过反射调用了ClassLoader类的注册方法。

类的加载能够并行后，我们启动应用的时候，肯定会更快。