一个类型被加载到虚拟机内存中开始,到卸载出内存为止、它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用、卸载七个阶段。其中验证、准备、解析为连接
REF_invokeStatic句柄对应的类没有被初始化则初始化。
2 . 只有当前程序访问的静态变量或静态方法确实在当前类或当前接口定义时,才可认为是对接口或类的主动使用。
3 . 调用 ClassLoader 类的 loadClass 方法加载一类,并不是对类的主动使用,不会导致类的初始化。
public class Test_2 extends Test_2_A {
static {
System.out.println("子类静态代码块");
}
{
System.out.println("子类代码块");
}
public Test_2() {
System.out.println("子类构造方法");
}
public static void main(String[] args) {
new Test_2();
}
}
class Test_2_A {
static {
System.out.println("父类静态代码块");
}
{
System.out.println("父类代码块");
}
public Test_2_A() {
System.out.println("父类构造方法");
}
public static void find() {
System.out.println("静态方法");
}
}
//代码块和构造方法执行顺序
//1).父类静态代码块
//2).子类静态代码块
//3).父类代码块
//4).父类构造方法
//5).子类代码块
//6).子类构造方法
public class Test_1 {
public static void main(String[] args) {
System.out.println(Test_1_B.str);
}
}
class Test_1_A {
public static String str = "A str";
static {
System.out.println("A Static Block");
}
}
class Test_1_B extends Test_1_A {
static {
System.out.println("B Static Block");
}
}
//输出结果
//A Static Block
//A str
在硬盘上查找并且通过 IO 读入字节码文件,使用到该类的时候才会被加载,例如调用 main 方法, new 关键字调用对象等,在加载阶段会在内存中生成这个类的 java.lang.Class
对象, 作为方法区这个类的各种数据的访问入口。
校验字节码文件的正确性
给类的静态变量分配内存,并且赋予默认值
将符号引用替换为直接引用,该节点会把一些静态方法(符号引用,比如 main() 方法)替换为指向数据所存内存的指针或句柄等(直接引用),这就是所谓的静态链接过程(类加载期间完成),动态链接是在程序运行期间完成的将符号引用替换为直接引用。
对类的静态变量初始化为指定的值,执行静态代码块。
<JAVA_HOME>\lib\
目录或者被 -Dbootclaspath
参数指定的类, 比如: rt.jar, tool.jar 等 。<JAVA_HOME>\lib\ext\
或 -Djava.ext.dirs
选项所指定目录下的类和 jar包。CLASSPATH
或 -Djava.class.path
所指定的目录下的类和 jar 包。测试文件:
public class TestJVMClassLoader {
public static void main(String[] args) {
System.out.println(String.class.getClassLoader());
System.out.println(DESKeyFactory.class.getClassLoader());
System.out.println(TestJVMClassLoader.class.getClassLoader());
System.out.println();
ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
ClassLoader extClassLoader = appClassLoader.getParent();
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println("bootstrapClassLoader: " + bootstrapClassLoader);
System.out.println("extClassLoader: " + extClassLoader);
System.out.println("appClassLoader: " + appClassLoader);
System.out.println();
System.out.println("bootstrapLoader 加载以下文件:");
URL[] urls = Launcher.getBootstrapClassPath().getURLs();
for (URL url : urls) {
System.out.println(url);
}
System.out.println();
System.out.println("extClassLoader 加载以下文件:");
System.out.println(System.getProperty("java.ext.dirs"));
System.out.println();
System.out.println("appClassLoader 加载以下文件:");
System.out.println(System.getProperty("java.class.path"));
}
}
一个类加载器收到了类加载的请求, 它首先不会自己去尝试自己去加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的请求最终都应该传送到最顶层的启动类加载器中,只有当父加载器反馈自己无法完成这个加载请求(即搜索范围中没有找到所需的类)时,子加载器才会尝试自己完成加载。
类加载和双亲委派模型如下图所示
我们再来看看 ClassLoader
类的 loadClass
方法
// loadClass
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先检查当前类是否被加载
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
// 如果父类类加载器不为空,先尝试父类加载来加载
c = parent.loadClass(name, false);
} else {
// 引导类加载器尝试加载
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
// 尝试自己加载
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
// 类加载器的包含关系
public abstract class ClassLoader {
private static native void registerNatives();
static {
registerNatives();
}
// 当前 ClassLoader 和 parent ClassLoader 的包含关系
private final ClassLoader parent;
}
总结:
Test
类,那么这个类加载器被称为定义类加载器,所有可能返回 Class 对象引用的类加载器(包括定义类加载器)都被称为初始类加载器。java.lang.Object
类, 也就是说在运行期, java.lang.Object 的这个类会被加载到 Java 虚拟机中,如果这个加载过程是由 Java 应用自己的类加载器所完成的,那么很有可能会在 JVM 中存在多个版本的 java.lang.Object 类,而且这些类之间还是不兼容的。互不可见的(正是命名空间发挥着作用)借助于双亲委托机制,Java 核心库中的类加载工作都是由启动类加载器统一来完成的。从而确保了Java 应用所使用的都是同一个版本的 Java 核心类库,他们之间是相互兼容的。自定义类加载器加载类,下面是一个简单的 Demo
import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
public class ClassLoaderTest extends ClassLoader {
private static String rxRootPath;
static {
rxRootPath = "/temp/class/";
}
@Override
public Class findClass(String name) {
byte[] b = loadClassData(name);
return defineClass(name, b, 0, b.length);
}
/**
* 读取 .class 文件为字节数组
*
* @param name 全路径类名
* @return
*/
private byte[] loadClassData(String name) {
try {
String filePath = fullClassName2FilePath(name);
InputStream is = new FileInputStream(new File(filePath));
ByteArrayOutputStream bos = new ByteArrayOutputStream();
byte[] buf = new byte[2048];
int r;
while ((r = is.read(buf)) != -1) {
bos.write(buf, 0, r);
}
return bos.toByteArray();
} catch (Throwable e) {
e.printStackTrace();
}
return null;
}
/**
* 全限定名转换为文件路径
*
* @param name
* @return
*/
private String fullClassName2FilePath(String name) {
return rxRootPath + name.replace(".", "//") + ".class";
}
public static void main(String[] args) throws ClassNotFoundException {
ClassLoaderTest classLoader = new ClassLoaderTest();
String className = "com.test.TestAA";
Class clazz = classLoader.loadClass(className);
System.out.println(clazz.getClassLoader());
// 输出结果
//cn.xxx.xxx.loader.ClassLoaderTest@3764951d
}
}
tomcat 的几个主要类加载器:
从图中的委派关系中可以看出:
Commonclassloader 能加载的类都可以被 Catalinaclassloader和 Sharedclassloadert 使用, 从而实现了公有类库的共用,而Catalinaclassloader 和 Sharedclassloader自己能加载的类则与对方相互隔离 Webappclassloader 可以使用 Shared Loader 加载到的类,但各个 Webappclassloader 实例之间相互隔离而 Jasper Loader 的加载范围仅仅是这个 JSP 文件所编译出来的那一个 . class 文件,它出现的目的就是为了被丢弃: 当 Web 容器检测到 JSP 文件被修改时,会替换掉目前的 Jasperloader 的实例,并通过再建立一个新的 Jsp 类加载器来实现 JSP 文件的热加载功能。
Tomcat这种类加载机制违背了java推荐的双亲委派模型了吗? 答案是: 违背了
tomcat不是这样实现, tomcat为了实现隔离性, 没有遵守这个约定, 每个 webapp Loader加载自己的目录下的 class'文件,不会传递给父类加载器,打破了双亲委派机制
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8