Java类加载的过程 ----双亲委派

Java类加载

类的生命周期

验证,准备,解析都属于连接

类加载的过程

加载

类加载过程的第一步，主要完成下面3件事情：

1. 通过全类名获取定义此类的二进制字节流
2. 将字节流所代表的静态存储结构转换为方法区的运行时数据结构
3. 在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口

类加载机制：双亲委派机制

• 向上委托：AppClassLoader(系统类加载器) - > ExtClassLoader(扩展类加载器) - > BootStrapClassLoader(引导类加载器)
• BootStrapClassLoader 加载器由C++实现，加载的是<CLASS_HOME>/lib
• ExClassLoader 加载的是<CLASS_HOME>/lib/ext
• AppClassLoader 加载的是 java -classpath
• 双亲委派机制：类加载器收到类加载请求，自己不能加载，得向上委托给父加载器加载，父加载器加载不了再自己加载

如何认定俩个对象同属于一个类型

1. 由同名的类完成实例化
2. 俩个实例各自对应的同名的类的加载器必须是同一个

双亲委派机制的优点：

1. 保护程序的安全，保证JDK核心类的优先加载，避免Java核心API篡改
2. 避免类的重复加载，确保一个类的全局唯一性

双亲委派机制的缺点：

1. 加载的委托过程是单向的，顶层的ClassLoader无法访问底层 的ClassLoader所加载的类

双亲委派机制的破坏

第一次破坏 ：findClass()方法
在JDK 1.2之后 ClassLoader类中增加了一个新的protected方法findClass()，并引导用户编写类加载器的时候，尽量去重写这个方法，而不是在loadClass()中编写代码。按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载。

第二次破坏 ：线程上下文类加载器
引用线程上下文类加载器，这个类加载器可以通过Thread的setContextClassLoader()方法进行设置，如果创建线程时还未设置，他将会从父线程中继承一个。
有了上下文类加载器，JNDI服务就可以通过他来加载所需的代码
采用这种方式的有：JNDI，JDBC，JCE，JAXB等

默认上下文加载器就是应用类加载器，这样以上下文加载器为中介，使得启动类加载器中的代码也可以访问应用器中的类

第三次破坏 ：热部署 委派机制由树状结构变为网状结构
每一个程序模块(Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。
类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构，当受到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1）将java.＊开头的类委派给父类加载器加载。
2）否则，将委派列表名单内的类委派给父类加载器加载。
3）否则，将Import列表中的类委派给Export这个类的Bundle的类加载器加载。
4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7）否则，类加载器失败。

自定义类加载器

为什么要自定义类加载器

1. 隔离加载类
   - 例如 tomcat内部自定义了好几种加载器，用来隔离同一个web应用服务器上的不同应用程序
2. 修改类加载的方式
3. 扩展加载源
4. 防止源码泄漏
   - Java代码容易被编译和篡改，可以进行编译加密，那么类也需要自定义，还原加密的字节码