目录
文章内容
这几天学习JVM:从类的加载过程到类的主动使用和被动使用再到JVM类加载器类型。
很难避免出现包名,类名相同的情况,怎么办?import谁?--->
统一类的加载 <------双亲委派机制------> 都加载不上? 抛出异ClassNotFoundException
类加载器有何应用? 为什么要破坏双亲委派机制? 用什么破坏??
类的加载过程
1.加载
查找并加载类的二进制数据。
这一步是程序能控制的,通过类加载器实现。
2. 连接
1. 验证: 确保被加载的类的正确性。
2. 准备: 为类的静态变量分配内存,并将其初始化为默认值。
3. 解析: 把类中的符号引用转换为直接引用(比如常量池中的引用替换为实际使用)。
3. 初始化
为类的静态变量赋予正确的初始。
值
4. 使用,就是指的new。
5. unloading从jvm中移除此实例。
类的主动使用和被动使用
JVM启动后,对类的初始化是一个延迟的机制,即Java虚拟机实现必须在每个类或接口被Java程序“首次主动使用”时才初始化他们。
六种主动使用类的场景
1. 创建类的实例
2. 访问某个类或接口的静态变量,或者对该静态变量赋值
3. 调用类的静态方法
4. 反射:Class.forName() xxx.newInstance()
5. 初始化一个类的子类( 但直接通过子类使用父类的静态变量只会导致父类的初始化,子类不会初始化 )
6. 启动类
除以上六种情况都称为被动使用,不会导致类的加载和初始化.
1. 构造某个类的数组不会引起该类的初始化.
X[] arrs=new X[10]; // X不会初始化
2. 引用类的静态常量不会导致类的初始化
JVM类加载器(class loader)
类加载器的定义
类加载器把.class文件加载到JVM的方法区中,变成一个Class对象。
结构图
启动类加载器(Bootstrap ClassLoader)
负责加载JAVA_HOME\jre\lib目录中并且能被虚拟机识别的类库到JVM内存中,如果名称不符合的类库即使放在lib目录中也不会被加载。该类加载器无法被Java程序直接引用。
可以通过 -Xbootclasspath指定, 也可以通过系统属性 sum.boot.class.path 获取当前根加载器加载的资源
C++编写
扩展类加载器(Extension ClassLoader)
该加载器主要是负责加载JAVA_HOME\jre\lib\ext,该加载器可以被开发者直接使用。
java编写
类名为: sun.misc.Launcher$ExtClassLoader
通过 java.ext.dirs获得加载情况
//扩展类加载器
System.out.println(System.getProperty("java.ext.dirs"));
也可以将自己的类打包jar包,放到此目录。 此时它的类加载器就是扩展类加载器了.
应用程序类加载器(Application ClassLoader)
该类加载器也称为系统类加载器,它负责加载用户类路径(Classpath)上所指定的类库,开发者可以直接使用该类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
加载路径通过 -classpath 指定. 通过 java.class.path获取
sun.misc.Launcher$AppClassLoader
自定义的类加载器 (User ClassLoader)
若要实现自定义类加载器,只需要继承java.lang.ClassLoader 类,并且重写其findClass()方法即可。
双亲委托机制
一个加载器在加载一个类的时候( loadClass ),都要先使用它的父类加载器去加载这个类,如果它的父类加载器可以加载这个类,那么就用父类加载器加载这个类,否则自己加载这个类。
原理图:
优点
java类随着它的类加载器一起具备了带有优先级的层次关系,保证java程序稳定运行。
例如 java.lang.Object这个类位于 jre/lib/rt.jar包中,这个包所有的类加载器都要加载它,从而保证了所有的java程序的统一性。
类加载器的应用
1.Tomcat的容器隔离等
2.andriod的在线更新
3.热部署(热替换)
4.代码保护
5.加解密
6.包的隔离
7.框架
8.引擎
线程上下文类加载器
问题
Java 提供了很多服务提供者接口(Service Provider Interface,SPI),允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。
这些 SPI 的接口由 Java 核心库来提供,而这些 SPI 的实现代码则是作为 Java 应用所依赖的 jar 包被包含进类路径(CLASSPATH)里。SPI接口中的代码经常需要加载具体的实现类。那么问题来了,SPI的接口是Java核心库的一部分,是由根启动类加载器(Bootstrap Classloader)来加的;SPI的实现类是由系统类加载器(System ClassLoader)来加载的。引导类加载器是无法找到 SPI 的实现类的,因为依照双亲委派模型,BootstrapClassloader无法委派AppClassLoader来加载类。
解决方案
线程上下文类加载器破坏了“双亲委派模型”,可以在执行线程中抛弃双亲委派加载链模式,使程序可以逆向使用类加载器。