java类静态域、块，非静态域、块，构造函数的初始化顺序

面试的时候，经常会遇到这样的考题：给你两个类的代码，它们之间是继承的关系，每个类里只有构造器方法和一些变量，

构造器里可能还有一段代码对变量值进行了某种运算，另外还有一些将变量值输出到控制台的代码，然后让我们判断输出的
结果。这实际上是在考查我们对于继承情况下类的初始化顺序的了解。 
我们大家都知道，对于静态变量、静态初始化块、变量、初始化块、构造器，它们的初始化顺序以此是 
（静态变量、静态初始化块）>（变量、初始化块）>构造器。 
我们也可以通过下面的测试代码来验证这一点：  
Java代码 

 

运行以上代码，我们会得到如下的输出结果： 
静态变量  
静态初始化块  
变量  
初始化块  
构造器 
这与上文中说的完全符合。 
那么对于继承情况下又会怎样呢？我们仍然以一段测试代码来获取最终结果： 
Java代码 

 运行一下上面的代码，结果马上呈现在我们的眼前： 

父类--静态变量  
父类--静态初始化块  
子类--静态变量  
子类--静态初始化块  
父类--变量  
父类--初始化块  
父类--构造器  
子类--变量  
子类--初始化块  
子类--构造器 
现在，结果已经不言自明了。大家可能会注意到一点，那就是，并不是父类完全初始化完毕后才进行子类的初始化， 
实际上子类的静态变量和静态初始化块的初始化是在父类的变量、初始化块和构造器初始化之前就完成了。 
那么对于静态变量和静态初始化块之间、变量和初始化块之间的先后顺序又是怎样呢？ 
是否静态变量总是先于静态初始化块，变量总是先于初始化块就被初始化了呢？实际上这取决于它们在类中出现的先后顺序。 
我们以静态变量和静态初始化块为例来进行说明。 同样，我们还是写一个类来进行测试：    
Java代码 

 运行上面的代码，会得到如下的结果： 

Test--A  
静态初始化块  
Test--B 
大家可以随意改变变量a、变量b以及静态初始化块的前后位置，就会发现输出结果随着它们在类中出现的前后顺序而改变， 
这就说明静态变量和静态初始化块是依照他们在类中的定义顺序进行初始化的。同样，变量和初始化块也遵循这个规律。 
了解了继承情况下类的初始化顺序之后，如何判断最终输出结果就迎刃而解了。  
测试函数：  

 运行结果： 

父类的非静态代码块在执行a=10 
!!!!!!!!!!!!!!!!!!!!! 
父类的非静态代码块在执行a=8 
a在父类带参构造方法中的值：10 
8 
8 
父类无参构造方法在执行a=8  
  
结论：静态代码块是在类加载时自动执行的，非静态代码块是在创建对象时自动执行的代码，不创建对象不执行该类的非静态代码块。且执行顺序为静态代码块------非静态代码块----构造函数。 
扩展：静态代码块  与  静态方法： 
一般情况下,如果有些代码必须在项目启动的时候就执行的时候,需要使用静态代码块,这种代码是主动执行的; 
需要在项目启动的时候就初始化,在不创建对象的情况下,其他程序来调用的时候,需要使用静态方法,这种代码是被动执行的.  
两者的区别就是:静态代码块是自动执行的;  静态方法是被调用的时候才执行的.  

作用:静态代码块可用来初始化一些项目最常用的变量或对象;静态方法可用作不创建对象也可能需要执行的代码

阿里笔试题：

求下面这段代码的输出：

 运行结果：

1:j    i=0    n=0
2:构造块    i=1    n=1
3:t1    i=2    n=2
4:j    i=3    n=3
5:构造块    i=4    n=4
6:t2    i=5    n=5
7:i    i=6    n=6
8:静态块    i=7    n=99
9:j    i=8    n=100
10:构造块    i=9    n=101
11:init    i=10    n=102

 

Java类的加载

