目录

一、类加载做了哪些事？

二、类加载的顺序

三、一个具体说明的例子

四、类加载前和加载后的执行顺序（转自http://blog.csdn.net/mrzhoug/article/details/51581994）

一、类加载做了哪些事？

  之前没有进行类加载
 1.类加载,同时初始化类中静态的属性(赋默认值)
 2.执行静态代码块
 3.分配内存空间,同时初始化非静态的属性(赋默认值)
 4.如果声明属性的同时有显示的赋值,那么进行显示赋值把默认值覆盖
 5.执行匿名代码块
 6.执行构造器  
 7.返回内存地址

二、类加载的顺序

 1.static 变量
 2.static 代码块
 3.成员变量
 4.匿名块
 5.构造器
 ps:先加载父类,再加载子类;

三、一个具体说明的例子

其中D继承C，C继承B，E,F是单独的类，主方法在ExaminationDemo 中。

public class ExaminationDemo {
	public static void main(String[] args) {
		System.out.println("1运行 ExaminationDemo 中的 main 函数， 创建 D 类实例");
		new D();
	}
}

class E {
	// E的构造器
	E() {
		System.out.println("8执行 E 的构造函数");
	}

	// E的普通成员方法
	public void funcOfE() {
		System.out.println("12执行 E 的函数");
	}
}

class F {
	// F的构造器
	F() {
		System.out.println("2执行 F 的构造函数");
	}

	// F的普通成员方法
	public void funcOfF() {
		System.out.println("4执行 F 的函数");
	}
}

class B {
	//new了一个E对象
	E e = new E();
	//B的静态成员变量
	static F f = new F();
	//B的普通成员变量
	public String sb = getSb();
	//B的静态代码块
	static {
		System.out.println("3执行 B 类的 static 块(B 包含 E 类的成员 变量,包含静态 F 类成员变量)");
		f.funcOfF();
	}
	//B的匿名代码块
	{
		System.out.println("10执行 B 实例的普通初始化块");
	}
	//B的构造器
	B() {
		System.out.println("11执行 B 类的构造函数(B 包含 E 类的成员变 量,包含静态 F 类成员变量)");
	}
	//B的普通成员方法
	public String getSb() {
		System.out.println("9初始化 B 的实例成员变量 sb");
		return "sb";
	}
}

class C extends B {
	// C的静态代码块
	static {
		System.out.println("5执行 C 的 static 块(C 继承 B)");
	}
	// C的匿名代码块
	{
		System.out.println("13执行 C 的普通初始化块");
	}

	// C的构造器
	C() {
		System.out.println("14执行 C 的构造函数(C 继承 B)");
	}
}

class D extends C {
	// D的静态成员变量
	public String sd1 = getSd1();
	// D的普通成员变量
	public static String sd = getSd();
	// D的静态代码块
	static {
		System.out.println("7执行 D 的 static 块(D 继承 C)");
	}
	// D的匿名代码块
	{
		System.out.println("16执行 D 实例的普通初始化块");
	}
	// D的构造器
	D() {
		System.out.println("17执行 D 的构造函数(D 继承 C);父类 B 的实 例成员变量 sb 的值为：" + sb + ";本类 D 的 static 成员变量 sd 的值为：" + sd
				+ "; 本类 D 的实例成员变量 sd1 的值是：" + sd1);
	}
	// D的静态成员方法（调用时才加载）
	static public String getSd() {
		System.out.println("6初始化 D 的 static 成员变量 sd");
		return "sd";
	}
	// D的普通成员方法
	public String getSd1() {
		System.out.println("15初始化 D 的实例成员变量 sd1");
		return "sd1";
	}
}

从上面的代码我们可以看出，加载主方法时，先执行了输出语句，然后是new D（），由此进行加载顺序的分析。

执行结果如下:

