知识大全关于Java程序中类加载完全揭密

Posted 2022-07-19 知

篇首语：幽沉谢世事，俯默窥唐虞。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全关于Java程序中类加载完全揭密相关的知识，希望对你有一定的参考价值。

关于Java程序中类加载完全揭密 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　类加载是java语言提供的最强大的机制之一尽管类加载并不是讨论的热点话题但所有的编程人员都应该了解其工作机制明白如何做才能让其满足我们的需要这能有效节省我们的编码时间从不断调试ClassNotFoundException ClassCastException的工作中解脱出来这篇文章从基础讲起比如代码与数据的不同之处是什么他们是如何构成一个实例或对象的然后深入探讨java虚拟机（JVM）是如何利用类加载器读取代码以及java中类加载器的主要类型接着用一个类加载的基本算法看一下类加载器如何加载一个内部类本文的下一节演示一段代码来说明扩展和开发属于自己的类加载器的必要性紧接着解释如何使用定制的类加载器来完成一个一般意义上的任务使其可以加载任意远端客户的代码在JVM中定义实例化并执行它本文包括了J EE关于类加载的规范——事实上这已经成为了J EE的标准之一 类与数据一个类代表要执行的代码而数据则表示其相关状态状态时常改变而代码则不会当我们将一个特定的状态与一个类相对应起来也就意味着将一个类事例化尽管相同的类对应的实例其状态千差万别但其本质都对应着同一段代码在JAVA中一个类通常有着一个 class文件但也有例外在JAVA的运行时环境中（Java runtime）每一个类都有一个以第一类(first class)的Java对象所表现出现的代码其是java lang Class的实例我们编译一个JAVA文件编译器都会嵌入一个public static final修饰的类型为java lang Class 名称为class的域变量在其字节码文件中因为使用了public修饰我们可以采用如下的形式对其访问

　　java lang Class klass = Myclass class;

　　一旦一个类被载入JVM中同一个类就不会被再次载入了（切记同一个类）这里存在一个问题就是什么是同一个类？正如一个对象有一个具体的状态即标识一个对象始终和其代码(类)相关联同理载入JVM的类也有一个具体的标识我们接下来看在JAVA中一个类用其完全匹配类名(fully qualified class name)作为标识这里指的完全匹配类名包括包名和类名但在JVM中一个类用其全名和一个加载类ClassLoader的实例作为唯一标识因此如果一个名为Pg的包中有一个名为Cl的类被类加载器KlassLoader的一个实例kl 加载 Cl的实例即C class在JVM中表示为(Cl Pg kl ) 这意味着两个类加载器的实例(Cl Pg kl ) 和 (Cl Pg kl )是不同的被它们所加载的类也因此完全不同互不兼容的那么在JVM中到底有多少种类加载器的实例？下一节我们揭示答案

　　类加载器

　　在JVM中每一个类都被java lang ClassLoader的一些实例来加载类ClassLoader是在包中java lang里开发者可以自由地继承它并添加自己的功能来加载类无论何时我们键入java MyMainClass来开始运行一个新的JVM 引导类加载器(bootstrap class loader) 负责将一些关键的Java类如java lang Object和其他一些运行时代码先加载进内存中运行时的类在JRE\\lib\\rt jar包文件中因为这属于系统底层执行动作我们无法在JAVA文档中找到引导类加载器的工作细节基于同样的原因引导类加载器的行为在各JVM之间也是大相径庭同理如果我们按照如下方式

　　log(java lang String class getClassLoader());