Java类的加载是由类加载器来完成的。一般来说，类加载器分成两类：启动类加载器（bootstrap）和用户自定义的类加载器（user-defined）。两者的区别在于启动类加载器是由JVM的原生代码实现的，而用户自定义的类加载器都继承自Java中的java.lang.ClassLoader类。在用户自定义类加载器的部分，一般JVM都会提供一些基本实现。应用程序的开发人员也可以根据需要编写自己的类加载器。JVM中最常使用的是系统类加载器（system），它用来启动Java应用程序的加载。通过java.lang.ClassLoader的getSystemClassLoader()方法可以获取到该类加载器对象。

类加载器需要完成的最终功能是定义一个Java类，即把Java字节代码转换成JVM中的java.lang.Class类的对象。但是类加载的过程并不是这么简单。Java类加载器有两个比较重要的特征：层次组织结构和代理模式。层次组织结构指的是每个类加载器都有一个父类加载器，通过getParent()方法可以获取到。类加载器通过这种父亲-后代的方式组织在一起，形成树状层次结构。代理模式则指的是一个类加载器既可以自己完成Java类的定义工作，也可以代理给其它的类加载器来完成。由于代理模式的存在，启动一个类的加载过程的类加载器和最终定义这个类的类加载器可能并不是一个。前者称为初始类加载器，而后者称为定义类加载器。两者的关联在于：一个Java类的定义类加载器是该类所导入的其它Java类的初始类加载器。比如类A通过import导入了类 B，那么由类A的定义类加载器负责启动类B的加载过程。

类加载器的一个重要用途是在JVM中为相同名称的Java类创建隔离空间。在JVM中，判断两个类是否相同，不仅是根据该类的二进制名称，还需要根据两个类的定义类加载器。只有两者完全一样，才认为两个类的是相同的。因此，即便是同样的Java字节代码，被两个不同的类加载器定义之后，所得到的Java类也是不同的。如果试图在两个类的对象之间进行赋值操作，会抛出java.lang.ClassCastException。这个特性为同样名称的Java类在JVM中共存创造了条件。在实际的应用中，可能会要求同一名称的Java类的不同版本在JVM中可以同时存在。通过类加载器就可以满足这种需求。这种技术在OSGi中得到了广泛的应用。

Java类的链接

Java类的链接指的是将Java类的二进制代码合并到JVM的运行状态之中的过程。在链接之前，这个类必须被成功加载。类的链接包括验证、准备和解析等几个步骤。验证是用来确保Java类的二进制表示在结构上是完全正确的。如果验证过程出现错误的话，会抛出java.lang.VerifyError错误。准备过程则是创建Java类中的静态域，并将这些域的值设为默认值。准备过程并不会执行代码。在一个Java类中会包含对其它类或接口的形式引用，包括它的父类、所实现的接口、方法的形式参数和返回值的Java类等。解析的过程就是确保这些被引用的类能被正确的找到。解析的过程可能会导致其它的Java类被加载。

不同的JVM实现可能选择不同的解析策略。一种做法是在链接的时候，就递归的把所有依赖的形式引用都进行解析。而另外的做法则可能是只在一个形式引用真正需要的时候才进行解析。也就是说如果一个Java类只是被引用了，但是并没有被真正用到，那么这个类有可能就不会被解析。考虑下面的代码：

public class LinkTest {   
   public static void main(String[] args) {       
      ToBeLinked toBeLinked = null;       
      System.out.println("Test link.");   
   }
}

类 LinkTest引用了类ToBeLinked，但是并没有真正使用它，只是声明了一个变量，并没有创建该类的实例或是访问其中的静态域。在 Oracle的JDK 6中，如果把编译好的ToBeLinked的Java字节代码删除之后，再运行LinkTest，程序不会抛出错误。这是因为ToBeLinked类没有被真正用到，而Oracle的JDK 6所采用的链接策略使得ToBeLinked类不会被加载，因此也不会发现ToBeLinked的Java字节代码实际上是不存在的。如果把代码改成ToBeLinked toBeLinked = new ToBeLinked();之后，再按照相同的方法运行，就会抛出异常了。因为这个时候ToBeLinked这个类被真正使用到了，会需要加载这个类。

Java类的初始化

