ClassLoader类装载策略

Java编程极限考验：ClassLoader类装载策略
作者：banq 发表时间：2004年07月26日 15:11 回复


原贴网址： http://www.jdon.com/jivejdon/thread/15456.html

个人认为，Java编程中极限考验是Classloader机制的掌握和灵活运用，特别是在复杂的系统，如存在动态类装载，Reflect，EJB,AOP等环境。

CLass.forName()
和Thread.currentThread().getContextClassLoader())
是否一样？

在很多文章中，都认为两者是一致的，如Java研究组织中一篇文章，被我从google搜索到的：
http://www.javaresearch.org/article/showarticle.jsp?column=31&thread=10178
文中说"这个方法可以用Class.forName()代替"，在一般简单情况是可以替代，但实际上有时候是不能替代的。

Classloader存在下面问题：
在一个JVM中可能存在多个ClassLoader，每个ClassLoader拥有自己的NameSpace。一个ClassLoader只能拥有一个class对象类型的实例，但是不同的ClassLoader可能拥有相同的class对象实例，这时可能产生致命的问题。如ClassLoaderA，装载了类A的类型实例A1，而ClassLoaderB，也装载了类A的对象实例A2。逻辑上讲A1=A2，但是由于A1和A2来自于不同的ClassLoader，它们实际上是完全不同的，如果A中定义了一个静态变量c，则c在不同的ClassLoader中的值是不同的。

因此，研究JBoss的ClassLoader策略，对于更好地实现EJB组件拼装是用好处的，因为，一个项目中可能要用其他项目的EJB组件，如何实现运行时EJB组件共享，如何实现EJB组件打包是很重要的。


为了说明ClassLoader对于复杂架构是至重关键，列举开源Portal产品Exo中ServivesManager类内容。

该类是Exo利用PicoCOntainer实现功能性Service JavaBeans初始化，在将那些Service性质的JavaBeans加载到pico中时，需要使用到Classloader,
Exo专门设立一个ServiceContext类：