来获取java的核心运行时类的加载器就会得到null 接下来介绍java的扩展类加载器扩展库提供比java运行代码更多的特性我们可以把扩展库保存在由java ext dirs属性提供的路径中 (编辑注 java ext dirs属性指的是系统属性下的一个key 所有的系统属性可以通过System getProperties()方法获得在编者的系统中 java ext dirs的value是 C:\\Program Files\\Java\\jdk _ \\jre\\lib\\ext 下面将要谈到的如java class path也同属系统属性的一个key )类ExtClassLoader专门用来加载所有java ext dirs下的 jar文件开发者可以通过把自己的 jar文件或库文件加入到扩展目录的classpath 使其可以被扩展类加载器读取从开发者的角度第三种同样也是最重要的一种类加载器是AppClassLoader 这种类加载器用来读取所有的对应在java class path系统属性的路径下的类 Sun的java指南中文章理解扩展类加载（Understanding Extension Class Loading）对以上三个类加载器路径有更详尽的解释这是其他几个JDK中的类加载器● URLClassLoader ●java security SecureClassLoader ●java rmi server RMIClassLoader ●sun applet AppletClassLoader java lang Thread 包含了public ClassLoader getContextClassLoader()方法这一方法返回针对一具体线程的上下文环境类加载器此类加载器由线程的创建者提供以供此线程中运行的代码在需要加载类或资源时使用如果此加载器未被建立缺省是其父线程的上下文类加载器原始的类加载器一般由读取应用程序的类加载器建立 类加载器如何工作？除了引导类加载器所有的类加载器都有一个父类加载器不仅如此所有的类加载器也都是java lang ClassLoader类型以上两种类加载器是不同的而且对于开发者自订制的类加载器的正常运行也至关重要最重要的方面是正确设置父类加载器任何类加载器其父类加载器是加载该类加载器的类加载器实例（记住类加载器本身也是一个类！）使用loadClass()方法可以从类加载器中获得该类我们可以通过java lang ClassLoader的源代码来了解该方法工作的细节如下

　　protected synchronized Class<?> loadClass (String name boolean resolve) throws ClassNotFoundException // First check if the class is already loaded Class c = findLoadedClass(name); if (c == null) try if (parent != null) c = parent loadClass(name false); else c = findBootstrapClass (name); catch (ClassNotFoundException e) // If still not found then invoke // findClass to find the class c = findClass(name); if (resolve) resolveClass(c); return c;

我们可以使用ClassLoader的两种构造方法来设置父类加载器

　　public class MyClassLoader extends ClassLoader public MyClassLoader() super(MyClassLoader class getClassLoader());

或

　　public class MyClassLoader extends ClassLoader public MyClassLoader() super(getClass() getClassLoader());

第一种方式较为常用因为通常不建议在构造方法里调用getClass()方法因为对象的初始化只是在构造方法的出口处才完全完成因此如果父类加载器被正确建立当要示从一个类加载器的实例获得一个类时如果它不能找到这个类它应该首先去访问其父类如果父类不能找到它(即其父类也不能找不这个类等等) 而且如果findBootstrapClass ()方法也失败了则调用findClass()方法 findClass()方法的缺省实现会抛出ClassNotFoundException 当它们继承java lang ClassLoader来订制类加载器时开发者需要实现这个方法 findClass()的缺省实现方式如下

　　protected Class<?> findClass(String name) throws ClassNotFoundException throw new ClassNotFoundException(name);

在findClass()方法内部类加载器需要获取任意来源的字节码来源可以是文件系统 URL 数据库可以产生字节码的另一个应用程序及其他类似的可以产生java规范的字节码的来源你甚至可以使用BCEL (Byte Code Engineering Library 字节码工程库) 它提供了运行时创建类的捷径 BCEL已经被成功地使用在以下方面编译器优化器混淆器代码产生器及其他分析工具一旦字节码被检索此方法就会调用defineClass()方法此行为对不同的类加载实例是有差异的因此如果两个类加载实例从同一个来源定义一个类所定义的结果是不同的 JAVA语言规范（Java language specification）详细解释了JAVA执行引擎中的类或接口的加载（loading）链接（linking）或初始化（initialization）过程图一显示了一个主类称为MyMainClass的应用程序依照之前的阐述 MyMainClass class会被AppClassLoader加载 MyMainClass创建了两个类加载器的实例 CustomClassLoader 和 CustomClassLoader 他们可以从某数据源（比如网络）获取名为Target的字节码这表示类Target的类定义不在应用程序类路径或扩展类路径在这种情况下如果MyMainClass想要用自定义的类加载器加载Target类 CustomClassLoader 和CustomClassLoader 会分别独立地加载并定义Target class类这在java中有重要的意义如果Target类有一些静态的初始化代码并且假设我们只希望这些代码在JVM中只执行一次而这些代码在我们目前的步骤中会执行两次——分别被不同的CustomClassLoaders加载并执行如果类Target被两个CustomClassLoaders加载并创建两个实例Target 和Target 如图一显示它们不是类型兼容的换句话说在JVM中无法执行以下代码

　　Target target = (Target) target ;