/*
 * 1运行 ExaminationDemo 中的 main 函数， 创建 D 类实例 
 * 2执行 F 的构造函数 
 * 3执行 B 类的 static 块(B 包含 E类的成员 变量,包含静态 F 类成员变量) 
 * 4执行 F 的函数 
 * 5执行 C 的 static 块(C 继承 B) 
 * 6初始化 D 的 static 成员变量sd 
 * 7执行 D 的 static 块(D 继承 C) 
 * 8执行 E 的构造函数 
 * 9初始化 B 的实例成员变量 sb 
 * 10执行 B 实例的普通初始化块
 * 11执行 B 类的构造函数(B 包含 E 类的成员变 量,包含静态 F 类成员变量) 
 * 13执行 C 的普通初始化块 
 * 14执行 C 的构造函数(C 继承B) 
 * 15初始化 D 的实例成员变量 sd1 
 * 16执行 D 实例的普通初始化块 
 * 17执行 D 的构造函数(D 继承 C);父类 B 的实 例成员变量 sb的值为：sb;本类 D 的 static 成员变量 sd 的值为：sd; 本类 D 的实例成员变量 sd1 的值是：sd1
 */

这个结果是怎么来的，看下图：

总体上还是按照二的加载顺序来的，需要注意的是，当遇到子父类时，加载顺序是：

父类的静态成员变量，静态代码块——>子类的静态成员变量，静态代码块——>父类的普通成员变量，匿名代码块，构造器

——>子类的普通成员变量，匿名代码块，构造器

静态变量，和静态代码块的顺序先后，主要看谁先写，先写的先加载

new对象和成员变量的顺序，谁写在前面就先加载谁（我理解的是两者都属于成员变量）

成员方法不调用就不加载

而，当成员变量是方法时，就要调用该方法。

无论是静态成员方法，还是普通成员方法，只有在调用时才被加载

四、类加载前和加载后的执行顺序（转自http://blog.csdn.net/mrzhoug/article/details/51581994）

如果类还没有被加载： 
1、先执行父类的静态代码块和静态变量初始化，并且静态代码块和静态变量的执行顺序只跟代码中出现的顺序有关。 
2、执行子类的静态代码块和静态变量初始化。 
3、执行父类的实例变量初始化 
4、执行父类的构造函数 
5、执行子类的实例变量初始化 
6、执行子类的构造函数 

如果类已经被加载： 
则静态代码块和静态变量就不用重复执行，再创建类对象时，只执行与实例相关的变量初始化和构造方法。

引言

在日常工作中，比较少的机会会探究类加载机制，类加载顺序，但是这部分在代码优化，深入学习jvm有着极大的帮助，本文帮助不太了解类加载顺序的人从代码层级了解类加载顺序。

示例1-普通类

class Foo{
    private int x;
    {
        System.out.println("1");
    }
    static {
        System.out.println("2");
    }

    public Foo() {
        System.out.println("3");
        System.out.println("x=" + x + ",z=" + z);
    }

    public Foo(int x) {
        super();
        System.out.println("4");
        this.x = x;
    }

    static int z = 8;

    public void say() {
        System.out.println("5");
    }

    public static void say2() {
        {
            System.out.println("6");
        }
        System.out.println("7");
    }
}
public class App {
    public static void main(String[] args) {
       Foo.say2(); 
    }
}

很多人拿到这样的代码就会打颤，别着急，接着向下看，如果你耐心读完此文，相信再遇到此类的问题，乃至面试题都会如鱼得水，整理的头头是道！

java类中包含的成员

首先，我们了解一下java类中包含的成员有哪些

类实例化顺序

了解了类的成员信息后，下面讲下类实例化顺序

1. 执行静态块
2. 执行构造代码块（构造代码块一定在构造器前执行）
3. 执行构造器

了解了这些之后，可能有些细心地童鞋会有疑问，还有静态成员变量呢？普通成员变量呢？他们什么时候执行？
我们可以把静态成员变量看做静态块，普通成员变量看做构造代码块来处理，这样是不是简单很多。

类加载的顺序

1. 调用构造器
2. class.forname
3. 调静态字段
4. 调静态方法

public class AppTest {
    public static void main(String[] args) {
        f1();
    }

    static AppTest t = new AppTest();
    static {
        System.out.println("1");
    }
    {
        System.out.println("2");
    }

    AppTest() {
        System.out.println("3");
        System.out.println("a=" + a + ",b=" + b);
    }

    public static void f1() {
        System.out.println("4");
    }

    int a = 110;
    static int b = 112;
}

类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，

内部类

