java中classloader原理

ClassLoader的工作原理

在Java内部实现了三种类型的ClassLoader：Bootstrap ClassLoader，Extension ClassLoader， System ClassLoader。这三个ClassLoader通过parent形成一条单向链，其中Bootstrap处于链尾，而System ClassLoader处于链头。

Bootstrap ClassLoader

Bootstrap ClassLoader用于在启动JVM时加载类，以使JVM能正常工作，因而它是用Native代码实现的，最早被创建出来，处于最底层。

Bootstrap ClassLoader将搜索Java核心库（%JAVA_HOME%\jre\lib），如rt.jar、i18n.jar等，在这些核心库中包含了Java的核心类，即Bootstrap ClassLoader用于加载Java的核心类，包括java.lang、java.io等包中的类。

Extension ClassLoader

Extension ClassLoader位于链的中间层，它将搜索特定的标准扩展目录。该标准扩展目录在不同的JVM实现中不一定相同，在sun的JVM中，它是%JRE_HOME% \lib\ext，具体路径可以通过java.ext.dirs系统属性值获取。该标准扩展目录存在的目的在于扩展和共享，应用程序厂商可以将部分共享库放置于此，而不是各自程序的目录下的多份拷贝。在开发过程中，我们也可以把部分常用的库放置于此，而不必每次都去配置环境。

System ClassLoader

System ClassLoader位于链的最顶层，它将搜索CLASSPATH中配置的目录和jar文件。

三种ClassLoader的协同工作

既然系统中有三种不同的ClassLoader，那么一个类的加载是用那个ClassLoader呢？在Java中，是通过“代理模型（delegation model）”来决定使用哪个ClassLoader来加载类的（读取.class文件，并创建相应的Class对象）。当一个类需要被加载的时候，系统默认通过System ClassLoader来加载该类；然而System ClassLoader并不立即加载该类，它会将加载的行为代理给其parent去加载，只有当其parent不能加载该类的时，System ClassLoader才去搜索CLASSPATH中的目录和jar文件以加载该类，若找到对应的.class文件，则加载该类，否则抛出ClassNotFoundException。当它将加载的行为代理给Extension ClassLoader并最终代理给Bootstrap ClassLoader的时候，他们也做的是相似的事情。从设计的角度，这其实就是一种职责链模式（Chain of Responsibility Pattern）。

那么Java为什么需要这种代理模型呢？答案是出于安全的考虑。Java是一种安全的编程语言，它会对每个加载的类执行安全检查，但是对Java核心库中的类是不执行安全检查的（即他们是受JVM信赖的）。（什么是安全检查？以我现在所知，就是用户可以通过security manager来控制特定目录的访问权限，如何使用这些控制将会是另一个主题。对安全检查是否还有其他的呢？）那么假如用户可以加载自己编写的和核心库同名的类（如java.lang.Object），那么这些用户编写的类就可以绕过安全检查，从而为一些恶意用户提供了一种破坏的途径。然而在使用这种代理模型后，类的加载首先会代理到Bootstrap ClassLoader中实行加载，如果它发现当前核心类库中可以加载对应的类，系统会加载核心库中的类，而不会加载用户编写的类。