以上代码会抛出一个ClassCastException 这是因为JVM把他们视为分别不同的类因为他们被不同的类加载器所定义这种情况当我们不是使用两个不同的类加载器CustomClassLoader 和 CustomClassLoader 而是使用同一个类加载器CustomClassLoader的不同实例时也会出现同样的错误这些会在本文后边用具体代码说明图在同一个JVM中多个类加载器加载同一个目标类关于类加载定义和链接的更多解释请参考Andreas Schaefer的 Inside Class Loaders 为什么我们需要我们自己的类加载器原因之一为开发者写自己的类加载器来控制JVM中的类加载行为 java中的类靠其包名和类名来标识对于实现了java io Serializable接口的类 serialVersionUID扮演了一个标识类版本的重要角色这个唯一标识是一个类名接口名成员方法及属性等组成的一个位的哈希字段而且也没有其他快捷的方式来标识一个类的版本严格说来如果以上的都匹配那么则属于同一个类但是让我们思考如下情况我们需要开发一个通用的执行引擎可以执行实现某一特定接口的任何任务当任务被提交到这个引擎首先需要加载这个任务的代码假设不同的客户对此引擎提交了不同的任务凑巧这些所有的任务都有一个相同的类名和包名现在面临的问题就是这个引擎是否可以针对不同的用户所提交的信息而做出不同的反应这一情况在下文的参考一节有可供下载的代码样例 samepath 和 differentversions 这两个目录分别演示了这一概念图显示了文件目录结构有三个子目录samepath differentversions 和 differentversionspush 里边是例子图文件夹结构组织示例在samepath 中类version Version保存在v 和v 两个子目录里两个类具有同样的类名和包名唯一不同的是下边这行

　　public void fx() log( this = + this + ; Version fx( ) );

V 中日志记录中有Version fx( ) 而在v 中则是Version fx( ) 把这个两个存在细微不同的类放在一个classpath下然后运行Test类 set CLASSPATH= ;%CURRENT_ROOT%\\v ;%CURRENT_ROOT%\\v %JAVA_HOME%\\bin\\java Test图显示了控制台输出我们可以看到对应着Version fx( )的代码被执行了因为类加载器在classpath首先看到此版本的代码图在类路径中samepath测试排在最前面的version 再次运行类路径做如下微小改动 set CLASSPATH= ;%CURRENT_ROOT%\\v ;%CURRENT_ROOT%\\v %JAVA_HOME%\\bin\\java Test控制台的输出变为图对应着Version fx( )的代码被加载因为类加载器在classpath中首先找到它的路径图在类路径中samepath测试排在最前面的version 根据以上例子可以很明显地看出类加载器加载在类路径中被首先找到的元素如果我们在v 和v 中删除了version Version 做一个非version Version形式的 jar文件如myextension jar 把它放到对应java ext dirs的路径下再次执行后看到version Version不再被AppClassLoader加载而是被扩展类加载器加载如图所示图 AppClassLoader及ExtClassLoader继续这个例子文件夹differentversions包含了一个RMI执行引擎客户端可以提供给执行引擎任何实现了mon TaskIntf接口的任务子文件夹client 和 client 包含了类client TaskImpl有个细微不同的两个版本两个类的区别在以下几行

　　static log( client TaskImpl class getClassLoader (v ) : + TaskImpl class getClassLoader()); public void execute() log( this = + this + ; execute( ) );

在client 和client 里分别有getClassLoader(v ) 与 execute( )和getClassLoader(v ) 与 execute( )的的log语句并且在开始执行引擎RMI服务器的代码中我们随意地将client 的任务实现放在类路径的前面 CLASSPATH=%CURRENT_ROOT%\\mon;%CURRENT_ROOT%\\server; %CURRENT_ROOT%\\client ;%CURRENT_ROOT%\\client %JAVA_HOME%\\bin\\java server Server如图的屏幕截图在客户端VM 各自的client TaskImpl类被加载实例化并发送到服务端的VM来执行从服务端的控制台可以明显看到client TaskImpl代码只被服务端的VM执行一次这个单一的代码版本在服务端多次生成了许多实例并执行任务图执行引擎服务器控制台图显示了服务端的控制台加载并执行两个不同的客户端的请求如图７８所示需要注意的是代码只被加载了一次（从静态初始化块的日志中也可以明显看出）但对于客户端的调用这个方法被执行了两次图７执行引擎客户端控制台　图７中客户端VM加载了含有client TaskImpl class getClassLoader(v )的日志内容的类TaskImpl的代码并提供给服务端的执行引擎图的客户端VM加载了另一个TaskImpl的代码并发送给服务端图执行引擎客户端控制台　在客户端的VM中类client TaskImpl被分别加载初始化并发送到服务端执行图还揭示了client TaskImpl的代码只在服务端的VM中加载了一次但这唯一的一次却在服务端创造了许多实例并执行或许客户端该不高兴了因为并不是它的client TaskImpl(v )的方法调用被服务端执行了而是其他的一些代码如何解决这一问题？答案就是实现定制的类加载器 定制类加载器要较好地控制类的加载就要实现定制的类加载器所有自定义的类加载器都应继承自java lang ClassLoader 而且在构造方法中我们也应该设置父类加载器然后重写findClass()方法 differentversionspush文件夹包含了一个叫做FileSystemClassLoader的自订制的类加载器其结构如图所示图定制类加载器关系以下是在mon FileSystemClassLoader实现的主方法

