JAVA工作方式
源程序(myProgram.java) – > 编译(javac myProgram.java) -> JAVA字节码(myProgram.class) ->运行(java myProgram)
JAVA的程序结构
源文件>类>方法>语句（source file > class > method > statement）
JDK、JRE、JVM的区别
- JVM（Java Virtual Machine）：JAVA虚拟机
- JDK（Java Developer’s Kit）：Java开发工具包
- JRE（Java runtime environment）：Java 运行环境
JVM主要包括四个部分
1.类加载器（ClassLoader）:在JVM启动时或者在类运行时将需要的class加载到JVM中。 2.执行引擎：负责执行class文件中包含的字节码指令 3.内存区（也叫运行时数据区）：是在JVM运行的时候操作所分配的内存区。运行时内存区主要可以划分为5个区域，如图： 
方法区(Method Area)：用于存储类结构信息的地方，包括常量池、静态变量、构造函数等。虽然JVM规范把方法区描述为堆的一个逻辑部分， 但它却有个别名non-heap（非堆），所以大家不要搞混淆了。方法区还包含一个运行时常量池。
java堆(Heap)：存储java实例或者对象的地方。这块是GC的主要区域（后面解释）。从存储的内容我们可以很容易知道，方法区和堆是被所有java线程共享的。
java栈(Stack)：java栈总是和线程关联在一起，每当创建一个线程时，JVM就会为这个线程创建一个对应的java栈。在这个java栈中又会包含多个栈帧，每运行一个方法就创建一个栈帧，用于存储局部变量表、操作栈、方法返回值等。每一个方法从调用直至执行完成的过程，就对应一个栈帧在java栈中入栈到出栈的过程。所以java栈是现成私有的。
程序计数器(PC Register)：用于保存当前线程执行的内存地址。由于JVM程序是多线程执行的（线程轮流切换），所以为了保证线程切换回来后，还能恢复到原先状态，就需要一个独立的计数器，记录之前中断的地方，可见程序计数器也是线程私有的。
- 本地方法栈(Native Method Stack)：和java栈的作用差不多，只不过是为JVM使用到的native方法服务的
4.本地方法接口：主要是调用C或C++实现的本地方法及返回结果。 JVM在整个JDK中处于最底层，负责与操作系统的交互，用来屏蔽操作系统环境，提供一个王正的Java运行环境，因此也称为虚拟计算机。操作系统装入JVM是通过JDK中的java.exe来实现，主要以下几步： 1.创建jvm装载环境和配置 2.装载jvm.dll 3.初始化jvm.dll 4.调用JNIEnv实例装载并处理class类 5.运行java程序
JVM初识及工作原理
1）类加载子系统负责从文件系统或者网络中加载Class信息，加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中可能还会存放运行时常量池信息，包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）。 2）java堆在虚拟机启动的时候建立，它是java程序最主要的内存工作区域。几乎所有的java对象实例都存放在java堆中。堆空间是所有线程共享的，这是一块与java应用密切相关的内存空间。 3）java的NIO库允许java程序使用直接内存。直接内存是在java堆外的、直接向系统申请的内存空间。通常访问直接内存的速度会优于java堆。因此出于性能的考虑，读写频繁的场合可能会考虑使用直接内存。由于直接内存在java堆外，因此它的大小不会直接受限于Xmx指定的最大堆大小，但是系统内存是有限的，java堆和直接内存的总和依然受限于操作系统能给出的最大内存。 4）垃圾回收系统是java虚拟机的重要组成部分，垃圾回收器可以对方法区、java堆和直接内存进行回收。其中，java堆是垃圾收集器的工作重点。和C/C++不同，java中所有的对象空间释放都是隐式的，也就是说，java中没有类似free()或者delete()这样的函数释放指定的内存区域。对于不再使用的垃圾对象，垃圾回收系统会在后台默默工作，默默查找、标识并释放垃圾对象，完成包括java堆、方法区和直接内存中的全自动化管理。 5）每一个java虚拟机线程都有一个私有的java栈，一个线程的java栈在线程创建的时候被创建，java栈中保存着帧信息，java栈中保存着局部变量、方法参数，同时和java方法的调用、返回密切相关。 6）本地方法栈和java栈非常类似，最大的不同在于java栈用于方法的调用，而本地方法栈则用于本地方法的调用，作为对java虚拟机的重要扩展，java虚拟机允许java直接调用本地方法（通常使用C编写） 7）PC（Program Counter）寄存器也是每一个线程私有的空间，java虚拟机会为每一个java线程创建PC寄存器。在任意时刻，一个java线程总是在执行一个方法，这个正在被执行的方法称为当前方法。如果当前方法不是本地方法，PC寄存器就会指向当前正在被执行的指令。如果当前方法是本地方法，那么PC寄存器的值就是undefined 8)执行引擎是java虚拟机的最核心组件之一，它负责执行虚拟机的字节码，现代虚拟机为了提高执行效率，会使用即时编译技术将方法编译成机器码后再执行。 
java堆
java堆是和应用程序关系最为密切的内存空间，几乎所有的对象都存放在堆上。并且java堆是完全自动化管理的，通过垃圾回收机制，垃圾对象会被自动清理，而不需要显示的释放。 根据java回收机制的不同，java堆有可能拥有不同的结构。最为常见的一种构成是将整个java堆分为新生代和老年代。其中新生代存放新生对象或者年龄不大的对象，老年代则存放老年对象。新生代有可能分为eden区、s0区、s1区，s0区和s1区也被称为from和to区，他们是两块大小相同、可以互换角色的内存空间。 如下图：显示了一个堆空间的一般结构： 
在绝大多数情况下，对象首先分配在eden区，在一次新生代回收之后，如果对象还存活，则进入s0或者s1，每经过一次新生代回收，对象如果存活，它的年龄就会加1。当对象的年龄达到一定条件后，就会被认为是老年对象，从而进入老年代。
public class SimpleHeap {
private int id;
public SimpleHeap(int id){
this.id = id;
}
public void show(){
System.out.println("My id is "+id);
}
public static void main(String[] args) {
SimpleHeap s1 = new SimpleHeap(1);
SimpleHeap s2 = new SimpleHeap(2);
s1.show();
s2.show();
}
}
该代码声明了一个类，并在main函数中创建了两个SimpleHeap实例。此时，各对象和局部变量的存放情况如图： SimpleHeap实例本身分配在堆中，描述SimpleHeap类的信息存放在方法区，main函数中的s1 s2局部变量存放在java栈上，并指向堆中两个实例。 
java栈
java栈是一块线程私有的内存空间。如果说，java堆和程序数据密切相关，那么java栈就是和线程执行密切相关。线程执行的基本行为是函数调用，每次函数调用的数据都是通过java栈传递的。 java栈与数据结构上的栈有着类似的含义，它是一块先进后出的数据结构，只支持出栈和进栈两种操作，在java栈中保存的主要内容为栈帧。每一次函数调用，都会有一个对应的栈帧被压入java栈，每一个函数调用结束，都会有一个栈帧被弹出java栈。如下图：栈帧和函数调用。函数1对应栈帧1，函数2对应栈帧2，依次类推。函数1中调用函数2，函数2中调用函数3，函数3调用函数4.当函数1被调用时，栈帧1入栈，当函数2调用时，栈帧2入栈，当函数3被调用时，栈帧3入栈，当函数4被调用时，栈帧4入栈。当前正在执行的函数所对应的帧就是当前帧（位于栈顶），它保存着当前函数的局部变量、中间计算结果等数据。 当函数返回时，栈帧从java栈中被弹出，java方法区有两种返回函数的方式，一种是正常的函数返回，使用return指令，另一种是抛出异常。不管使用哪种方式，都会导致栈帧被弹出。 在一个栈帧中，至少包含局部变量表、操作数栈和帧数据区几个部分。 
由于每次函数调用都会产生对应的栈帧，从而占用一定的栈空间，因此，如果栈空间不足，那么函数调用自然无法继续进行下去。当请求的栈深度大于最大可用栈深度时，系统会抛出StackOverflowError栈溢出错误。 使用递归，由于递归没有出口，这段代码可能会抛出栈溢出错误，在抛出栈溢出错误时，打印最大的调用深度。 使用参数-Xss128K执行下面代码（在eclipse中右键选择Run As–>run Configurations….设置Vm arguments） 发生了栈溢出错误，通过增大-Xss的值，可以获得更深的层次调用，尝试使用参数-Xss256K执行下述代码
public class TestStackDeep {
private static int count =0;
public static void recursion(){
count ++;
recursion();
}
public static void main(String[] args) {
try{
recursion();
}catch(Throwable e){
System.out.println("deep of calling ="+count);
e.printStackTrace();
}
}
}
函数嵌套调用的层次在很大程度上由栈的大小决定，栈越大，函数支持的嵌套调用次数就越多。
栈帧组成之局部变量表
局部变量表是栈帧的重要组成部分之一。它用于保存函数的参数以及局部变量，局部变量表中的变量只在当前函数调用中有效，当函数调用结束，随着函数栈帧的弹出销毁，局部变量表也会随之销毁。 由于局部变量表在栈帧之中，因此，如果函数的参数和局部变量很多，会使得局部变量表膨胀，从而每一次函数调用就会占用更多的栈空间，最终导致函数的嵌套调用次数减少。 一个recursion函数含有3个参数和10个局部变量，因此，其局部变量表含有13个变量，而第二个recursion函数不再含有任何参数和局部变量，当这两个函数被嵌套调用时，第二个recursion函数可以拥有更深的调用层次。
public class TestStackDeep2 {
private static int count = 0;
public static void recursion(long a,long b,long c){
long e=1,f=2,g=3,h=4,i=5,k=6,q=7,x=8,y=9,z=10;
count ++;
recursion(a,b,c);
}
public static void recursion(){
count++;
recursion();
}
public static void main(String[] args) {
try{
recursion(0L,0L,0L);
//recursion();
}catch(Throwable e){
System.out.println("deep of calling = "+count);
e.printStackTrace();
}
}
}
使用参数-Xss128K执行上述代码中的第一个带参recursion(long a,long b,long c)函数。可以知道输出调用次数后抛出异常。 使用虚拟机参数-Xss128K执行上述代码中第二个不带参数的recursion()函数（当然需要把第一个函数注释掉）。可以看出，在相同的栈容量下，局部变量少的函数可以支持更深的函数调用。即输出次数比上次增加。 第一个带参recursion(long a,long b,long c)的最大局部变量表的大小为26个字，因为该函数包含总共13个参数和局部变量，且都为long型，long和double在局部变量表中需要占用2个字，其他如int short byte 对象引用等占用一个字。 说明：字（word）指的是计算机内存中占据一个单独的内存单元编号的一组二进制串，一般32位计算机上一个字为4个字节长度。 栈帧中局部变量表中的槽位是可以重用的，如果一个局部变量过了其作用域，那么在其作用域之后申明的新的局部变量就很有可能会复用过期局部变量的槽位，从而达到节省资源的目的。
垃圾回收
目前为止，jvm**已经发展处三种比较成熟的垃圾收集算法：1.标记-清除算法；2.复制算法；3.标记-整理算法；4.分代收集算法**
1.**标记-**清除算法
这种垃圾回收一次回收分为两个阶段：标记、清除。首先标记所有需要回收的对象，在标记完成后回收所有被标记的对象。这种回收算法会产生大量不连续的内存碎片，当要频繁分配一个大对象时，jvm在新生代中找不到足够大的连续的内存块，会导致jvm频繁进行内存回收(目前有机制，对大对象，直接分配到老年代中)
2.**复制算法**
这种算法会将内存划分为两个相等的块，每次只使用其中一块。当这块内存不够使用时，就将还存活的对象复制到另一块内存中，然后把这块内存一次清理掉。这样做的效率比较高，也避免了内存碎片。但是这样内存的可使用空间减半，是个不小的损失。
3.**标记-**整理算法
这是标记-清除算法的升级版。在完成标记阶段后，不是直接对可回收对象进行清理，而是让存活对象向着一端移动，然后清理掉边界以外的内存
4.**分代收集算法**
当前商业虚拟机都采用这种算法。首先根据对象存活周期的不同将内存分为几块即新生代、老年代，然后根据不同年代的特点，采用不同的收集算法。在新生代中，每次垃圾收集时都有大量对象死去，只有少量存活，所以选择了复制算法。而老年代中因为对象存活率比较高，所以采用标记-整理算法(或者标记-清除算法)
GC**的执行机制**
由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。 Minor **GC 一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发MinorGC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。 Full GC** 对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比MinorGC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC： 1.年老代（Tenured）被写满 2.持久代（Perm）被写满 3.System.gc()被显示调用 4.上一次GC之后Heap的各域分配策略动态变化
为什么要运用分代垃圾回收策略？
在java程序运行的过程中，会产生大量的对象，因每个对象所能承担的职责不同所具有的功能不同所以也有着不一样的生命周期，有的对象生命周期较长，比如Http请求中的Session对象，线程，Socket连接等；有的对象生命周期较短，比如String对象，由于其不变类的特性，有的在使用一次后即可回收。试想，在不进行对象存活时间区分的情况下，每次垃圾回收都是对整个堆空间进行回收，那么消耗的时间相对会很长，而且对于存活时间较长的对象进行的扫描工作等都是徒劳。因此就需要引入分治的思想，所谓分治的思想就是因地制宜，将对象进行代的划分，把不同生命周期的对象放在不同的代上使用不同的垃圾回收方式。 
通过一个简单示例，展示局部变量对垃圾回收的影响。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32public class LocalvarGC {
public void localvarGc1(){
byte[] a = new byte[6*1024*1024];//6M
System.gc();
}
public void localvarGc2(){
byte[] a = new byte[6*1024*1024];
a = null;
System.gc();
}
public void localvarGc3(){
{
byte[] a = new byte[6*1024*1024];
}
System.gc();
}
public void localvarGc4(){
{
byte[] a = new byte[6*1024*1024];
}
int c = 10;
System.gc();
}
public void localvarGc5(){
localvarGc1();
System.gc();
}
public static void main(String[] args) {
LocalvarGC ins = new LocalvarGC();
ins.localvarGc1();
}
}
每一个localvarGcN()函数都分配了一块6M的堆内存，并使用局部变量引用这块空间。 在localvarGc1()中，在申请空间后，立即进行垃圾回收，很明显由于byte数组被变量a引用，因此无法回收这块空间。 在localvarGc2()中，在垃圾回收前，先将变量a置为null，使得byte数组失去强引用，故垃圾回收可以顺利回收byte数组。 在localvarGc3()中，在进行垃圾回收前，先使局部变量a失效，虽然变量a已经离开了作用域，但是变量a依然存在于局部变量表中，并且也指向这块byte数组，故byte数组依然无法被回收。 对于localvarGc4()，在垃圾回收之前，不仅使变量a失效，更是声明了变量c，使变量c复用了变量a的字，由于变量a此时被销毁，故垃圾回收器可以顺利回收数组byte 对于localvarGc5()，它首先调用了localvarGc1()，很明显，在localvarGc1()中并没有释放byte数组，但在localvarGc1()返回后，它的栈帧被销毁，自然也包含了栈帧中的所有局部变量，故byte数组失去了引用，在localvarGc5()的垃圾回收中被回收。 可以使用-XX:+printGC执行上述几个函数，在输出日志里，可以看到垃圾回收前后堆的大小，进而推断出byte数组是否被回收。 下面的输出是函数localvarGc4()的运行结果： [GC (System.gc()) 7618K->624K(94208K), 0.0015613 secs] [Full GC (System.gc()) 624K->526K(94208K), 0.0070718 secs] 从日志中可以看出，堆空间从回收前的7618K变为回收后的624K，释放了>6M的空间，byte数组已经被回收释放。
类加载过程
分三步，细化为五步。 
类加载的五个过程：
- 加载
- 验证
- 准备
- 解析
- 初始化
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的生命周期包括了：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)七个阶段，其中验证、准备、解析三个部分统称链接。 
加载：完成三件事
- 通过类的全限定名来获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的
java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
简单来说，加载指的是把class字节码文件从各个来源通过类加载器装载入内存中。 这里有两个重点： 1. 字节码来源。一般的加载来源包括从本地路径下编译生成的.class文件，从jar包中的.class文件，从远程网络，以及动态代理实时编译 2. 类加载器。一般包括启动类加载器，扩展类加载器，应用类加载器，以及用户的自定义类加载器。 注：为什么会有自定义类加载器？ 一方面是由于java代码很容易被反编译，如果需要对自己的代码加密的话，可以对编译后的代码进行加密，然后再通过实现自己的自定义类加载器进行解密，最后再加载。 另一方面也有可能从非标准的来源加载代码，比如从网络来源，那就需要自己实现一个类加载器，从指定源进行加载。
验证：四个阶段的检验动作
- 文件格式验证
- 元数据验证
- 字节码验证
- 符号引用验证
验证是连接阶段的第一步，这一阶段目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身安全。 虚拟机规范对这个阶段的限制和指导非常笼统，仅仅说了一句如果验证到输入的字节流不符合Class文件的存储格式，就抛出一个java.lang.VerifyError异常或者其子类异常。具体应当检查哪些方面，如何检查，何时检查，都没有强制要求或明确说明，所以不同的虚拟机对验证的实现可能会有所不同，但大致上都会完场下面四个阶段的检验过程：文件格式验证、元数据验证、字节码验证和符号引用验证。
1.文件格式验证
第一阶段要验证字节流是否符合Class文件格式的规范否，并且能被当前版本的虚拟机处理。该验证阶段的主要目的是保证输入的字节流能正确的解析并存储于方法区之内，格式上符合描述一个Java类型的信息的要求。这阶段的验证是基于字节流进行的，经过这个就饿段的验证之后，字节流才会进入内存的方法区进行存储，所以后面三个验证阶段全部是基于方法区的存储结构进行的。
2.元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言的规范要求，这个阶段可能包括的验证点如下：
- 这个类是否有父类（除了java.lang.Object之外，所有的类应当有父类）
- 这个类的父类是否继承了不允许被继承的类（被final修饰）
- 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
- 类中的字段、方法是否与父类产生了矛盾
- 。。。。。
3.字节码验证
第三个阶段是验证过程中最复杂的一个，其主要工作是进行数据流和控制流分析。第二阶段对元数据信息中的数据类型做完校验后，这阶段将对类的方法体进行校验分析。这阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为,例如：
- 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这种情况：在操作栈中放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中。
- 保证跳转指令不会跳转到方法体以外的字节码指令上。
- 保证方法体中的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，反之不合法。
- 。。。。。。
如果一个类的方法体的字节码没有通过字节码验证，那肯定是有问题的；如果一个方法体通过了字节码验证，也不能说明其一定就是安全的。即使字节码验证之中进行了大量的检查，也不能保证这一点。这里涉及了离散数学中一个很著名的问题“Halting Problem“：通俗一点的说法就是，通过程序去校验程序逻辑是无法做到绝对准确的–不能通过程序准确地检查出程序是否能在有限的时间之内结束运行。 为避免将过多时间消耗在字节码验证阶段，1.6之后给方法体的Code属性的属性表中增加了一项名为“StackMapTable”的属性，这项属性描述了方法体重所有的基本块开始时本地变量表和操作栈应有的状态，这可以将字节码验证的类型推导转变为类型检查从而节省一些时间。使用-XX：-UseSplitVerifier选项来关闭掉这项优化，或者使用参数-XX:+FailOverToOldVerifier要求在类型校验失败的时候瑞回到旧的类型推导方式进行校验（1.7之后不允许）。
4.符号引用验证
最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外的信息进行匹配性的校验，通常需要校验以下内容：
- 符号引用中通过字符串描述的全限定名是否能找到对应的类。
- 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
- 符号引用中的类、字段和方法的访问性（private、protected、public、default）是否可被当前类访问。
- 。。。。。。
符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。 验证阶段对于虚拟机的类加载机制来说，是一个非常重要、但不一定是必要的阶段。如果所运行的全部代码都已经被反复使用和验证过，在实施阶段就可以考虑使用-Xverify：none参数来关闭大部分的类验证措施，以锁单虚拟机类加载的时间。
准备：为类变量（static）分配内存并设置类变量的初始值。
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。这个阶段中有两个容易产生混淆的知识点，首先是这时候进行内存分配的仅包括类变量(static 修饰的变量),而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量定义为: public static int value = 12; 那么变量value在准备阶段过后的初始值为0而不是12，因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器static int value = 123;那么变量value在准备阶段过后初始值为0，而不是123。值123是在<clinit>()方法中赋予。
解析：将常量池内的符号引用替换为直接引用的过程。
解析的动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行。分别对应编译后常量池内的CONSTANT_Class_Info、CONSTANT_Fieldref_Info、CONSTANT_Methodef_Info、CONSTANT_InterfaceMethoder_Info四种常量类型。 1.类、接口的解析 2.字段解析 3.类方法解析 4.接口方法解析 两个重点： 1. 符号引用。即一个字符串，但是这个字符串给出了一些能够唯一性识别一个方法，一个变量，一个类的相关信息。 2. 直接引用。可以理解为一个内存地址，或者一个偏移量。比如类方法，类变量的直接引用是指向方法区的指针；而实例方法，实例变量的直接引用则是从实例的头指针开始算起到这个实例变量位置的偏移量。 举个例子来说，现在调用方法helloWorld()，这个方法的地址是1234567，那么helloWorld就是符号引用，1234567就是直接引用。 在解析阶段，虚拟机会把所有的类名，方法名，字段名这些符号引用替换为具体的内存地址或偏移量，也就是直接引用。
初始化
按照static块和static变量在文件中的出现顺序，合并到<clinit>()方法中。实例变量由<init>()函数赋值。 将一个类中所有被static关键字标识的代码统一执行一遍，如果执行的是静态变量，那么就会使用用户指定的值覆盖之前在准备阶段设置的初始值；如果执行的是static代码块，那么在初始化阶段，JVM就会执行static代码块中定义的所有操作。 所有类变量初始化语句和静态代码块都会在编译时被前端编译器放在收集器里头，存放到一个特殊的方法中，这个方法就是