classloader的演进

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

classloader从1.6到1.7整体分成了两个版本。重点区别就是并行类加载。

1.6版本

    protected synchronized Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        ……
        return c;
    }


1.6版本加了一个方法锁。

1.7版本

  private final ConcurrentHashMap parallelLockMap;

    protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            ……
            return c;
        }
    }

    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;
    }

1.7之后就是用了两种模式getClassLoadingLock方法中,我们可以看出有两种模式,一种是parallelLockMap为空,锁的对象是classloader本身,另外一种是parallelLockMap不为null。这里会根据classname去获取锁,如果有返回的object不为null。说明已经有class使用过了,如果为null,就把新建的object当做锁,达到了一个classname一个锁的效果。

classloader加锁的原因

有很多classloader的例子直接复写了loadClass但是没有加锁,只有读取文件加载的过程,这种classloader都是特定场合使用的。并不具备通用性。众所周知的一个规则,一个classloader不能加载相同类的字节码,第二次加载就会在defineclass的时候报错。
场景1
不同的线程可以是相同的classloader,两个线程的都是A classloader加载的,当里面的有个方法里都有B类时,两个线程都会触发A加载B类
场景2
双亲委托的情况,A loader是B loader的parent。A能加载到C类。B loader加载c的时候委托给A,A也在同时加载C。此时触发了两次A加载C。

锁分离的好处

锁分离加快了并发,这个是显而易见的。还有一个好处是减少了死锁。在编写javaagent的时候,只要在transform加点锁,特别容易和classloader还有类初始化时候的锁造成死锁。基本死锁的场景都在1.6。


原文始发于微信公众号(一次编译多处运行):classloader的演进