Wicket1.3中Class热加载--揭秘篇

Wicket1.3中Class热加载--揭秘篇

 

在文章《Wicket1.3中Class热加载--使用篇》中，展示了如何使用Wicket1.3提供的ReloadingWicketFilter来动态加载修改后的类（包括修改了签名的类），从而实现高效开发。但在该文章中，只是给出了如何使用该功能的说明，而本篇文章将明确解析Wicket1.3类热加载魔法的奥秘所在。

在上一篇文章中，是通过修改Wicket项目中web.xml文件，将其中的

org.apache.wicket.protocol.http.WicketFilter

全部替换成

org.apache.wicket.protocol.http.ReloadingWicketFilter

从而开启了Wicket类热加载的功能。那么为了探究其魔法奥秘，入手点自然就选择ReloadingWicketFilter这个类了。

先来看一下ReloadingWicketFilter的代码，惊人的少:

public class ReloadingWicketFilter extends WicketFilter { private ReloadingClassLoader reloadingClassLoader; /**  * Instantiate the reloading class loader  */ public ReloadingWicketFilter() { // Create a reloading classloader reloadingClassLoader = new ReloadingClassLoader(getClass().getClassLoader()); } /**  * @see org.apache.wicket.protocol.http.WicketFilter#getClassLoader()  */ protected ClassLoader getClassLoader() { return reloadingClassLoader; } /**  * @see org.apache.wicket.protocol.http.WicketFilter#init(javax.servlet.FilterConfig)  */ public void init(final FilterConfig filterConfig) throws ServletException { reloadingClassLoader.setListener(new IChangeListener() { public void onChange() { // Remove the ModificationWatcher from the current reloading class loader reloadingClassLoader.destroy(); /*  * Create a new classloader, as there is no way to clear a ClassLoader's cache. This  * supposes that we don't share objects across application instances, this is almost  * true, except for Wicket's Session object.  */ reloadingClassLoader = new ReloadingClassLoader(getClass().getClassLoader()); try { init(filterConfig); } catch (ServletException e) { Throw new RuntimeException(e); } } }); super.init(filterConfig); } }

其中最引人注目的就是那个ReloadingClassLoader，再打开WicketFilter类中，很容易找到以下代码，它表示使用自定义的ClassLoader来加载类。

final ClassLoader newClassLoader = getClassLoader(); Thread.currentThread().setContextClassLoader(newClassLoader);

而ReloadingWicketFilter则是重载了getClassLoader方法，以返回了自定义的ReloadingClassLoader。也就是说Wicket的魔法其实是使用了一个自定义的ReloadingClassLoader来实现类的热加载（包括对签名被修改的类）。为了让大家更清楚理解Wicket这一方法以，在分析ReloadingClassLoader之前，先来简单的过一下JVM的类加载机制。

在JDK1.2以后，JVM在加载类时默认采用的是双亲委托机制（早期的类加载机制存在安全漏洞）。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，所有 ClassLoaders 的根都是系统 ClassLoader，它会以缺省方式装入类，即从本地文件系统加载（可能是Jar包，也可能是Class文件），如果父类加载器可以完成类加载任务，就成功返回加载后的类；但如果父类加载器无法完成此加载任务时，那么这个特定的类加载才自己去加载指定名称的类。这样的双亲委托机制可以保证象java.io.*这种基础类库的内容一定是被系统ClassLoader加载，从而保证类加载的安全性。

下面是双亲委派机制的示意图:

实例分析Web应用下的类加载顺序:

为了更好的方便大家理解类的加载机制，并说明Wicket如何使用自定义的ClassLoader来加载更改后的类，下面将有一个简单的实例来说明。

首先将前一篇文章中的HelloWorld代码修改为:

public class HelloWorld extends WicketExamplePage { /**  * Constructor  */ public HelloWorld() { ClassLoader classLoader = this.getClass().getClassLoader(); while (null != classLoader)  { System.err.println("loader   " + classLoader.hashCode()+"   "+classLoader.getClass()); classLoader = classLoader.getParent(); } add(new Label("message", "New Hello World!")); } }

修改以后的代码，可以在对象被创建时，输出HelloWorld类的ClassLoader及其父ClassLoader，接下来恢复web.xml文件中的filter为WicketFilter，不使用RelodingWicketFilter，从而观察原先的Class加载顺序，得到的结果为:

loader   2011334   class org.apache.catalina.loader.WebappClassLoader loader   19608393   class org.apache.catalina.loader.StandardClassLoader loader   13756574   class org.apache.catalina.loader.StandardClassLoader loader   26726999   class sun.misc.Launcher$AppClassLoader loader   7494106   class sun.misc.Launcher$ExtClassLoader

接下来仍然按照上一篇文章中的操作修改web.xml，使用RelodingWicketFilter，开启Wicket类的热加载功能。再看一下输出结果:

loader   8310913   class org.apache.wicket.application.ReloadingClassLoader loader   2011334   class org.apache.catalina.loader.WebappClassLoader loader   19608393   class org.apache.catalina.loader.StandardClassLoader loader   13756574   class org.apache.catalina.loader.StandardClassLoader loader   26726999   class sun.misc.Launcher$AppClassLoader loader   7494106   class sun.misc.Launcher$ExtClassLoader

可见通过代码

final ClassLoader newClassLoader = getClassLoader(); Thread.currentThread().setContextClassLoader(newClassLoader);

ReloadingWicketFilter使用ReloadingClassLoader作为当前类的ClassLoader，也就是说它接管了所有WEB-INF/classes目录下面类文件的加载。这样它就可以根据实际情况来加载一个类。但有经验的程序员都有知道，一般来说Class一旦被加载，就表示在整个JVM生命周期的过程中，不会自动释放，而是放置在内存中。那么Wicket又是怎么释放已经加载的类，同时加载修改后的类呢?看一段ReloadingWicketFilter中init方法的代码:

/**  * @see org.apache.wicket.protocol.http.WicketFilter#init(javax.servlet.FilterConfig)  */ public void init(final FilterConfig filterConfig) throws ServletException { reloadingClassLoader.setListener(new IChangeListener() { public void onChange() { // Remove the ModificationWatcher from the current reloading class loader reloadingClassLoader.destroy(); /*  * Create a new classloader, as there is no way to clear a ClassLoader's cache. This  * supposes that we don't share objects across application instances, this is almost  * true, except for Wicket's Session object.  */ reloadingClassLoader = new ReloadingClassLoader(getClass().getClassLoader()); try { init(filterConfig); } catch (ServletException e) { Throw new RuntimeException(e); } } }); super.init(filterConfig); }

这段代码表示，一旦发现类文件的改变，将会销毁当前的reloadingClassLoader ，同时新建一个ReloadingClassLoader的实例，因为ClassLoader被销毁了，所以由该ClassLoader加载的类都将被销毁，然后再由新的ReloadingClassLoader进行加载，因此即使是修改了签名的类也是可以被正确加载成功的。当然这种做法，可能会引起Session中的数据不能正确识别和转换。但相对于开发环境下，开发人员通过另起一个新的Session就可以开始正常的工作了，还是可以有效的提高开发效率。

Wicket类加载的一个潜在问题:

如果仅仅使用Wicket开发程序，那么Wicket1.3引入的热加载机制，对开发人员来说，会是一件非常幸福的事情，但如果同时使用了jsp，也就是说同时在一个Web应用程序（不是Web应用服务器）中同时使用Wicket和JSP，而且在Wicket和JSP代码分别向Session中写入相同的对象，如用户信息之类的数据对象，那么就会出现一些不必要的问题，最觉的莫过于ClassCastException。虽然共用Wicket+JSP的情况比较少，出问题的机率也比较少，但还是要额外提出来作为一个警示。

下面是一个简单的类Person代码，用来展示如何出现ClassCastException:

public class Person  { /**  * Default constructor  */ public Person()  { super(); ClassLoader classLoader = this.getClass().getClassLoader(); while (null != classLoader)  { System.err.println("loader   " + classLoader.hashCode()+"   "+classLoader.getClass()); classLoader = classLoader.getParent(); } } }

在构造函数中的那段代码，可以输出它的ClassLoader顺序，接下来象先前一样访问那个HelloWorld应用，得到如下的ClassLoader顺序:

loader   8310913   class org.apache.wicket.application.ReloadingClassLoader loader   3862294   class org.apache.catalina.loader.WebappClassLoader loader   19608393   class org.apache.catalina.loader.StandardClassLoader loader   13756574   class org.apache.catalina.loader.StandardClassLoader loader   26726999   class sun.misc.Launcher$AppClassLoader loader   7494106   class sun.misc.Launcher$ExtClassLoader

然后再写一个run.jsp，代码如下:

<%@page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@page import="org.apache.wicket.examples.Person"%> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>Class Loader Demo</title> </head> <body> <% new Person(); %> </body> </html>

在run.jsp中，初始化一个Person对象，同样观察它的输出结果，得到另外一个不同的Class加载顺序:

loader   3862294   class org.apache.catalina.loader.WebappClassLoader loader   19608393   class org.apache.catalina.loader.StandardClassLoader loader   13756574   class org.apache.catalina.loader.StandardClassLoader loader   26726999   class sun.misc.Launcher$AppClassLoader loader   7494106   class sun.misc.Launcher$ExtClassLoader

可见在JSP中的Person与在HelloWorld中的Person是由不同的ClassLoader加载的（JSP编译成Servlet执行，在Tomcat中，org.apache.jasper.servlet.JasperLoader负责JSP编译后的类加载），根据JVM规范，这两个Class是不等价的。因此进行转换的时候，会引起ClassCastException，这是特别需要注意的一点。

点击这里下载Word格式