public class ServiceContext {  private ClassLoader cl;  //包含Classloader信息  private Services services;  public ServiceContext(ClassLoader cl, Services services) {    this.cl = cl;    this.services = services;  }  public ClassLoader getCl() {    return cl;  }  public Services getServices() {    return services;  }}


在ServicesManager中，有：
private ClassLoader updatedClassLoader;

它的初始值是：
Thread.currentThread().getContextClassLoader();

如果，这里写Class.forName　那么简单，那么你头疼去吧。

但是这样不够：
在addService方法中，根据加入的不同ServiceContext实现类装载：



public void addService(ServiceContext context) {    Services servicesToAdd = context.getServices();    String name = servicesToAdd.getName();    URLClassLoader cl = null;    if(context.getCl() instanceof URLClassLoader) {      cl = (URLClassLoader) context.getCl();    } else {      cl = URLClassLoader.newInstance(new URL[]{}, context.getCl());    }    updatedClassLoader = new URLClassLoader(cl.getURLs(), updatedClassLoader);    synchronized (servicesContext) {      servicesContext.put(name, context);      reloadContainer();    }  }


其实向Picocontainer中加入一个服务很简单，上述方法的主要代码是处理Classloader，考虑到Classloader有嵌套关系，上述代码小心使用这个Service服务的父Classloader，使用父Classloader装载服务Service。


希望有兴趣者一起讨论。




Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月26日 15:35  回复 

banq 发表文章: 8564/ 注册时间: 2002年08月03日 17:08 

下面一段代码　是在Web容器中，实现Servlet类或Jsp类的动态装载，一般Servlet类部署到Web容器，是由Web容器监测Web.xml是否变化，<br>以决定是否装载，这是非常被动的，使用下面代码通过ClassLoader可以在自己程序中主动实现装载：<br>


public class WrapperServlet extends Servlet {   public void init(ServletConfig config) {     m_config = config; // stored as you don't want this to change   }   public void doGet(...) throws ServletException {     getServlet().doGet(...);   }   private Servlet getServlet() throws ServletException {     if ((m_servlet == null) || haveClassesChanged()) {         创造一个独立的classloader 确保它的父是我们的自己的ClassLoader<br>        path_to_separate_classes是将被装载的路       URLClassLoader loader = new URLClassLoader(new URL[] {         new URL("path_to_separate_classes");       }, WrapperServlet.class.getClassLoader());       从被装载的路径使用自己装载器来装载Servlet类              Class servletClass =         loader.loadClass(m_config.getInitParameter("servletClass");       m_servlet = (Servlet)servletClass.newInstance();       m_servlet.init(m_config);     }     return m_servlet;   }   private boolean haveClassesChanged() {     // determine whether classes have changed somehow   }   private ServletConfig m_config;   private Servlet m_servlet = null;}





Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 10:13  回复 

flyisland 发表文章: 15/ 注册时间: 2004年04月22日 13:33 

以前写的一篇文章：http://www.blogbus.com/blogbus/blog/diary.php?diaryid=153255，可供参考。



Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 10:32  回复 

cats_tiger 发表文章: 178/ 注册时间: 2003年05月16日 16:58 

嗯，难道需要编写通用的ClassLoader查询类？我写了一个...


// 摘自javax.xml.parsers.FactoryFinderpublic final class ClassLoaderFinder {  private ClassLoaderFinder() {  }  /**   * Figure out which ClassLoader to use.  For JDK 1.2 and later use the   * context ClassLoader if possible.  Note: we defer linking the class   * that calls an API only in JDK 1.2 until runtime so that we can catch   * LinkageError so that this code will run in older non-Sun JVMs such   * as the Microsoft JVM in IE.   */  public static ClassLoader findClassLoader() throws ConfigurationError {    ClassLoader classLoader;    try {      // Construct the name of the concrete class to instantiate      Class clazz = Class.forName(ClassLoaderFinder.class.getName()                                  + "$ClassLoaderFinderConcrete");      ContextClassLoaderFinder clf = (ContextClassLoaderFinder) clazz.          newInstance();      classLoader = clf.getContextClassLoader();    }    catch (LinkageError le) {      // Assume that we are running JDK 1.1, use the current ClassLoader      classLoader = ClassLoaderFinder.class.getClassLoader();    }    catch (ClassNotFoundException x) {      // This case should not normally happen.  MS IE can throw this      // instead of a LinkageError the second time Class.forName() is      // called so assume that we are running JDK 1.1 and use the      // current ClassLoader      classLoader = ClassLoaderFinder.class.getClassLoader();    }    catch (Exception x) {      // Something abnormal happened so throw an error      throw new ConfigurationError(x.toString(), x);    }    return classLoader;  }  static class ConfigurationError      extends Error {    private Exception exception;    /**     * Construct a new instance with the specified detail string and     * exception.     */    ConfigurationError(String msg, Exception x) {      super(msg);      this.exception = x;    }    Exception getException() {      return exception;    }  }  /*   * The following nested classes allow getContextClassLoader() to be   * called only on JDK 1.2 and yet run in older JDK 1.1 JVMs   */  private static abstract class ContextClassLoaderFinder {    abstract ClassLoader getContextClassLoader();  }  static class ClassLoaderFinderConcrete      extends ContextClassLoaderFinder {    ClassLoader getContextClassLoader() {      return Thread.currentThread().getContextClassLoader();    }  }  //Sample  public static void main(String args[]) {    try {      final String CLASS_NAME = "oracle.jdbc.driver.OracleDriver";      Class spiClass;      ClassLoader classLoader = ClassLoaderFinder.findClassLoader();      if (classLoader == null) {        System.out.println("From Class.forName");        spiClass = Class.forName(CLASS_NAME);      }      else {        System.out.println("From ClassLoaderFinder");        spiClass = classLoader.loadClass(CLASS_NAME);        spiClass.newInstance();      }      java.sql.Connection conn = java.sql.DriverManager.getConnection(          "jdbc:oracle:thin:@localhost:1521:ORCL",          "scott",          "tiger");      java.sql.Statement stmt = conn.createStatement();      java.sql.ResultSet rs = stmt.executeQuery("select * from cat");      while (rs.next()) {        System.out.println(rs.getString(2));      }    }    catch (Exception e) {      e.printStackTrace();    }  }}




Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 10:53  回复 

asdlcj 发表文章: 22/ 注册时间: 2004年03月19日 23:42 

大家还是看深入java虚拟机那本书把

说的很详细了

我不想再多说了！



Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 11:06  回复 

banq 发表文章: 8564/ 注册时间: 2002年08月03日 17:08 

深入java虚拟机只是从原理机制谈了ClassLoader，关键是应用，面对复杂环境的应用，比如别人的框架已经有ClassLoader，你在别人的框架下还要ClassLoader，你就得注意父子关系，但是你也可以建立并行关系。

在你决定如何建立你的CLassLoader策略时，你必须对你基于的框架内部有了解，因为你的应用和JVM之间有很多层，有EJB容器层　有你的框架层，你也必须了解这中间层的ClassLoader策略，只是掌握JVM还不够的。

简单地说，如果你基于AOP框架或EJB容器实现ClassLoader，那么你必须对你的AOP框架或EJB容器的ClassLoader策略掌握，Weblogic和JBoss 3.2机制就不一样，各个服务器都不同，不同版本不同，如果你不注意这些变化，那么你的应用系统迁移就有问题，甚至无法实现迁移。





Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 11:08  回复 

banq 发表文章: 8564/ 注册时间: 2002年08月03日 17:08 

to cats_tiger
你做了findClassLoader，但是没有构造自己的ClassLoader，还是有漏洞，你的Classloader是使用Class.forName，这个问题在复杂环境下会有问题，特别是动态代理Proxy下不正常，有时会报ClassCastException错误。这也是很多人对动态代理感到无法掌握的原因之一。




Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 12:14  回复 

cats_tiger 发表文章: 178/ 注册时间: 2003年05月16日 16:58 

to banq
难道要这样？好像太麻烦了。

package cloader;public final class ClassLoaderFinder {  private ClassLoaderFinder() {  }    /**   * The following nested classes extends the <tt>ClassLoader</tt> so that we   * can create our ClassLoader freely.   */  private static class PersonalClassLoader extends ClassLoader {    public PersonalClassLoader(ClassLoader parentLoader) {      super(parentLoader);    }        public PersonalClassLoader() {      //Use the external class's <tt>ClassLoader</tt>      super(ClassLoaderFinder.class.getClassLoader());    }  }  /**   * Figure out which ClassLoader to use.  For JDK 1.2 and later use the   * context ClassLoader if possible.  Note: we defer linking the class   * that calls an API only in JDK 1.2 until runtime so that we can catch   * LinkageError so that this code will run in older non-Sun JVMs such   * as the Microsoft JVM in IE.   */  public static ClassLoader findClassLoader() throws ConfigurationError {    ClassLoader classLoader;    try {      // Construct the name of the concrete class to instantiate      PersonalClassLoader pLoader = new PersonalClassLoader();      Class clazz = pLoader.loadClass(ClassLoaderFinder.class.getName()                                         + "$ClassLoaderFinderConcrete");      //Class clazz = Class.forName(ClassLoaderFinder.class.getName()      //                            + "$ClassLoaderFinderConcrete");      ContextClassLoaderFinder clf = (ContextClassLoaderFinder) clazz.          newInstance();      classLoader = clf.getContextClassLoader();    }    catch (LinkageError le) {      // Assume that we are running JDK 1.1, use the current ClassLoader      classLoader = ClassLoaderFinder.class.getClassLoader();    }    catch (ClassNotFoundException x) {      // This case should not normally happen.  MS IE can throw this      // instead of a LinkageError the second time Class.forName() is      // called so assume that we are running JDK 1.1 and use the      // current ClassLoader      classLoader = ClassLoaderFinder.class.getClassLoader();    }    catch (Exception x) {      // Something abnormal happened so throw an error      throw new ConfigurationError(x.toString(), x);    }    return classLoader;  }  static class ConfigurationError      extends Error {    private Exception exception;    /**     * Construct a new instance with the specified detail string and     * exception.     */    ConfigurationError(String msg, Exception x) {      super(msg);      this.exception = x;    }    Exception getException() {      return exception;    }  }  /*   * The following nested classes allow getContextClassLoader() to be   * called only on JDK 1.2 and yet run in older JDK 1.1 JVMs   */  private static abstract class ContextClassLoaderFinder {    abstract ClassLoader getContextClassLoader();  }  static class ClassLoaderFinderConcrete      extends ContextClassLoaderFinder {    ClassLoader getContextClassLoader() {      return Thread.currentThread().getContextClassLoader();    }  }  //Sample  }





Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 12:20  回复 

cats_tiger 发表文章: 178/ 注册时间: 2003年05月16日 16:58 

实在是麻烦，绕来绕去的。
看来怎样处理ClassLoader，要根据具体的应用具体分析，从运行环境（Container）、用途等方面综合考虑。
绝大多数应用系统Class.forName就足够了。



Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 12:35  回复 

banq 发表文章: 8564/ 注册时间: 2002年08月03日 17:08 

>绝大多数应用系统Class.forName就足够了
这个定义如果存在的话，Exo的ServiceManager就不必这么复杂，Exo作为一个设计概念非常前卫的开源系统，在ServiceManager将ClassLoader搞得很复杂是有道理的，是经验的总结，使得自己的系统伸缩性强，健壮性更强，这些都是严格要求的设计目标所致。

这里我想讨论的是，不怕复杂，解剖其本质。

另外，自己定义ClassLoader象上面的代码是可以，但是在具体情况时还要注意，可能需要将原来的ClassLoader机制暂存，用自己定义的ClassLoader，然后再恢复原来的ClassLoader。





Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月27日 16:06  回复 

kewan 发表文章: 46/ 注册时间: 2003年04月20日 19:11 

ClassLoader其实是很简单的，以树型来组织。我看是楼上的各位把把简单的问题搞复杂了。



Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月28日 00:41  回复 

cats_tiger 发表文章: 178/ 注册时间: 2003年05月16日 16:58 

> ClassLoader其实是很简单的，以树型来组织。我看是楼上的?> 位把把简单的问题搞复杂了。

这个帖子的目的主要是研究一下ClassLoader的应用，而不是它的原理，所以复杂一些（很多原理简单的东西，用起来却复杂，例如围棋）。
但是，如果你的应用可能会在不同的JVM（例如MS JVM）下或不同的Container中运行，就要考虑ClassLoader的问题了。比如基于xml的静态工厂类，通常用Class.forName就行，但是在有些情况下却出现异常。




Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月28日 08:53  回复 

kewan 发表文章: 46/ 注册时间: 2003年04月20日 19:11 

> 这个帖子的目的主要是研究一下ClassLoader的应用，而不是?> 的原理，所以复杂一些（很多原理简单的东西，用起来却复杂
> 缥澹?> 但是，如果你的应用可能会在不同的JVM（例如MS
> JVM）下或不同的Container中运行，就要考虑ClassLoader的?> 题了。比如基于xml的静态工厂类，通常用Class.forName就行
> 窃谟行┣榭鱿氯闯鱿忠斐！?

不知道你说的基于xml的静态工厂类是怎么回事。
装入类和是否通过Class.forName没有必然的联系。
任何一个类装入都有一个运行环境和边界，搞清楚这个就行，没那么复杂。类要在该装入的地方装入。每个ClassLoader指的就是一个运行环境，每个ClassLoader也都有一个边界，类必须在这个边界内运行。
如果在不同的JVM下运行（不管是Sun的JVM还是MS的JVM，于此无关），应该和ClassLoader没有关系。比如一个分布式的Web应用，类的装入都在本地，和其他的JVM无关。如果考虑集群的问题，就不是ClassLoader的问题了。这一块没有做过，请各位指正。



Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月28日 09:39  回复 

cats_tiger 发表文章: 178/ 注册时间: 2003年05月16日 16:58 

>不知道你说的基于xml的静态工厂类是怎么回事。
>装入类和是否通过Class.forName没有必然的联系。
就是读取xml中定义的类名，然后实例化，返回父类型的那种工厂。
>任何一个类装入都有一个运行环境和边界，搞清楚这个就行，没那么复杂。
问题是有时候没有那么容易搞清楚。建议参考javax.xml.parsers.DocumentBuilderFactory的源代码



Re: Java编程极限考验：ClassLoader类装载策略  发表: 2004年07月28日 15:45  回复 

kewan 发表文章: 46/ 注册时间: 2003年04月20日 19:11 

那就先搞清楚再装入，呵呵。没有必要纠缠在ClassLoader上，把ClassLoader搞复杂了，并没有任何的好处。
另外，parser并没有你说得那么复杂。哈哈



  

这个主题共有 49 回复 ／ 4 页 [ 1 2 3 4 下一页 ]   

   上一篇: 如何处理对象删除时引用的判断  下一篇: 对于工商局中的线索管理业务如何画出四色模.. 
   

  查询本论坛 近一天 近三天 近一周 近一月 近三月 近半年 近一年 所有 最热门帖子  


   快速发表回复: 标题 
                       

内容   

评论

1 楼 pouyang 2011-09-01  

很感谢您的文章，但是能不能排版一下?