classloader的演进

Posted 2021-02-01 qfjavabd

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

　　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。

?