(1)、内部类仍然是一个独立的类，在编译之后内部类会被编译成独立的.class文件，但是前面冠以外部类的类名和$符号 。
(2)、内部类不能用普通的方式访问。内部类是外部类的一个成员，因此内部类可以自由地访问外部类的成员变量，无论是否是private的 。
(3)、内部类声明成静态的，就不能随便的访问外部类的成员变量了，此时内部类只能访问外部类的静态成员变量 。

子类C继承父类F

当调用子类静态方法时，执行顺序为

1. 按照继承顺序从顶级父类开始加载类
2. 执行子类C中的静态块
3. 执行子类静态块
4. 执行调用方法

当调用子类非静态方法

1. 初始化（加载）所有超类
2. 加载自身静态块
3. 再次初始化所有超类及自身
4. 执行调用方法

解释

1. 按照继承顺序从顶级父类开始所加载类（按照顶级类到子类开始把相关类加载进内存中）
2. 因为使用了new，所以会创建一个全新的子类对象，所以之前的超类由于连带关系均需要为了创建新的子类对象而再次执行一遍类加载，但是静态块已经加载完毕，无需再次加载，所以此时仅加载构造代码块和构造器
3. 得到引用对象，执行代码

接口

1. 在有继承关系的类中引用多个不同接口时，需要注意接口内定义的常量名称不可重复，如果重复在调用常量时，编译器会提示The field Father.v is ambiguous（所使用的字段不明确）
2. 接口内的常量初始化是在被调用时初始化，当且仅当仅调用接口中的某常量时，运行且不会影响实现接口的类，例如类Foo实现了接口Bar，Bar中有常量S，使用Foo.S仅会初始化S，不会调用Foo内部任何成员。

Tomcat的类加载顺序的实现

  其实之所以为写这篇文章的原因，主要是前段时间，因为使用第三方的一些库，需要将这些库放到JDK的ext目录，由Java的ExtClassLoader进行加载，第三方库也是用了日志框架，而且使用的是slf4j,所以要使用这个第三方库，必须将slf4j-api.jar这个slf4j的接口包放到ext目录下。将这个日志放到slf4j-api.jar放到ext目录下，接着应用层的日志打印不出来，应用层的日志包也是使用slf4j,应用是在Tomcat中跑的。

为什么打印不了日志

  上面的问题，在Debug日志包和查找类加载相关的资料，最终发现与类加载相关；实际上一直使用的slf4j-api.jar是ext目录下，而它的实现包在应用层，即项目中引入的，ExtClassLoader加载的slf4j-api.jar日志包，根据类加载的特性不允许向下查找到它的实现包slf4j-simple.jar,所以实际上就会找不到实现，导致日志打印不出来问题。如下示意图，这是类加载的特性和顺序决定的，具体可以参考另外一篇关于Java的类加载器的文章：https://blog.csdn.net/strive_or_die/article/details/98664519。

Tomcat的类加载机制

应用服务器一般都会自行创建类加载器来实现更加灵活的控制，Tomcat服务器也不例外。

• 隔离性：Web应用类库互相隔离，避免依赖库或者应用包相互影响。因为一个Tomcat服务器可以跑多个应用，不同的应用对于同一个包所依赖的版本可能不一样，例如有的slf4j-api包的版本是1.6.x，而有的应用是1.8.x，那么这样必然会导致部分应用的日志无法打印。
• 灵活性：Web应用之间的类加载器互相独立，那么就可以针对一个Web应用进行重新部署，此时Web应用的类加载器会重新创建并且不会影响其他Web应用。
• 性能：由于每个Web应用都有一个类加载器，因此Web应用在加载类时，不会搜索其他Web应用包含的Jar包，这样性能是比只有一个累加器的情况要好的。

先看一下Tomcat的类加载器的图示:

  从上图中可以看到，除了每个Web应用加载器外，Tomcat也提供了3个基础的类加载器，这3个类加载器指向的路径和包列表都可以再catalina.properties中配置。