当一个Java类第一次被真正使用到的时候，JVM会进行该类的初始化操作。初始化过程的主要操作是执行静态代码块和初始化静态域。在一个类被初始化之前，它的直接父类也需要被初始化。但是，一个接口的初始化，不会引起其父接口的初始化。在初始化的时候，会按照源代码中从上到下的顺序依次执行静态代码块和初始化静态域。考虑下面的代码：

public class StaticTest {   
   public static int X = 10;   
   public static void main(String[] args) {       
      System.out.println(Y); //输出60   
   }   
   static {       
      X = 30;   
   }  
   public static int Y = X * 2;
}

在上面的代码中，在初始化的时候，静态域的初始化和静态代码块的执行会从上到下依次执行。因此变量X的值首先初始化成10，后来又被赋值成30；而变量Y的值则被初始化成60。

Java类和接口的初始化只有在特定的时机才会发生，这些时机包括：

• 创建一个Java类的实例。如

  MyClass obj = new MyClass()

• 调用一个Java类中的静态方法。如

  MyClass.sayHello()

• 给Java类或接口中声明的静态域赋值。如

  MyClass.value = 10

• 访问Java类或接口中声明的静态域，并且该域不是常值变量。如

  int value = MyClass.value

• 在顶层Java类中执行assert语句。

通过Java反射API也可能造成类和接口的初始化。需要注意的是，当访问一个Java类或接口中的静态域的时候，只有真正声明这个域的类或接口才会被初始化。考虑下面的代码：

class B {   
   static int value = 100;   
   static {       
      System.out.println("Class B is initialized."); //输出   
   }
}
class A extends B {   
   static {       
      System.out.println("Class A is initialized."); //不会输出   
   }
}
public class InitTest {   
   public static void main(String[] args) {       
      System.out.println(A.value); //输出100   
   }
}

在上述代码中，类InitTest通过A.value引用了类B中声明的静态域value。由于value是在类B中声明的，只有类B会被初始化，而类A则不会被初始化。

创建自己的类加载器

在 Java应用开发过程中，可能会需要创建应用自己的类加载器。典型的场景包括实现特定的Java字节代码查找方式、对字节代码进行加密/解密以及实现同名 Java类的隔离等。创建自己的类加载器并不是一件复杂的事情，只需要继承自java.lang.ClassLoader类并覆写对应的方法即可。 java.lang.ClassLoader中提供的方法有不少，下面介绍几个创建类加载器时需要考虑的：

• defineClass()：这个方法用来完成从Java字节代码的字节数组到java.lang.Class的转换。这个方法是不能被覆写的，一般是用原生代码来实现的。
• findLoadedClass()：这个方法用来根据名称查找已经加载过的Java类。一个类加载器不会重复加载同一名称的类。
• findClass()：这个方法用来根据名称查找并加载Java类。
• loadClass()：这个方法用来根据名称加载Java类。
• resolveClass()：这个方法用来链接一个Java类。

这里比较 容易混淆的是findClass()方法和loadClass()方法的作用。前面提到过，在Java类的链接过程中，会需要对Java类进行解析，而解析可能会导致当前Java类所引用的其它Java类被加载。在这个时候，JVM就是通过调用当前类的定义类加载器的loadClass()方法来加载其它类的。findClass()方法则是应用创建的类加载器的扩展点。应用自己的类加载器应该覆写findClass()方法来添加自定义的类加载逻辑。 loadClass()方法的默认实现会负责调用findClass()方法。

前面提到，类加载器的代理模式默认使用的是父类优先的策略。这个策略的实现是封装在loadClass()方法中的。如果希望修改此策略，就需要覆写loadClass()方法。

下面的代码给出了自定义的类加载的常见实现模式：

public class MyClassLoader extends ClassLoader {   
   protected Class<?> findClass(String name) throws ClassNotFoundException {       
      byte[] b = null; //查找或生成Java类的字节代码       
	  return defineClass(name, b, 0, b.length);   
   }
}

参考资料

• Java语言规范（第三版）- 第十三章：执行
• JVM规范（第二版） - 第五章：加载、链接和初始化

• 深入探讨Java类加载器
• http://www.infoq.com/cn/articles/cf-Java-class-loader