类加载器中的 Java 死锁

Question

我编写了两个自定义类加载器来动态加载代码。

第一个从 Jar 中加载代码:

package com.customweb.build.bean.include;

import java.net.URL;
import java.net.URLClassLoader;

import com.customweb.build.process.ILeafClassLoader;

public class JarClassLoader extends URLClassLoader implements ILeafClassLoader {

    public JarClassLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
    }

    @Override
    public Class<?> findClassWithoutCycles(String name) throws ClassNotFoundException {

        Class<?> c = findLoadedClass(name);
        if (c != null) {
            return c;
        }

        return findClass(name);
    }

    @Override
    protected Class<?> findClass(String qualifiedClassName) throws ClassNotFoundException {
        synchronized (this.getParent()) {
            synchronized (this) {
                return super.findClass(qualifiedClassName);
            }
        }
    }

    @Override
    public URL findResourceWithoutCycles(String name) {
        return super.findResource(name);
    }

    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        synchronized (this.getParent()) {
            synchronized (this) {
                return super.loadClass(name);
            }
        }
    }

}

另一个类加载器采用多个类加载器以允许访问其他类加载器的类。在第一个初始化期间，我将此类加载器的一个实例设置为父级。为了打破循环，我使用方法“findClassWithoutCycles”。

package com.customweb.build.process;

import java.net.URL;
import java.security.SecureClassLoader;
import java.util.ArrayList;
import java.util.List;

public class MultiClassLoader extends SecureClassLoader {

    private final List<ClassLoader> classLoaders = new ArrayList<ClassLoader>();

    public MultiClassLoader(ClassLoader parent) {
        super(parent);
    }

    public void addClassLoader(ClassLoader loader) {
        this.classLoaders.add(loader);
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {

        for (ClassLoader loader : classLoaders) {
            try {
                if (loader instanceof ILeafClassLoader) {
                    return ((ILeafClassLoader) loader).findClassWithoutCycles(name);
                } else {
                    return loader.loadClass(name);
                }
            } catch (ClassNotFoundException e) {
                // Ignore it, we try the next class loader.
            }
        }

        throw new ClassNotFoundException(name);
    }

    @Override
    protected URL findResource(String name) {

        for (ClassLoader loader : classLoaders) {
            URL url = null;
            if (loader instanceof ILeafClassLoader) {
                url = ((ILeafClassLoader) loader).findResourceWithoutCycles(name);
            } else {
                url = loader.getResource(name);
            }

            if (url != null) {
                return url;
            }
        }

        return null;
    }
}

但是当我使用此类加载器时，大多数时候我都会遇到死锁。我已经经过这里的线程转储: http://pastebin.com/6wZKv4Y0

由于 Java ClassLoader 在某些方法中通过在 $this 上同步来阻塞线程，我尝试先在 MultiClassLoader 上同步，然后在 JarClassLoader 上同步。当获取锁的顺序相同时，这应该可以防止任何死锁。但似乎在 native 类加载例程的某个地方获取了对类加载器的锁定。我得出这个结论是因为线程“pool-2-thread-8”被锁定在对象“0x00000007b0f7f710”上。但是在日志中我看不到这个锁是什么时候被哪个线程获取的。

如何找出哪个线程在类加载器上进行同步？

编辑:我通过在调用 MultiClassLoader 的 loadClass 之前同步所有类加载器来解决这个问题。

Answer 1

JVM 在调用 loadClass 之前获取 ClassLoader 上的锁。如果通过您的 JarClassLoader 之一加载的类引用另一个类并且 JVM 尝试解析该引用，则会发生这种情况。它将直接转到创建该类的 ClassLoader，锁定它并调用 loadClass。但是随后您试图在再次锁定 JarClassLoader 之前锁定父加载器。所以这两个锁的顺序是行不通的。

但是我看不出这两个锁中任何一个的原因，因为您不访问任何需要同步的资源。 URLClassLoader 的继承内部状态由其实现本身维护。

但是，如果您想向需要同步的类添加更多状态，您应该使用不同的机制来锁定 ClassLoader 实例。

http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html说

If you have a custom class loader with a risk of deadlocking, with the Java SE 7 release, you can avoid deadlocks by following these rules:

1. Ensure that your custom class loader is multithread safe for concurrent class loading.

   a. Decide upon an internal locking scheme. For example, java.lang.ClassLoader uses a locking scheme based on the requested class name.

   b. Remove all synchronization on the class loader object lock alone.

   c. Ensure that critical sections are safe for multiple threads loading different classes.

2. In your custom class loader's static initializer, invoke java.lang.ClassLoader's static method registerAsParallelCapable(). This registration indicates that all instances of your custom class loader are multithread safe.

3. Check that all class loader classes that this custom class loader extends also invoke the registerAsParallelCapable() method in their class initializers. Ensure that they are multithread safe for concurrent class loading.

If your custom class loader overrides only findClass(String), you do not need further changes. This is the recommended mechanism to create a custom class loader.