• Common Class Loader:以System类加载器为父类加载器，位于Tomcat应用夫妻顶层的公用类加载器。它的路径为commmon.loader，默认指向的是$CATALINA_HOME/lib下的包。
• Catalina Class Loader:以Common类加载器为父类加载器，用于加载Tomcat应用服务器的累加器，其路径为server.loader,默认为空。此时Tomcat使用Common类加载器加载器应用服务器。
• Shared Class Loader:以Common类加载器为父类加载器，是所有父类应用加载器的父类加载器，其路径为为shared.loader,默认为空，此时此时Tomcat使用Common类加载器作为Web应用的父类加载器。
• Web Application Class Loader:以Shared为父类加载器，加载/WEB-INF/classes目录下的未压缩的Class和资源文件以及/WEB-INF/lib目录下的Jar包。特别注意:该类加载器只对当前Web应用可见，对其他Web应用都不可见。

  首先，Common类加载器负责加载Tomcat的应用服务器了内部和Web应用均可见得类，例如Servlet相关包和一些通用的工具包。

  其次，Catalina类加载器负责加载只有Tomcat应用服务器内部可见的类，这些类对Web应用不可见。如Tomcat的具体实现类，因为我们的Web应用最好和服务器松耦合。

  再次，Shared累加器负责加载Web应用共享的类，这些类Tomcat服务器不会依赖。

  最后，Tomcat服务器$CATALINA_HOME/bin目录下的包作为启动入口由System类加载器加载。通过将者几个启动包剥离，Tomcat简化了应用服务器的启动，同时增加了灵活性。

Web应用类加载器顺序（关键）

Tomcat的默认加载机制是委派模式，委派过程如下。

• 1.从缓存中加载
• 2.如果缓存中没有，则从父类加载器中加载。
• 3.如果父类加载器没有，则从当前类加载器加载。
• 4.如果没有，则抛出异常。

  Tomcat提供的Eeb应用类加载器和默认的委派模型有些地方是不同的。当进行类加载是，除了JVM基础类库外，他首先会尝试通过当前累加器加载，然后才进行委派。另外一点需要注意的是：Servlet规范相关API禁止通过Web应用类加载器加载，因此，不要在Web应用中包含这些包，例如javax.servlet-api.jar。

Web应用加载器默认加载顺序如下：

• 1.从缓存中加载
• 2.如果没有，则从扩展类加载器和Bootstrap类加载器中加载。
• 3.如果没有，则从当前类加载器加载（按照WEB-INF/classes、WEB-INF/lib的顺序）。
• 4.如果没有，则从父类加载器加载，由于父类加载器采用默认的委派模型，所以加载顺序为System、Common、Shared。

  Tocmat提供了delegate属性用于控制是否启用Java委派模型，默认为false(不启用)。当配置为true时，Tomcat将使用默认委派模型，即按如下顺序加载。

• 1.从缓存中加载
• 2.如果没有，则从扩展类加载器和Bootstrap类加载器中加载。
• 3.如果没有，则从父类加载器加载，加载顺序为System、Common、Shared。
• 4.如果没有，则从当前类加载器加载（按照WEB-INF/classes、WEB-INF/lib的顺序）。

如何解决日志包加载问题

  通过前面的Tomcat的类加载器知识，我们可以知道为啥那个在ext目录下的slf4j-api.jar会使得应用的jar打印不出来，因为即使Tomcat实现了自己的类加载器，但是对于Web应用类加载器来说，扩展类加载器和Bootstrap类加载器是优先于它进行加载的，所以应用中的slf4j-api.jar实际并没有被加载，ext目录下的被加载了，但是正常的类加载是没法实现父类加载器向子类加载器方向去寻找实现的，所以slf4j-api.jar找不到实现了，打印不出日志。

  那该怎么解决呢，有了上面的知识，我们可以知道如果Tomcat的delegate属性为false时，这也是默认值来的，Web应用加载器优先于System、Common、Shared类加载器，那么我们可以将第三方库和它所以来的slf4j-api.jar包移动到Common类加载器加载的目录$CATALINA_HOME/lib下，那么就可以保证使用的slf4j-api.jar是应用中引入的了，这样我们的应用就可以打印出日志了。特别注意：这时候的第三方库的日志是打印不出来的，因为它依旧没法找到它的日志实现包，除非将它的实现包也放到$CATALINA/lib下。

参考

Tomcat 架构解析 刘光瑞 著.
https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html