ClassLoader专题

 

（一）：ClassLoader基础

JVM启动，会形成3个类加载器组成的初始化加载器层次结构：
bootstap classloader （加载核心类）
        ||
extension classloader（加载ext(目录)，即java.ext.dirs()）
        ||
system classloader   （加载-classpath或者java.class.path或者CLASSPATH）

ClassLoader机制：
a）全盘负责：一个classloader加载一个class后，这个class所引用或者依赖的类也由这个classloader载入，除非显示的用另一个classloader载入
b）委托机制：先由父加载器加载，除非父加载器找不到时才从自己的类路径中去寻找
c）Cache机制：classloader采用缓存机制，即先查cache；若cache中保存了这个class就直接返回；若无，才从文件读取和转化为class并放入cache

 

ClassLoader加载类顺序：
1）检查cache是否有该类：
    11）若有直接返回
    12）若无，请求父类加载
    　　　　121) 若无父,则从bootstap classloader加载
2）加载：
    21）寻找class文件（丛与此classloader相关的类路径中寻找）
    22）从文件载入class
    23）找不到则抛出ClassNotFoundeException
3）扩展：
    记载时即2），覆写findClass可以实现自己的载入策略
    记载时即2），覆写loadClass来实现自己的载入过程

如何实现运行时动态载入与更新
本质：只要动态改类搜索路径和清除classloader的cache已载入的class就ok
做法：
1）继承ClassLoader：覆写loadClass方法，动态寻找class文件
2）只要重新使用一个新的类搜索路径来new一个classloader就可以，这样既更新了类的搜索路径以便来载入新的class，也更新生成了一个空白的cache

classloader载入的方式
1）Pre-loading 预先载入，载入基础类
2）load-on-demand 按需求载入

JDK为啥有两个JRE？
JDK中jre是运行java本身的程序，如javac
ProgramFile（默认安装）中jre是运行用户编写的java程序

(2) 从 Servlet 容器看 ClassLoader 机制的妙用

classloader有啥妙用（1）？
这个问题得从自定义的classloader身上说，那自定义classloader缘由是什么呢？
告诉你：大多是因为编译时无法预知运行时需要哪些类，特别是app server；因此自定义classloader，运行时指定路径，来加载这个路径下的class

特殊说明
特殊说明1：如果没有特殊指定，用户自定义的classloader都把system classloader作为它的父加载器
特殊说明2：jvm认为不同的classloade载入相同名字的class是不同的，即使从同一个class文件载入

classloader有啥妙用（2）？
看到特殊说明2，你或许就会感觉疑惑或者不爽；啥概念？
以servlet、ejb等容器来剖析这个问题：

将接口或者基类放入classpath                         <---------system classloader
执行时，动态载入实现或者继承这些接口或者基类的子类；<---------customized classloader
         ||
         ||
用customized classloader载入类时，发现它有一个父类class（extends）；
但是在载入它时，jvm先加载父类class； 这个父类是system classloader能识别的； 根据“委托机制”它将由system classloader来加载；
然后customized classloader（实际是system classloader来加载）再载入这个class,创建一个实例，转型为父类；
jvm就使用system classloader再次载入父类class，然后将此实例转型为这个父类class；

这个过程加载了两个父类class，都是由system classloader载入；即同一个classloader载入同一个文件，造型不会由异常

web app server大概是这样工作的；这样载入了任何继承了servlet的class并正确运行它们，不管class是什么，都它们实例化为一个servlet class.

