但是没有这样就结束，我继续对getResource的源码进行了跟进，由于能力有限，没有弄清楚getResource的原理。

最终留下了两个疑问：

1、如果追踪到getResource方法的最底层(也许是JVM层面)，它实现的原理是什么？

2、为何Resin中<class-loader>的配置会对getResource产生影响，但是对getResourceAsStream毫无影响(getResourceAsStream可是将获取路径委托给getResource的啊)。还是这里我理解或者使用错误了？

本来文章到这里就结束了，本来是想问问牛人的，但是这个问题引起了很多的好奇心，于是我又花了一两周做了下面的调查。

Resin中类加载器

在我了解的 ClassLoader 是在 com.caucho.loader包下，结构请看下图：

图1

图2

从上面两幅图中可以看出，图1是与Jdk有关联的，继承自java.net.URLClassLoader。DynamicClassLoader的注释是这样的：

/**
* Class	loader which checks for changes in class files and automatically
* picks up new jars.
*
* DynamicClassLoaders can be chained creating one virtual class loader.
* From the perspective of the JDK, it's all one classloader.  Internally,
* the class loader chain searches like a classpath.
*/

EnvironmentClassLoader又继承了DynamicClassLoader 。

图 2 应该是 Resin 本身的 ClassLoader ，其中 Loader 是一个抽象类，包含了各种子类类加载器。

从两幅图中是看不出 Resin 自身的 Loader 体系与继承自 JVM 的类加载器存在关系，那是不是他们就不存在某种关联呢？其实不是这样子的。请看下面 DynamicClassLoader 源码的片段：

// List of resource loaders
private ArrayList _loaders = new ArrayList();
private JarLoader _jarLoader;
private PathLoader _pathLoader;

清楚了吧，这两个Loader 分支通过组合的方式协作。

类加载器顺序

既然 Resin 标准的 Loader 及其子类以组合的方式嵌入到 DynamicClassLoader 中，那么在加载一个“资源”时， Loader 分支和 java.net.URLClassLoader 分支的先后顺序是什么样子的呢？

首先使用下面这段代码，将类加载器名称打印到控制台：

ClassLoader loader = PathServlet.class.getClassLoader();
while (loader != null) {
    System.out.println(loader.toString());
    loader = loader.getParent();
}

输出的结果为：

EnvironmentClassLoader[web-app:http://localhost:8080/Test]

EnvironmentClassLoader[web-app:http://localhost:8080]

EnvironmentClassLoader[cluster ]

EnvironmentClassLoader[]

[email protected]

[email protected]

额，没有任何一个Resin 的 Loader 被打印出来啊，对头，有就错了。下面就让我们看看 DynamicClassLoader 中 getResource 的源码来解答。

/**
* Gets the named resource
*
* @param name name of the resource
*/

public URL getResource(String name)
{
    if (_resourceCache == null) {
        long expireInterval = getDependencyCheckInterval();
        _resourceCache = new TimedCache(256, expireInterval);
    }

    URL url = _resourceCache.get(name);
    if (url == NULL_URL)
        return null;
    else if (url != null)
        return url;

    boolean isNormalJdkOrder = isNormalJdkOrder(name);

    if (isNormalJdkOrder) {
    url = getParentResource(name);
    if (url != null)
        return url;
    }

    ArrayList loaders = _loaders;
    for (int i = 0; loaders != null && i < loaders.size(); i++) {
        Loader loader = loaders.get(i);
        url = loader.getResource(name);

        if (url != null) {
            _resourceCache.put(name, url);
            return url;
        }

    }

    if (! isNormalJdkOrder) {
        url = getParentResource(name);
        if (url != null)
            return url;
    }

    _resourceCache.put(name, NULL_URL);
    return null;
}

代码不难懂，我画了一张流程图，不规范，凑合看下。

总结

boolean isNormalJdkOrder = isNormalJdkOrder(name);

这行代码控制着Resin 类加载的顺序，如果是常规的类加载顺序 ( 向上代理，原文： Returns true if the class loader should use the normal order, i.e. looking at the parents first.) ，则先 url = getParentResource(name)，后遍历_loaders。否则是按照先遍历_loaders 再 url = getParentResource(name)向上代理。

在我的调试经历中，一直都是先向上代理，后遍历_loaders 的顺序，未遇到第二种方式。

文字对先向上代理，后遍历的顺序做点儿说明：

1. 首先使用“最上层”的 [email protected] 加载name 资源，如果找到就返回 URL 否则返回 null
2. 程序返回到 [email protected] ，首先判断父类加载器返回的 url 是否为 null ，如果不为 null 则返回 url ，返回 null 。
3. EnvironmentClassLoader[]
4. 程序返回到 EnvironmentClassLoader[cluster ] 的getParentResource ，再返回到 getResource ，如果 url 不为 null ，则直接返回，否则遍历 ArrayList<Loader> loaders = _loaders;从各个loader 中加载 name ，如果加载成功，即不为 null ，则返回，否则继续遍历，直至遍历完成。
5. EnvironmentClassLoader[web-app:http://localhost:8080] 同4
6. EnvironmentClassLoader[web-app:http://localhost:8080/Test] 同4

OK ，完事儿，后续还有，准备好好写几篇。

本文同时发布于：

• http://www.oschina.net/question/129471_34225 。
• http://www.oschina.net/question/129471_35231#AnchorAnswer143898

（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）