【正文】Java类加载器( CLassLoader ) 死磕5:
自定义一个文件系统classLoader
本小节目录
5.1. 自定义类加载器的基本流程
5.2. 入门案例：自定义文件系统类加载器
5.3. 案例的环境配置
5.4 FileClassLoader 案例实现步骤
5.5. FileClassLoader 的类设计
5.6. FileClassLoader 的源码
5.7. FileClassLoader 的使用
5.8. 不同类加载器的命名空间关系
5.9. 自定义加载器的两个要点
1.1. 自定义classLoader
不管是Bootstrap ClassLoader还是ExtClassLoader等，这些类加载器都只是加载指定的目录下的jar包或者资源。
要实现其他的途径的类加载，比如从D盘某个文件夹加载一个class文件，或者从网络上下载class主内容然后再进行加载，就需要我们自定义一个classloader。
1.1.1. 自定义类加载器的基本流程
实际上，除了和本地实现密切相关的Bootstrap启动类加载器之外，包括Extention标准扩展类加载器和AppClassLoader应用类加载器在内的所有其他类加载器，都可以当做自定义类加载器来对待。
前面的内容中已经对java.lang.ClassLoader抽象类中的loadClass方法做了介绍，在此方法中，如果所有的上层类加载器都没有加载成功，则调用本类加载器的findClass（）方法，在自己的地盘，获取对应的字节码，并完成字节码到类的转变，并且将class加载到缓存中。这个findClass（）方法，就是自定义加载器的关键。
实现一个自定义加载器，总体来说，分成三步：
（1）在自己的地盘，获取对应的字节码；
（2）并完成字节码到类的转变；
（3）将class加载到缓存中；
前面两步，需要在findClass（）方法中完成。
废话少说，先看一个简单实例。
1.1.2. 入门案例：自定义文件系统类加载器
在宠物店的案例中，如果需要装载第三方的宠物库，并且第三方宠物库的类路径非常灵活。
现在需要设计自定义加载器，按照需要，从第三方库的加载宠物到内存。这里设计一个自定义加载类FileClassLoader。
在设计FileClassLoader之前，先交代一下第三方的宠物类LittleDog ，为了演示，和之前的Dog类代码99%相同的。
LittleDog 的代码如下：
package com.crazymakercircle.annoDemo;
.......
public class LittleDog implements IPet{
//宠物编号
private static int dogNo;
protected String name;
protected int age;
//无参构造器
public LittleDog() {
dogNo++;
name="LittleDog-"+ dogNo;
age = RandomUtil.randInMod(20);
}
@Tanscation
public LittleDog sayHello() {
Logger.info("嗨，大家好！我是" + name);
return this;
}
@Tanscation
public LittleDog sayAge() {
Logger.info("我是" + name + ",我的年龄是：" + age);
return this;
}
}
至此，一个简单的第三方类——LittleDog宠物类，已经介绍完毕。
下面看看本案例所涉及到的路径，和其他的环境配置。
1.1.3. 案例的环境配置
这个类的名字，在System.properties 配置文件的配置项为：
pet.dog.class=com.crazymakercircle.otherPet.pet.LittleDog
编译完成之后，存在在一个独立的路径中。
这个第三方类库的路径，为了可以灵活多变，并且与源代码工程的输出路径相不能相同，也在System.properties 配置文件增加配置项，具体为：
class.server.path=D:/疯狂创客圈 死磕java/code/out2/
为这方便读取，给这个两个配置项，增加其在对应在SystemConfig 配置类中的常量，具体如下：
package com.crazymakercircle.config;
@ConfigFileAnno(file = "/system.properties")
public class SystemConfig extends ConfigProperties
{
............
//第三方的类路径
@ConfigFieldAnno(proterty = "class.server.path")
public static String CLASS_SERVER_PATH;
//宠物狗的类型
@ConfigFieldAnno(proterty = "pet.dog.class")
public static String PET_DOG_CLASS;
............
}
编译完成LittleDog类后，将.class文件，复制到配置项%class.server.path% 所在的目录下。
至此，环境配置已经交代完毕。
下面马上进入正题。
1.1.4. FileClassLoader 案例实现步骤
自定义类加载器，首先要继承ClassLoader抽象类，并且重写其findClass()方法。
在重写的findClass()方法中，完成以下三步：
（1）在自己的地盘（查找路径），获取对应的字节码；
（2）并完成字节码到Class类对象的转变；
（3）返回Class类对象。
接下来，findClass()方法返回Class类对象之后，ClassLoader抽象类的代码，会将新返回Class类对象加载到缓存中，这个工作由抽象类ClassLoader加载器去完成。
1.1.5. FileClassLoader 的类设计
这里的自定义加载的名称为——FileClassLoader。
类图如下：
FileClassLoader的成员属性rootDir，用来存着自己的查找路径。当加载一个类时，如果所有的双亲加载器都没有加载到，就去rootDir下查找。
FileClassLoader重写了的findClass()方法。在这个重写方法中，首先会调用getClassData，在自己的地盘（查找路径），获取对应的字节码，返回字节码的二进制数组。
FileClassLoader增加了的getClassData()方法，这是其自己的私有方法。主要是找到类的二进制class文件，然后通过读取文件流的方式，读取文件的字节码，供findClass()重写方法使用。
1.1.6. FileClassLoader 的源码
简单粗暴，直接上源码。
package com.crazymakercircle.classLoader;
import java.io.*;
public class FileClassLoader extends ClassLoader {
private String rootDir;
public FileClassLoader(String rootDir) {
this.rootDir = rootDir;
}
public FileClassLoader(ClassLoader parent,String rootDir) {
super(parent);
this.rootDir = rootDir;
}
@Override
protected Class<?> findClass(String name)
throws ClassNotFoundException
{
byte[] classData = getClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
return defineClass(name, classData, 0, classData.length);
}
}
protected byte[] getClassData(String className)
{
String path = classNameToPath(className);
try {
InputStream ins = new FileInputStream(path);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 4096;
byte[] buffer = new byte[bufferSize];
int bytesNumRead = 0;
while ((bytesNumRead = ins.read(buffer)) != -1) {
baos.write(buffer, 0, bytesNumRead);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
protected String classNameToPath(String className) {
return rootDir + File.separatorChar
+ className.replace('.', File.separatorChar) + ".class";
}
}
案例路径：com.crazymakercircle.classLoader.ClassLoader
案例提示：无编程不创客、无案例不学习。一定记得看案例哦
上面的findClass()方法中，了调用defineClass()方法。这个方法是基类ClassLoader的方法，其作用是，将字节码导入到JVM的方法区内存，完成Class类对象加载、验证、准备、解析四步工作。 这个方法在编写自定义class loader的时候非常重要，它能将class二进制内容转换成Class对象，如果不符合要求的会抛出各种异常。
总结一下，自定义加载器的步骤为：
（1）编写一个类继承自ClassLoader抽象类。
（2）重写它的findClass()方法。
（3）在自己的地盘，获取对应的字节码；
（4）调用defineClass()方法，将字节码加载成Class对象，并且返回。
1.1.7. FileClassLoader 的使用
简单粗暴，先上代码：
public class FileLoaderDemo
{
public static void useFileLoader() {
try {
String baseDir = SystemConfig.CLASS_SERVER_PATH;
FileClassLoader fileClassLoader = new FileClassLoader(baseDir);
String className =SystemConfig.PET_DOG_CLASS;
Class dogClass = fileClassLoader.loadClass(className);
Logger.info("显示dogClass的ClassLoader =>");
ClassLoaderUtil.showLoader4Class(dogClass);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
useFileLoader();
}
}
上面的例子中，所加载的类为：
pet.dog.class=com.crazymakercircle.otherPet.pet.LittleDog
这个类是提前编译完成之后，放置在在一个独立的路径中，这个路径为：
class.server.path=D:/疯狂创客圈 死磕java/code/out2/
需要注意的是，这个路径不包括在当前工程的类路径%java.class.path%中。否则，自定义的加载器，是铁定加载不到的。
为什么呢？
依据双亲委托机制，包括在当前工程的类路径%java.class.path%中的类，会优先被AppClassLoader加载。因为自定义加载器的parent，默认就是AppClassLoader。
案例路径：com.crazymakercircle.classLoaderDemo.base.FileLoaderDemo
案例提示：无编程不创客、无案例不学习。一定要跑案例哦
运行的结果是：
showLoaderTree |> com.crazymakercircle.classLoader.FileClassLoader@2a18f23c
showLoaderTree |> sun.misc.Launcher$AppClassLoader@18b4aac2
showLoaderTree |> sun.misc.Launcher$ExtClassLoader@6fdb1f78
1.1.8. 不同类加载器的命名空间关系
同一个命名空间内的类是相互可见的。子加载器的命名空间包含所有父加载器的命名空间。因此子加载器加载的类能看见父加载器加载的类。例如系统类加载器加载的类能看见根类加载器加载的类。
由父加载器加载的类不能看见子加载器加载的类。
如果两个加载器之间没有直接或间接的父子关系，那么它们各自加载的类相互不可见。当两个不同命名空间内的类相互不可见时，可以采用Java的反射机制来访问实例的属性和方法。
这里，需要说明一下 Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。
即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。
下面看一段代码：
package com.crazymakercircle.classLoaderDemo.base;
public class LoaderedCompare
{
public static void showClassSame() {
try {
String baseDir = SystemConfig.CLASS_SERVER_PATH;
FileClassLoader fileClassLoader = new FileClassLoader(baseDir);
String className =SystemConfig.PET_DOG_CLASS;
Class dogClass = fileClassLoader.loadClass(className);
FileClassLoader classLoader2 = new FileClassLoader(baseDir);
Class dogClass2 = classLoader2.loadClass(className);
Logger.info("dogClass2.equals(dogClass) => ");
Logger.info( dogClass2.equals(dogClass));
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
showClassSame();
}
}
案例路径：com.crazymakercircle.classLoaderDemo.base.LoaderedCompare
案例提示：无编程不创客、无案例不学习。一定要跑案例哦
运行的结果是：
showClassSame |> dogClass2.equals(dogClass) => showClassSame |> false
上面的例子中，加载的是同样的字节码文件。甚至两个加载都是同一个类，只是是两个不同的类加载器对象。但是，加载完成之后，在内存中的Class对象，是不一样的。
1.1.9. 自定义加载器的两个要点
要点一：
如果一个自定义加载器创建时如果没有指定parent，那么它的parent默认就是AppClassLoader。
为什么呢？
原因是：如果默认的parent父加载器是AppClassLoader，这样就能够保证它能访问系统内置加载器加载成功的class文件。
要点二：
一般尽量不要重写ClassLoader抽象类的loadClass()方法，破坏其中的双亲委托的程序逻辑。
在JVM规范和JDK文档中（1.2或者以后版本中），都没有建议用户重写loadClass()方法，相比而言，明确提示开发者在开发自定义的类加载器时重写findClass()逻辑。
源码：
代码工程: classLoaderDemo.zip
下载地址：在疯狂创客圈QQ群文件共享。
疯狂创客圈：如果说Java是一个武林，这里的聚集一群武痴， 交流编程体验心得
QQ群链接：疯狂创客圈QQ群
无编程不创客，无案例不学习。 一定记得去跑一跑案例哦
类加载器系列全目录