何时使用Thread.getContextClassLoader()?

    这是一个很常见的问题，但答案却很难回答。这个问题通常在需要动态加载类和资源的系统编程时会遇到。总的说来动态加载资源时，往往需要从三种类加载器里选择：系统或说程序的类加载器、当前类加载器、以及当前线程的上下文类加载器。在程序中应该使用何种类加载器呢？

    系统类加载器通常不会使用。此类加载器处理启动应用程序时classpath指定的类，可以通过ClassLoader.getSystemClassLoader()来获得。所有的ClassLoader.getSystemXXX()接口也是通过这个类加载器加载的。一般不要显式调用这些方法，应该让其他类加载器代理到系统类加载器上。由于系统类加载器是JVM最后创建的类加载器，这样代码只会适应于简单命令行启动的程序。一旦代码移植到EJB、Web应用或者Java Web Start应用程序中，程序肯定不能正确执行。

    因此一般只有两种选择，当前类加载器和线程上下文类加载器。当前类加载器是指当前方法所在类的加载器。这个类加载器是运行时类解析使用的加载器，Class.forName(String)和Class.getResource(String)也使用该类加载器。代码中X.class的写法使用的类加载器也是这个类加载器。

    线程上下文类加载器在Java 2(J2SE)时引入。每个线程都有一个关联的上下文类加载器。如果你使用new Thread()方式生成新的线程，新线程将继承其父线程的上下文类加载器。如果程序对线程上下文类加载器没有任何改动的话，程序中所有的线程将都使用系统类加载器作为上下文类加载器。Web应用和Java企业级应用中，应用服务器经常要使用复杂的类加载器结构来实现JNDI（Java命名和目录接口)、线程池、组件热部署等功能，因此理解这一点尤其重要。

    为什么要引入线程的上下文类加载器？将它引入J2SE并不是纯粹的噱头，由于Sun没有提供充分的文档解释说明这一点，这使许多开发者很糊涂。实际上，上下文类加载器为同样在J2SE中引入的类加载代理机制提供了后门。通常JVM中的类加载器是按照层次结构组织的，目的是每个类加载器（除了启动整个JVM的原初类加载器）都有一个父类加载器。当类加载请求到来时，类加载器通常首先将请求代理给父类加载器。只有当父类加载器失败后，它才试图按照自己的算法查找并定义当前类。

    有时这种模式并不能总是奏效。这通常发生在JVM核心代码必须动态加载由应用程序动态提供的资源时。拿JNDI为例，它的核心是由JRE核心类(rt.jar)实现的。但这些核心JNDI类必须能加载由第三方厂商提供的JNDI实现。这种情况下调用父类加载器（原初类加载器）来加载只有其子类加载器可见的类，这种代理机制就会失效。解决办法就是让核心JNDI类使用线程上下文类加载器，从而有效的打通类加载器层次结构，逆着代理机制的方向使用类加载器。

    顺便提一下，XML解析API(JAXP)也是使用此种机制。当JAXP还是J2SE扩展时，XML解析器使用当前类加载器方法来加载解析器实现。但当JAXP成为J2SE核心代码后，类加载机制就换成了使用线程上下文加载器，这和JNDI的原因相似。

    好了，现在我们明白了问题的关键：这两种选择不可能适应所有情况。一些人认为线程上下文类加载器应成为新的标准。但这在不同JVM线程共享数据来沟通时，就会使类加载器的结构乱七八糟。除非所有线程都使用同一个上下文类加载器。而且，使用当前类加载器已成为缺省规则，它们广泛应用在类声明、Class.forName等情景中。即使你想尽可能只使用上下文类加载器，总是有这样那样的代码不是你所能控制的。这些代码都使用代理到当前类加载器的模式。混杂使用代理模式是很危险的。

    更为糟糕的是，某些应用服务器将当前类加载器和上下文类加器分别设置成不同的ClassLoader实例。虽然它们拥有相同的类路径，但是它们之间并不存在父子代理关系。想想这为什么可怕：记住加载并定义某个类的类加载器是虚拟机内部标识该类的组成部分，如果当前类加载器加载类X并接着执行它，如JNDI查找类型为Y的数据，上下文类加载器能够加载并定义Y，这个Y的定义和当前类加载器加载的相同名称的类就不是同一个，使用隐式类型转换就会造成异常。

     这种混乱的状况还将在Java中存在很长时间。在J2SE中还包括以下的功能使用不同的类加载器：

    * JNDI使用线程上下文类加载器

    * Class.getResource()和Class.forName()使用当前类加载器

    * JAXP使用上下文类加载器

    * java.util.ResourceBundle使用调用者的当前类加载器

    * URL协议处理器使用java.protocol.handler.pkgs系统属性并只使用系统类加载器。

    * Java序列化API缺省使用调用者当前的类加载器

    这些类加载器非常混乱，没有在J2SE文档中给以清晰明确的说明。

原文地址：

http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html?page=1

public abstract class ClassLoaderResolver
{
    /**
     * This method selects the best classloader instance to be used for
     * class/resource loading by whoever calls this method. The decision
     * typically involves choosing between the caller's current, thread context,
     * system, and other classloaders in the JVM and is made by the {@link IClassLoadStrategy}
     * instance established by the last call to {@link #setStrategy}.
     * 
     * @return classloader to be used by the caller ['null' indicates the
     * primordial loader]   
     */
    public static synchronized ClassLoader getClassLoader ()
    {
        final Class caller = getCallerClass (0);
        final ClassLoadContext ctx = new ClassLoadContext (caller);
        
        return s_strategy.getClassLoader (ctx); 
    }
    public static synchronized IClassLoadStrategy getStrategy ()
    {
        return s_strategy;
    }
    public static synchronized IClassLoadStrategy setStrategy (final IClassLoadStrategy strategy)
    {
        final IClassLoadStrategy old = s_strategy;
        s_strategy = strategy;
        
        return old;
    }
        
    /**
     * A helper class to get the call context. It subclasses SecurityManager
     * to make getClassContext() accessible. An instance of CallerResolver
     * only needs to be created, not installed as an actual security
     * manager.
     */
    private static final class CallerResolver extends SecurityManager
    {
        protected Class [] getClassContext ()
        {
            return super.getClassContext ();
        }
        
    } // End of nested class 
    
    
    /*
     * Indexes into the current method call context with a given
     * offset.
     */
    private static Class getCallerClass (final int callerOffset)
    {        
        return CALLER_RESOLVER.getClassContext () [CALL_CONTEXT_OFFSET +
            callerOffset];
    }
    
    private static IClassLoadStrategy s_strategy; // initialized in <clinit>
    
