（1）<clinit>（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。如下：

public class Test {
    static{
        i = 0;//可以给变量赋值，编译通过
        System.out.println(i);//编译不通过！！不能进行访问后面的静态变量
    }
    static int i =1;
}

有点与我们平常的认知相反，这里是可以下赋值，却不能访问...
 （2）<clinit>（）方法与实例构造器<init>（）方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法执行之前，父类的<clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的<clinit>（）方法的类肯定是java.lang.Object。
 （3）<clinit>（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>（）方法。
 （4）接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成<clinit>（）方法。但是接口与类不同的是：执行接口的<clinit>（）方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>（）方法。
 （5）虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>（）方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>（）方法完毕。如果在一个类的<clinit>（）方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

4、类加载器

前面说过，在类加载过程的第一个阶段：加载阶段，除了可以使用系统提供的引导类加载器外，还可以使用用户自定义的类加载器，以便让用户决定如何去获取所需要的类（是从Class文件中？还是从jar、或者其他方式...可以自由决定）。

4.1 类和类加载器

任意一个类，都需要由加载它的类加载器和这个类本身共同确定其在Java 虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达的更通俗一些：比较两个类是否相等，只有在这两个类是同一个类加载器加载的前提下才意义。否则，即使这两个类来自同一个Class文件，被同一个虚拟机加载，但只要加载他们的类加载器不同，那这两个类就必定不相等。

这里的“相等”，包括代表类的 Class 对象的equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果，也包括 instanceof 关键字对对象所属关系判定等情况。下面代码演示了不同类加载器对 instanceof 关键字运算的结果的影响。

public class ClassLoaderTest {  
    public static void main(String[] args) throws Exception {  
        ClassLoader myLoader = new ClassLoader() {  
            @Override  
            public Class<> loadClass(String name)  
                    throws ClassNotFoundException {  
                try {  
                    String fileName = name.substring(name.lastIndexOf(".") + 1)  
                            + ".class";  
                    InputStream is = getClass().getResourceAsStream(fileName);  
                    if (is == null) {  
                        return super.loadClass(name);  
                    }  
                    byte[] b = new byte[is.available()];  
                    is.read(b);  
                    return defineClass(name, b, 0, b.length);  
                } catch (IOException e) {  
                    throw new ClassNotFoundException(name);  
                }  
            }  
        };  

        Class c = myLoader.loadClass("org.bupt.xiaoye.blog.ClassLoaderTest");  
        Object obj = c.newInstance();  
        System.out.println(obj.getClass());  
        System.out.println(ClassLoaderTest.class);  
        System.out.println(obj instanceof ClassLoaderTest);  

    }  
}

运行结果如下：class org.bupt.xiaoye.blog.ClassLoaderTest  class org.bupt.xiaoye.blog.ClassLoaderTest  false我们使用了一个自定义的类加载器去加载ClassLoaderTest，由第一句也可以看出这个对象也的确是ClassLoaderTest实例化出来的对象，但是这个对象在与类class org.bupt.xiaoye.blog.ClassLoaderTest 做属性检查的时候却反悔了false，这就是因为虚拟机中存在了两个ClassLoaderTest类，一个由系统应用程序类加载器加载，一个由我们自定义的类加载器加载，虽然是 来自同一个Class文件，但依然是两个独立的类。
因此，类是否相等，取决于类本身和加载该类的类加载器是否是同一个类加载器。

4.2 双亲委派模型

从虚拟机的角度来讲，只存在两种不同的类加载器：

    一种是启动类加载器（Bootstrap ClassLoader），这个类加载器用 C++  语言实现， 是虚拟机自身的一部分：

    另一种就是所有其它的类加载器， 这些类加载器用Java 语言实现，独立于虚拟机外部，并且全都继承与抽象类 java.lang.ClassLoader。

从Java 开发人员的角度来看，类加载器还可以划分的更细致一些，绝大多数Java 程序都会用到以下3种系统提供的类加载器：

   （1）启动类加载器（Bootstrap ClassLoader） ： 这个类加载器负责将存放在 <JAVA_HOME>\lib 目录中的，或者被 -Xbootclasspath 参数指定的路径中的，并且是虚拟机识别的(仅按照文件名识别,如rt.jar ，名字不符合类库不会加载) 类库加载到虚拟机内存中。启动类加载器无法被 java 程序直接引用，如需要，直接使用 null 代替即可。