　　public byte[] findClassBytes(String className) try String pathName = currentRoot + File separatorChar + className replace( File separatorChar) + class ; FileInputStream inFile = new FileInputStream(pathName); byte[] classBytes = new byte[inFile available()]; inFile read(classBytes); return classBytes; catch (java io IOException ioEx) return null; public Class findClass(String name)throws ClassNotFoundException byte[] classBytes = findClassBytes(name); if (classBytes==null) throw new ClassNotFoundException(); else return defineClass(name classBytes classBytes length); public Class findClass(String name byte[] classBytes)throws ClassNotFoundException if (classBytes==null) throw new ClassNotFoundException( (classBytes==null) ); else return defineClass(name classBytes classBytes length); public void execute(String codeName byte[] code) Class klass = null; try klass = findClass(codeName code); TaskIntf task = (TaskIntf) klass newInstance(); task execute(); catch(Exception exception) exception printStackTrace();

这个类供客户端把client TaskImpl(v )转换成字节数组之后此字节数组被发送到RMI服务端在服务端一个同样的类用来把字节数组的内容转换回代码客户端代码如下

　　public class Client public static void main (String[] args) try byte[] code = getClassDefinition ( client TaskImpl ); serverIntf execute( client TaskImpl code); catch(RemoteException remoteException) remoteException printStackTrace(); private static byte[] getClassDefinition (String codeName) String userDir = System getProperties() getProperty( BytePath ); FileSystemClassLoader fscl = null; try fscl = new FileSystemClassLoader (userDir); catch(FileNotFoundException fileNotFoundException) fileNotFoundException printStackTrace(); return fscl findClassBytes(codeName);

在执行引擎中从客户端收到的代码被送到定制的类加载器中定制的类加载器把其从字节数组定义成类实例化并执行需要指出的是对每一个客户请求我们用类FileSystemClassLoader的不同实例来定义客户端提交的client TaskImpl 而且 client TaskImpl并不在服务端的类路径中这也就意味着当我们在FileSystemClassLoader调用findClass()方法时 findClass()调用内在的defineClass()方法类client TaskImpl被特定的类加载器实例所定义因此当FileSystemClassLoader的一个新的实例被使用类又被重新定义为字节数组因此对每个客户端请求类client TaskImpl被多次定义我们就可以在相同执行引擎JVM中执行不同的client TaskImpl的代码

　　public void execute(String codeName byte[] code)throws RemoteException FileSystemClassLoader fileSystemClassLoader = null; try fileSystemClassLoader = new FileSystemClassLoader(); fileSystemClassLoader execute(codeName code); catch(Exception exception) throw new RemoteException(exception getMessage());

　　示例在differentversionspush文件夹下服务端和客户端的控制台界面分别如图所示

　　图定制类加载器执行引擎图显示的是定制的类加载器控制台我们可以看到client TaskImpl的代码被多次加载实际上针对每一个客户端类都被加载并初始化图定制类加载器客户端图中含有client TaskImpl class getClassLoader(v )的日志记录的类TaskImpl的代码被客户端的VM加载然后送到服务端图另一个客户端把包含有client TaskImpl class getClassLoader(v )的类代码加载并送往服务端图定制类加载器客户端这段代码演示了我们如何利用不同的类加载器实例来在同一个VM上执行不同版本的代码 J EE的类加载器

cha138/Article/program/Java/hx/201311/26923

知识大全 关于Java程序中类加载完全揭密

知识大全关于Java程序中类加载完全揭密