一 。深入了解Java的ClassLoader机制
为了深入了解Java的ClassLoader机制,我们先来做以下实验:
package java.lang;
public class Test {
public static void main(String[] args) {
char[] c = "1234567890".toCharArray();
String s = new String(0, 10, c);
}
}
String类有一个Package权限的构造函数String(int offset, int length, char[] array),按照默认的访问权限,由于Test属于java.lang包,因此理论上应该可以访问String的这个构造函数。编译通过!执行时结果如下:
Exception in thread "main" java.lang.SecurityException: Prohibited package name:
java.lang
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
奇怪吧?要弄清为什么会有SecurityException,就必须搞清楚ClassLoader的机制。
Java的ClassLoader就是用来动态装载class的,ClassLoader对一个class只会装载一次,JVM使用的ClassLoader一共有4种:
启动类装载器,标准扩展类装载器,类路径装载器和网络类装载器。
这4种ClassLoader的优先级依次从高到低,使用所谓的“双亲委派模型”。确切地说,如果一个网络类装载器被请求装载一个java.lang.Integer,它会首先把请求发送给上一级的类路径装载器,如果返回已装载,则网络类装载器将不会装载这个java.lang.Integer,如果上一级的类路径装载器返回未装载,它才会装载java.lang.Integer。
类似的,类路径装载器收到请求后(无论是直接请求装载还是下一级的ClassLoader上传的请求),它也会先把请求发送到上一级的标准扩展类装载器,这样一层一层上传,于是启动类装载器优先级最高,如果它按照自己的方式找到了java.lang.Integer,则下面的ClassLoader都不能再装载java.lang.Integer,尽管你自己写了一个java.lang.Integer,试图取代核心库的java.lang.Integer是不可能的,因为自己写的这个类根本无法被下层的ClassLoader装载。
再说说Package权限。Java语言规定,在同一个包中的class,如果没有修饰符,默认为Package权限,包内的class都可以访问。但是这还不够准确。确切的说,只有由同一个ClassLoader装载的class才具有以上的Package权限。比如启动类装载器装载了java.lang.String,类路径装载器装载了我们自己写的java.lang.Test,它们不能互相访问对方具有Package权限的方法。这样就阻止了恶意代码访问核心类的Package权限方法。
end
二 .一个简单的自定义classloader的实现
一个简单的自定义classloader的实现 |
kert 原创 (参与分:57651,专家分:885) 发表:2002-07-18 17:55 更新:2002-07-18 20:05 版本:1.0 阅读:16355次 |
|
<!---->
<!---->
很多时候人们会使用一些自定义的classloader ,而不是使用系统的class loader。大多数时候人们这样做的原因是,他们在编译时无法预知运行时会需要那些class。特别是在那些appserver中,比如tomcat,avalon-phonix,jboss中。或是程序提供一些plug-in的功能,用户可以在程序编译好之后再添加自己的功能,比如ant, jxta-shell等。定制一个classloader很简单,一般只需要理解很少的几个方法就可以完成。
一个最简单的自定义的classloader从classloader类继承而来。这里我们要做一个可以在运行时指定路径,加载这个路径下的class的classloader。
通常我们使用classloader.loadclass(string):class方法,通过给出一个类名,就会得到一个相应的class实例。因此只要小小的改动这个方法,就可以实现我们的愿望了。
源码:
- protected synchronized class loadclass(string name, boolean resolve) throws classnotfoundexception {
- / first, check if the class has already been loaded
- class c = findloadedclass(name);
- if (c == null) {
- try {
- if (parent != null) {
- c = parent.loadclass(name, false);
- }else{
- c = findbootstrapclass0(name);
- }
- }catch(classnotfoundexception e){
- / if still not found, then call findclass in order
- / to find the class.
- c = findclass(name);
- }
- }
- if (resolve) {
- resolveclass(c);
- }
- return c;
- }
source from classloader.java
first,check javaapi doc:上面指出了缺省的loadclass方法所做的几个步骤。
1. 调用findloadedclass(string):class 检查一下这个class是否已经被加载过了,由于jvm 规范规定classloader可以cache它所加载的class,因此如果一个class已经被加载过的话,直接从cache中获取即可。
2. 调用它的parent 的loadclass()方法,如果parent为空,这使用jvm内部的class loader(即著名的bootstrap classloader)。
3. 如果上面两步都没有找到,调用findclass(string)方法来查找并加载这个class。
后面还有一句话,在java 1.2版本以后,鼓励用户通过继承findclass(string)方法实现自己的class loader而不是继承loadclass(string)方法。
既然如此,那么我们就先这么做:)
- public class anotherclassloader extends classloader {
- private string basedir;private static final logger log =
- logger.getlogger(anotherclassloader.class);
- public anotherclassloader (classloader parent, string basedir) {
- super(parent);
- this.basedir = basedir;
- }
- protected class findclass(string name)
- throws classnotfoundexception {
- log.debug("findclass " + name);
- byte!#91;!#93; bytes = loadclassbytes(name);
- class theclass = defineclass(name, bytes, 0, bytes.length);/a
- if (theclass == null)
- throw new classformaterror();
- return theclass;
- }
- private byte!#91;!#93; loadclassbytes(string classname) throws
- classnotfoundexception {
- try {
- string classfile = getclassfile(classname);
- fileinputstream fis = new fileinputstream(classfile);
- filechannel filec = fis.getchannel();
- bytearrayoutputstream baos = new bytearrayoutputstream();
- writablebytechannel outc = channels.newchannel(baos);
- bytebuffer buffer = bytebuffer.allocatedirect(1024);
- while (true) {
- int i = filec.read(buffer);
- if (i == 0 || i == -1) {
- break;
- }
- buffer.flip();
- outc.write(buffer);
- buffer.clear();
- }
- fis.close();
- return baos.tobytearray();
- } catch (ioexception fnfe) {
- throw new classnotfoundexception(classname);
- }
- }
- private string getclassfile(string name) {
- stringbuffer sb = new stringbuffer(basedir);
- name = name.replace('.', file.separatorchar) + ".class";
- sb.append(file.separator + name);
- return sb.tostring();
- }
- }
[i]ps:这里使用了一些jdk1.4的nio的代码:)[/i]
很简单的代码,关键的地方就在a处,我们使用了defineclass方法,目的在于把从class文件中得到的二进制数组转换为相应的class实例。defineclass是一个native的方法,它替我们识别class文件格式,分析读取相应的数据结构,并生成一个class实例。
还没完呢,我们只是找到了发布在某个目录下的class,还有资源呢。我们有时会用class.getresource():url来获取相应的资源文件。如果仅仅使用上面的classloader是找不到这个资源的,相应的返回值为null。
同样我们看一下原来的classloader内部的结构。
- public java.net.url getresource(string name) {
- name = resolvename(name);
- classloader cl = getclassloader0();/这里
- if (cl==null) {
- / a system class.
- return classloader.getsystemresource(name);
- }
- return cl.getresource(name);}
原来是使用加载这个class的那个classloader获取得资源。
- public url getresource(string name) {
- url url;
- if (parent != null) {
- url = parent.getresource(name);
- } else {
- url = getbootstrapresource(name);
- }
- if (url == null) {
- url = findresource(name);/这里
- }
- return url;
- }
这样看来只要继承findresource(string)方法就可以了。修改以下我们的代码:
- /新增的一个findresource方法
- protected url findresource(string name) {
- log.debug("findresource " + name);
- try {
- url url = super.findresource(name);
- if (url != null)
- return url;
- url = new url("file://" + convername(name));
- /简化处理,所有资源从文件系统中获取
- return url;
- } catch (malformedurlexception mue) {
- log.error("findresource", mue);
- return null;
- }
- }
- private string convername(string name) {
- stringbuffer sb = new stringbuffer(basedir);
- name = name.replace('.', file.separatorchar);
- sb.append(file.separator + name);
- return sb.tostring();
- }
好了,到这里一个简单的自定义的classloader就做好了,你可以添加其他的调料(比如安全检查,修改class文件等),以满足你自己的口味:)
|
|
.jar文件?
end
三.tomcat reload,不得不说的故事
tomcat reload,不得不说的故事 |
kert 原创 (参与分:57509,专家分:885) 发表:2002-09-15 18:18 更新:2002-09-15 19:15 版本:0.5 阅读:10250次 |
|
<!---->
<!---->
tomcat reload,不得不说的故事
[i]我们知道在使用tomcat时,如果设置了reload后,tomcat会自动侦测web-inf目录下修改过的资源。如果发现有变化(通常是依据文件的lastmodified值),便会自动重新载入所有 的资源。表面上看,似乎是个很好的主意:不用重新启动tomcat便可以更新我们的web应。尤其是在调试阶段,只需简单的更新我们的代码,就可以重新测试了。然而美丽的表面总是隐藏着不可测的秘密。[/i]
----------------
最近在使用tomcat时,就遇到了一个有趣的问题,简单当时困扰了我很久(也许是因为我比较苯:))。到这里和大家分享一下。
我在webapp应用中有一个daemon 线程,用来定时监视某个状态的改变。如果没有改变就sleep一段时间,否则进行某些相应的处理。类似如下的代码:
-
- public class testreload{
- private static final logger log = logger.getlogger(commonreload.class.getname());
- private testreload(){
- log.info("constructing "+ getclass() + " : " + getclass().hashcode());
- new thread(){
- public void run(){
- while(true){
- work();/相应的处理工作
- try{
- sleep(10000);
- }catch(throwable t){
- };
- }
- }
- }.start();
- }
- private final static testreload instance = new testreload();
- }
[i]在constructor中构造这个线程,每隔10秒钟工作一次[/i]
这个类作为某个webapp中的一个组件,因此最初的入口还是一个servlet。当我为了debug,而重新编译代码并重新发布我的webapp后,发现原先生成的线程仍旧在工作,而同时tomcat也将新编译的代码载入内存,因此这时jvm中有了两个监视的线程在工作,因此会有不可预料的问题。但是这不仅仅是两个独立的工作线程的问题,虽然表面上如此。我修改了一下代码,添加了一个测试用的work方法,如下:
-
- public class testreload{
- ......
- private void work(){
- log.info("testreload "+
- testreload.class.hashcode());
- final classloader cl = getclass().getclassloader();
- log.info("the class loader is "
- + cl.getclass().getname()+ " : " + cl.hashcode());
- }
- }
这里有三行输出信息,用来跟踪一些jvm内部的信息。
- log.info("testreload "+testreload.class.hashcode());
用来输出testreload的class的hashcode值。
- log.info("the class loader is " + cl.getclass().getname()+ " : " + cl.hashcode())
用来输出加载这个testclass的class的classloader的名字和hashcode。
然后用一个简单的servlet作为程序的入口:
-
- protected void doget(httpservletrequest httpservletrequest,
- httpservletresponse httpservletresponse)
- throws servletexception, ioexception {
- class reload = testreload.class;
- writer w = httpservletresponse.getwriter();
- w.write("working...\r\n");
- w.write(reload.getname() +
- ": " + reload.hashcode());
- w.flush();
- }
这个servlet只是简单的要求classloader载入testclass的class并且进行class的初始化和相应的静态初始化。
我们来看一下试验的输出。
当webapp第一次运行时,屏幕输出入下:
...... 2002-9-15 16:00:01 kert.reload.testreload <init> 信息: constructing class kert.reload.testreload : 2737550 2002-9-15 16:00:01 kert.reload.testreload work 信息: testreload 2737550 2002-9-15 16:00:01 kert.reload.testreload work 信息: the class loader is org.apache.catalina.loader.webappclassloader : 23414511 2002-9-15 16:00:11 kert.reload.testreload work 信息: testreload 2737550 2002-9-15 16:00:11 kert.reload.testreload work 信息: the class loader is org.apache.catalina.loader.webappclassloader : 23414511
我重新编译代码并发布后,tomcat reload相应的代码后并在此运行这个webapp:
...... 2002-9-15 16:01:59 kert.reload.testreload <init> 信息: constructing class kert.reload.testreload : 9104244 2002-9-15 16:01:59 kert.reload.testreload work 信息: testreload 9104244 2002-9-15 16:01:59 kert.reload.testreload work 信息: the class loader is org.apache.catalina.loader.webappclassloader : 13754931 2002-9-15 16:02:01 kert.reload.testreload work 信息: testreload 2737550 2002-9-15 16:02:01 kert.reload.testreload work 信息: the class loader is org.apache.catalina.loader.webappclassloader : 23414511 2002-9-15 16:02:09 kert.reload.testreload work 信息: testreload 9104244 2002-9-15 16:02:09 kert.reload.testreload work 信息: the class loader is org.apache.catalina.loader.webappclassloader : 13754931 2002-9-15 16:02:11 kert.reload.testreload work 信息: testreload 2737550 2002-9-15 16:02:11 kert.reload.testreload work 信息: the class loader is org.apache.catalina.loader.webappclassloader : 23414511 ......
可以很明显的看到,在tomcat reload后jvm中同时存在了两个工作线程。并且不仅仅如此,两个线程输出有着明显的不同。
- 两个testreload的class的hashcode不同,说明jvm内存中存在着两个不同的testreload的class的实例。
- 每个testreload的class的对应的classloader也不相同。
照理说,tomcat reload在reload一个webapp时,应该清除原先的所有载入的数据。包括已生成的对象和相应的class对象,然后交个gc来处理(回收所有的对象,包括class对象和classloader)。
但是由于有一个无法终止的线程,tomcat reload无法让线程停止,因此也无法回收相应的class。这样,在先前生成的所有class都会仍旧保存在内存中。并且与reload后的class同名,虽然由于加载的classloader不同,这两组class是无法互相访问的,因为他们属于不同的runtime package。
但是这种状况仍旧会导致很多问题。
- 1.重复工作:有多个线程在做同样的工作。
- 2.访问限制:由于runtime package的限制,原来在编译期互相可见的变量或是方法,在运行期可能无法互相访问。
- 3.classnotfound:显而易见。
......
显然,tomcat reload并不能像我们想象的那样很够很好的完成我们的工作。虽然这不是tomcat的错,我猜想在其他的container中也会有这样的现象发生,如jboss。container并不能够终止我们的精灵线程,而我们也无法介入到container的reload机制中去,如何reload(remove)我们先前的代码。如果tomcat在reload之前,在remove旧的代码的时候可以定义一个回调函数,或是有一个event机制通知我们的应用,那么我们可以采取某些措施。
现在为止,我还没有想到一个比较好的方式来处理这种情况(还是比较笨的缘故)。暂时还是重启tomcat。或是把这个后台线程做成一个mbean,使用jmx来管理它。
如果各位有好解决方法或是相应的pattern,欢迎回贴。
如果各位发现某些错误,更是欢迎“砖头”。
|
|
相關評論:
评论人:crazycode 参与分: 101 专家分: 0 |
发表时间: 2003-01-14 14:42 |
你可以用single设计模式来保证只创建一个实例,再在启动线程时做一下判断,如果已经有线程在运行,中止它,再启动新的线程。 |
评论人:kert 参与分: 57509 专家分: 885 |
发表时间: 2003-01-14 16:08 |
呵呵,由于代码是由tomcat的内置classloader加载,它们根本不再同一个runtime package中,
因此无法判断。 |
|
评论人:quake_wang 参与分: 179 专家分: 130 |
发表时间: 2003-01-15 09:12 |
你可以把这个daemon线程的类放在tomcat的classpath下,而不是放在webapp下,这样应该就可以了. |
|
评论人:banq 参与分: 86 专家分: 10 |
发表时间: 2003-01-15 09:51 |
我不理解的问题是:
servlet一般情况下本质是线程的,你为什么还在其内部直接编制启动一个线程?
我觉得如果你可以在servlet容器外编制一个线程不停的访问servlet
这样可以实现你的目的 |
|
评论人:banq 参与分: 86 专家分: 10 |
发表时间: 2003-01-15 10:09 |
如果一定要在servlet容器内部做,可以借鉴jive使用java.util.timertask |
|
评论人:wuyu 参与分: 80 专家分: 50 |
发表时间: 2003-02-14 16:49 |
精灵线程start的时候将其hashcode或时间戳记录在一个handle文件中,定期检查这个文件内容是否相符,如果不符则中止线程?
|
|
评论人:panwen 参与分: 77 专家分: 0 |
发表时间: 2003-02-15 13:23 |
我觉得任何线程都应该有一个退出机制,例如:
public void run()
{
while(flag)
{
try
{
work();
thread.sleep(6000);
}catch(exception e){}
}
}
在servlet的destroy方法里
设置flag=false就可以让线程退出。 |
|
评论人:fridaychen 参与分: 59 专家分: 10 |
发表时间: 2003-02-18 14:09 |
在tomcat中可以注册servletcontextlistener,这是一个标准的机制。
public void contextinitialized(servletcontextevent sce);
public void contextdestroyed(servletcontextevent sce);
允许程序在系统启动和关闭的时候作一些工作。我把线程的启动和关闭都放在这里了,这样系统在reload的时候,也会调用servletcontextlistener的方法。
|
|
评论人:wuyu 参与分: 80 专家分: 50 |
发表时间: 2003-02-18 16:20 |
非常感谢楼上的所有朋友们,特别是fridaychen。
为了测试fridaychen所说的servletcontextlistener,我特意做了一个小测试,然后在tomcat4.1.18的/manager/html/list里面stop/start/reload /market这个web app,结果,在tomcat load webapp的时,contextinitialized中的代码被执行,系统开始定时执行继续了java.util.timertask的守护线程程序,stop时,contextdestroyed中的代码被执行,所有正在执行的守护线程程序均正常中止。
tomcat控制台的输出信息
startup init
start
d:\www\web\market_version\
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
timertask run...
destory
market.marketlistener源代码
package market;
/**
* 侦听器程序测试
*/
public class marketlistener implements javax.servlet.servletcontextlistener {
private java.util.timer timer;
public marketlistener() {
system.out.println( "startup init" );
timer = new java.util.timer( true );
}
public void contextdestroyed( javax.servlet.servletcontextevent event ) {
system.out.println( "destory" );
timer.cancel();
}
public void contextinitialized( javax.servlet.servletcontextevent event ) {
& | |
分享到:
相关推荐
1. 当程序需要加载一个类时,它会请求ClassLoader。 2. ClassLoader接收到请求后,首先检查该类是否已经加载过,如果已加载则直接返回。 3. 如果类还未加载,ClassLoader会在指定的路径(例如类路径,classpath)下...
本篇文章将深入探讨Java ClassLoader的内部工作,并通过一个具体的实例来展示如何定制自己的ClassLoader。 首先,我们来看ClassLoader的基本工作流程。当JVM启动时,它会有一个初始的Bootstrap ClassLoader,用于...
### Java虚拟机中ClassLoader概述与双亲委托机制详解 #### 一、ClassLoader概念与作用 在Java编程语言中,`ClassLoader`是一个非常重要的组件,它负责加载程序运行所需的类文件到Java虚拟机(JVM)中。`ClassLoader`...
1. Bootstrap ClassLoader:这是JVM启动时的第一个ClassLoader,负责加载JDK核心类库(如rt.jar)。 2. Extension ClassLoader:加载JDK扩展目录(如$JAVA_HOME/jre/lib/ext)中的类。 3. System ClassLoader(也...
在Java中,Classloader是加载类的关键组件,它负责查找、加载和初始化字节码文件。自定义Classloader允许开发者根据特定需求定制类的加载逻辑,例如加密类文件、隔离不同版本的库或者动态加载代码。本文将深入探讨...
1. **ClassLoader的基本概念** - 类加载器是Java中的一个核心组件,它负责将类的.class文件加载到JVM中,并转换为可执行的Java对象。 - Java的类加载机制遵循“双亲委派模型”,即一个类加载请求会先由顶级的...
1. **加载**:加载是ClassLoader工作的起点,它从文件系统或网络中找到类的二进制数据,然后创建一个对应的Class对象。这个过程可以通过自定义ClassLoader来实现,比如从数据库中加载类。 2. **验证**:验证是确保...
1. 每个OSGi bundle都有自己的ClassLoader,用于加载该bundle中的类,这使得不同bundle之间的类隔离得以实现,避免了类冲突。 2. OSGi的ClassLoader支持动态加载和卸载bundle,当bundle被激活或停用时,对应的类...
首先,ClassLoader可以分为三种基本类型:Bootstrap ClassLoader、Extension ClassLoader和Application ClassLoader。Bootstrap ClassLoader是JVM启动时的第一个ClassLoader,负责加载JDK的`<JAVA_HOME>\lib`目录下...
1. Bootstrap ClassLoader:引导类加载器,也称为原始类加载器。它是整个加载过程的起点,负责加载Java的核心类库,如rt.jar,这是Java运行环境的基础。Bootstrap ClassLoader并非继承自java.lang.ClassLoader,而是...
1. 类加载器的实例化和配置,包括指定加载类的目录。 2. 对`loadClass()` 和 `findClass()` 的覆写,实现自定义加载逻辑。 3. 文件I/O操作,读取并加载指定目录下的.class文件。 4. 使用`Class.forName()` 或 `Class...
1. **查找类**:当JVM需要加载一个类时,ClassLoader会根据类名(全限定名,如`java.lang.String`)在对应的存储位置寻找`.class`文件。 2. **加载类**:找到`.class`文件后,ClassLoader将其读入内存,并创建一个...
Java ClassLoader是一个核心的Java运行时组件,负责加载类到Java虚拟机(JVM)中。它是Java平台的独特特性,因为它允许动态加载类,增强了软件的可扩展性和灵活性。这篇博文(虽然链接不可用)可能深入探讨了...
1. **Bootstrap ClassLoader**:启动类加载器,负责加载位于`<JAVA_HOME>\lib`目录中的类库或者扩展目录中的类库(由`-Xbootclasspath`选项指定)。 2. **Extension ClassLoader**:扩展类加载器,负责加载`...
1. Bootstrap ClassLoader:这是最基础的类加载器,由C++实现,负责加载JDK核心库(rt.jar)。 2. Extension ClassLoader:扩展类加载器,负责加载JRE的扩展目录(jre/lib/ext目录下的jar文件)。 3. AppClassLoade...
1. 类加载机制概述 Java的类加载机制遵循“双亲委派模型”(Delegation Model)。当一个类被加载时,它首先会尝试由当前线程的Context ClassLoader进行加载,如果该类加载器无法加载,则向上委托给父类加载器,直至...
破解java加密的ClassLoader.java,在classloader植入破解代码