    private static final int CALL_CONTEXT_OFFSET = 3; // may need to change if this class is redesigned
    private static final CallerResolver CALLER_RESOLVER; // set in <clinit>
    
    static
    {
        try
        {
            // This can fail if the current SecurityManager does not allow
            // RuntimePermission ("createSecurityManager"):
            
            CALLER_RESOLVER = new CallerResolver ();
        }
        catch (SecurityException se)
        {
            throw new RuntimeException ("ClassLoaderResolver: could not create CallerResolver: " + se);
        }
        
        s_strategy = new DefaultClassLoadStrategy ();
    }
} // End of class.

You acquire a classloader reference by calling the ClassLoaderResolver.getClassLoader() static method and use the result to load classes and resources via the normal java.lang.ClassLoader API. Alternatively, you can use this ResourceLoader API as a drop-in replacement for java.lang.ClassLoader:
public abstract class ResourceLoader
{
     /**
      * @see java.lang.ClassLoader#loadClass(java.lang.String)
      */
     public static Class loadClass (final String name)
         throws ClassNotFoundException
     {
         final ClassLoader loader = ClassLoaderResolver.getClassLoader (1);
         
         return Class.forName (name, false, loader);
     }
     /**
      * @see java.lang.ClassLoader#getResource(java.lang.String)
      */     
     public static URL getResource (final String name)
     {
         final ClassLoader loader = ClassLoaderResolver.getClassLoader (1);
         
         if (loader != null)
             return loader.getResource (name);
         else
             return ClassLoader.getSystemResource (name);
     }
     ... more methods ...
} // End of class

The decision of what constitutes the best classloader to use is factored out into a pluggable component implementing the IClassLoadStrategy interface:

public interface IClassLoadStrategy
{
    ClassLoader getClassLoader (ClassLoadContext ctx);
} // End of interface
 
To help IClassLoadStrategy make its decision, it is given a ClassLoadContext object:
public class ClassLoadContext
{
    public final Class getCallerClass ()
    {
        return m_caller;
    }
    
    ClassLoadContext (final Class caller)
    {
        m_caller = caller;
    }
    
    private final Class m_caller;
} // End of class
 
ClassLoadContext.getCallerClass() returns the class whose code calls into ClassLoaderResolver or ResourceLoader. This is so that the strategy implementation can figure out the caller's classloader (the context loader is always available as Thread.currentThread().getContextClassLoader()). Note that the caller is determined statically; thus, my API does not require existing business methods to be augmented with extra Class parameters and is suitable for static methods and initializers as well. You can augment this context object with other attributes that make sense in your deployment situation.
 
I have a default strategy implementation that should work correctly in 95 percent of real-life situations:
public class DefaultClassLoadStrategy implements IClassLoadStrategy
{
    public ClassLoader getClassLoader (final ClassLoadContext ctx)
    {
        final ClassLoader callerLoader = ctx.getCallerClass ().getClassLoader ();
        final ClassLoader contextLoader = Thread.currentThread ().getContextClassLoader ();
        
        ClassLoader result;
        
        // If 'callerLoader' and 'contextLoader' are in a parent-child
        // relationship, always choose the child:
        
        if (isChild (contextLoader, callerLoader))
            result = callerLoader;
        else if (isChild (callerLoader, contextLoader))
            result = contextLoader;
        else
        {
            // This else branch could be merged into the previous one,
            // but I show it here to emphasize the ambiguous case:
            result = contextLoader;
        }
        
        final ClassLoader systemLoader = ClassLoader.getSystemClassLoader ();
        
        // Precaution for when deployed as a bootstrap or extension class:
        if (isChild (result, systemLoader))
            result = systemLoader;
        
        return result;
    }
    
    ... more methods ...
} // End of class
The logic above should be easy to follow. If the caller's current and context classloaders are in a parent-child relationship, I always choose the child. The set of resources visible to a child loader is normally a superset of classes visible to its parent, so this feels like the right decision as long as everybody plays by J2SE delegation rules.
It is when the current and the context classloaders are siblings that the right decision is impossible. Ideally, no Java runtime should ever create this ambiguity. When it happens, my code chooses the context loader: a decision based on personal experience of when things work correctly most of the time. Feel free to change that code branch to suit your taste. It is possible that the context loader is a better choice for framework components, and the current loader is better for business logic.
Finally, a simple check ensures that the selected classloader is not a parent of the system classloader. This is a good thing to do if you are developing code that might be deployed as an extension library.
Note that I intentionally do not look at the name of resources or classes that will be loaded. If nothing else, the experience with Java XML APIs becoming part of the J2SE core should have taught you that filtering by class names is a bad idea. Nor do I trial load classes to see which classloader succeeds first. Examining classloader parent-child relationships is a fundamentally better and more predictable approach.
Although Java resource loading remains an esoteric topic, J2SE relies on various load strategies more and more with every major platform upgrade. Java will be in serious trouble if this area is not given some significantly better design considerations. Whether you agree or not, I would appreciate your feedback and any interesting pointers from your personal design experience.