调用JVM和类Java命令运行Java程序时，该命令将启动Java虚拟机进程。 不管Java程序有多复杂，以及程序启动的线程数量如何，它都在Java虚拟机进程中。 同一JVM的所有线程、所有变量都位于同一进程中，它们使用该JVM进程的内存空间。 如果系统出现以下情况，JVM进程将终止：
程序使用正常接收到最后的System.exit (或Runtime.getRuntime ).exit )代码执行程序直到程序结束； 程序运行时发生未捕获的异常或错误而退出； 程序所在的平台强制退出了JVM进程； 类加载器是查找和分析类或接口字节码文件以在JVM中构建对象表示的组件。 在java中，类加载器将类加载到JVM中，过程如下：
1、加载：查找和导入类文件
2、链接：其中可以选择分析步骤(a )选中：检查加载的class文件数据的正确性) b )准备：为类的静态变量分配存储空间) c )分析：将符号引用转换为直接引用
3、初始化：对静态变量、静态代码块执行初始化工作
的加载过程如果Java程序需要使用类，但该类尚未加载到内存中，则JVM通过三个步骤初始化类：加载、连接、验证、准备和分析。
的加载是指将类的. class文件中的数据读入内存。 通常，您会创建一个字节数组，将其导入到. class文件中，然后生成与加载的类相对应的class对象。 加载完成后，Class对象还不完整，因此此时类还不能使用。 类加载后，将进入连接阶段。 此阶段包括三个步骤：验证、准备、为静态变量分配内存、设置缺省初始值、解析和直接用引用替换符号引用。 最后一个JVM按如下方式初始化类：
1 )如果类中存在直接父类，且该类尚未初始化，则首先初始化父类；
2 )如果类中有初始化语句，则依次执行这些初始化语句。
摘要由于Java的跨平台性，编译的Java源程序不是可执行文件，而是一个或多个类文件。 如果Java程序需要使用该类，但该类尚未加载到内存中，则Java虚拟机将加载、连接和初始化该Java类，以便运行的Java程序可以使用它。 其中，“加载”(Loading )是将类的. class文件导入Java虚拟机。 链接是指将导入此类虚拟机的二进制格式的数据整合到虚拟机的运行时状态中。 连接阶段分为三个子步骤：验证(Verification )、准备(Preparation )和分析(Resolution )。 验证步骤以确保Java类型的数据格式正确，并且适合在Java虚拟机上使用。 准备过程负责分配该类型所需的内存，包括为类变量分配内存。 分析过程将常量池中的符号引用直接转换为引用。
加载、验证、准备和初始化四个阶段的顺序是确定的，类的加载过程必须按此顺序一个接一个地开始。 另一方面，分析不一定是：在某些情况下也可以在初始化阶段之后开始。 这是为了支持Java语言的运行时绑定(也称为动态绑定或延迟绑定)。
在类初始化的计时类和接口已加载并连接时，Java虚拟机规范为实现提供了一定程度的灵活性。 但是，它严格定义了初始化的时机。 的所有Java虚拟机实现都必须在第一次活动使用每个类或接口时初始化。 在以下情况下，必须立即“初始化”类：
1 )遇到new、getstatic、putstatic或invokestatic四字节码指令时，如果类尚未初始化，则必须首先触发初始化。 生成这四条指令最常见的Java代码场景是：
使用new关键字实例化对象时，即在字节码中执行getstalic或putstatic指令时，调用类的静态方法(除了在编译时在常量池中生成结果的静态字段外) 2 )调用Java API反射方法(如类Class的方法或java.lang.reflect包的方法)时，如果类尚未初始化，则必须首先触发初始化。
3 )初始化类时，如果发现父类尚未初始化，则需要首先触发父类的初始化。
4 )虚拟机启动时，用户必须指定要运行的主类(main ) (封装方法的类)。 虚拟机首先初始化这个主类。
5 )使用JDK1.7动态语言支持时，java.lang.invoke.MethodHandle实例的上次分析结果为REF_getStatic、REF_putStatic、REF_invokeStatic
对于引起类初始化的五个场景，虚拟机规范使用强修饰符“有且仅' '”。 这五个场景中的行为称为对类的积极引用。 引用所有其他类的方法不会触发称为被动引用的初始化。
的加载是类加载过程的一个阶段，请不要混淆这两个概念。 在加载阶段，虚拟机需要完成以下三项：
1 )通过一个类的完全限定名获取定义
此类的二进制字节流。2 )将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3 ) 将类的class文件读入内存，并为之创建一个java.lang.Class对象，也就是说当程序中使用任何类时，系统都会为之建立一个java.lang.Class对象, 作为方法区这个类的各种数据的访问入口。
通过使用不同的类加载器，可以从不同来源加载类的二进制数据，通常有如下几种来源：
从本地文件系统加载class文件；从一个ZIP、 JAR、 CAB或者其他某种归档文件中提取Java class文件，JDBC编程时使用到的数据库驱动就是放在JAR文件中，JVM可以直接从JAR包中加载class文件；通过网络加载class文件，这种场景最典型的应用就是 Applet；把一个java源文件动态编译、并执行加载运行时计算生成, 这种场景使用得最多的就是动态代理接术, 在 java.lang.reflect.Proxy中 , 就是用了 ProxyGenerator.generateProxyClass来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。类的连接当类被加载后，系统为之生成一个对应的Class对象，接着会进入连接阶段，连接阶段将会负责把类的二进制文件合并到JRE中。类连接分为如下三个阶段：
验证：验证阶段用于检验被加载的类是否有正确的内部结构，并和其他类协调一致；准备：准备阶段则负责为类的静态属性分配内存，并设置默认初始值；解析：将类的二进制数据中的符号引用替换成直接引用（符号引用是用一组符号描述所引用的目标；直接引用是指向目标的指针）验证验证是连接阶段的第一步, 这一阶段的目的是为了确保 Class文件的字节流中包含的信息符合当前虚拟机的要求, 井且不会危害虚拟机自身的安全。
Java语言本身是相对安全的语言，但前面已经说过, Class文件并不一定要求用 Java源码编译而来, 可以使用任何途径, 包括用十六进制编译器直接编写来产生 Class 文件。在字节码的语言层面上, 上述 Java代码无法做到的事情都是可以实现的, 至少语义上是可以表达出来的。虚拟机如果不检査输入的字节流,对其完全信任的话, 很可能会因为载入了有害的字节流而导致系统崩溃 , 所以验证是虚拟机对自身保护的一项重要工作。从整体上看，验证阶段会完成下面四个阶段的检验过程: 文件格式验证、 元数据验证、 字节码验证、符号引用验证。
1、文件格式验证
第一阶段要验证字节流是否符合 Class文件格式的规范, 井且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证点：
是否以魔数 0xCAFEBABE开头主、次版本号是否在当前虚拟机处理范围之内 。常量池的常量中是否有不被支持的常量类型(检査常量tag 标志)。指向常量的各种索引值中是否有指向不存在的常量或不符合装型的常量 。CONSTANT_Utf8_info型的常量中是否有不符合 UTF8编码的数据Class 文件中各个部分及文件本身是否有被删除的或附加的其他信息实际上第一阶段的验证点还远不止这些, 上面这些只是从 HotSpot虚拟机源码中摘抄的一小部分而已。只有通过了这个阶段的验证之后, 字节流才会进入内存的方法区中进行存储, 所以后面的三个验证阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。
2、元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求,这个阶段可能包括的验证点如下:
这个类是否有父类(除了 java.lang.0bject之外,所有的类都应当有父类)
这个类的父类是否继承了不允许被继承的类(被finaI修饰的类)
如果这个类不是抽象类, 是否实現了其父类或接口之中要求实现的所有方法
类中的字段、 方法是否与父类产生了矛盾(例如覆盖了父类的final字段, 或者出現不符合规则的方法重载, 例如方法参数都一致, 但返回值类型却不同等)
第二阶段的验证点同样远不止这些，这一阶段的主要目的是对类的元数据信息进行语义检验, 保证不存在不符合 Java语言规范的元数据信息。
3、字节码验证
第三阶段是整个验证过程中最复杂的一个阶段, 主要目的是通过数据流和控制流的分析，确定语义是合法的。符号逻辑的。在第二阶段对元数据信息中的数据类型做完校验后，这阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为，例如：
保证任意时刻操作数栈的数据装型与指令代码序列都能配合工作, 例如不会出现类似这样的情况:在操作栈中放置了一个 int类型的数据, 使用时却按long类型来加载入本地变量表中。保证跳转指令不会跳转到方法体以外的字节码指令上保证方法体中的类型转换是有效的, 例如可以把一个子类对象赋值给父类数据装型，这是安全的,但是把父类对象意赋值给子类数据类型,甚至把对象赋值给与它毫无继承关系、 完全不相干的一个数据类型, 则是危险和不合法的。即使一个方法体通过了字节码验证, 也不能说明其一定就是安全的。
4、符号引用验证
最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候 , 这个转化动作将在连接的第三个阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外(常量池中的各种符号引用) 的信息进行匹配性的校验, 通常需要校验以下内容:
符号引用中通过字将串描述的全限定名是否能找到对应的类在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段 。符号引用中的类、字段和方法的访问性(private、 protected、 public、 default)是否可被当前类访问符号引用验证的目的是确保解析动作能正常执行, 如果无法通过符号引用验证, 将会抛出一个 java.lang.IncompatibleClassChangError异常的子类, 如 java.lang.IllegalAccessError、 java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。
对于虚拟机的装加载机制来说 ,验证阶段是一个非常重要的、 但不一定是必要的阶段（因为对程序没有影响）。如果所运行的全部代码(包括自己编写的以及第三方包中的代码)都已经被反复使用和验证过 , 那么在实施阶段就可以考虑使用一Xverify;none 参数来关闭大部分的验证措施, 以缩短虚拟机类加载的时间。
准备准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配 。这个阶段中有两个容易产生混淆的概念需要强调一下, 首先，这时候进行内存分配的仅包括类变量(被static修饰的变量)，而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在 Java 堆中 。 其次，这里所说的初始值“通常情况”下是数据类型的零值。
解析解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程， 解新动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行,分别对应于常量池的CONSTANT_Class_info、 CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_IntrfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info7种常量类型,解析阶段中所说的直接引用与符号引用关系如下：
符号引用(Symlxiuc References):符号引用以一组符号来描述所引用的日标,符号可以是任何形式的字面量, 只要使用时能无歧义地定位到目标即可, 特号引用与配組机实现的内存1布.局11i-美 , 引用的日标并不一定已组加裁到内存中直接引用(Direct References):直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的 , 同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同. 如果有了直接引用, 那引用的目标必定已经在内存中存在类的初始化初始化阶段是类加载过程的最后一步 , 前面的几个阶段, 除了在加载阶段用户应用程序可以通过自定 义类加载器參与之外, 其余动作完全由虚拟机主导和控制。到了初始化阶段, 才真正开始执行类中定义的 Java程序代码。从代码角度，初始化阶段是执行类构造器<clinit>()方法的过程。我们先看一下<clinit>()方法执行过程中可能会影响程序运行行为的特点和细节：
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静志语句块(static{}块)中的语句合并产生的, 编译器收集的顺序是由语句在源文件中出现的顺序所决定的, 静态语句块中只能访问到定义在静态语句块之前的变量, 定义在它之后的変量 , 在前面的静态语句块可以赋值 , 但是不能访问<clinit>()方法与类的构造函数 (或者说实例构造器<init>()方法)不同，它不需要显式地调用父类构造器, 虚期机会保证在子类的<clinit>()方法执行之前, 父类的<clinit>()方法已经执行完毕, 因此在虚期机中第一个被执行的<clinit>()方法的类肯定是 java,lang.Object由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作<clinit>()方法对于类或接口来说并不是必须的, 如果一个类中没有静态语句块,也没有对变量的赋值操作, 那么编译器可以不为这个类生成<clinit>()方法接口中不能使用静态语句块，但仍然有变量初始化的赋值操作, 因此接口与类一样都会生成<clinit>()方法。 但接口与类不同的是, 执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时, 父接口才会被初始化。 另外, 接口的实现类在初始化时也一样不会执行接口的<clinit>()方法虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()法,其他线程部需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作, 那就可能造成多个进程阻塞, 在实际应用中这种阻塞往往是隐蔽的。类的初始化阶段主要是对类变量进行初始化，在Java类中对类变量指定初始值有两种方式：
声明类变量时指定初始值使用静态初始化块为类变量指定初始值JVM初始化一个类一般包括如下几个步骤：
假如这个类还没有被加载和连接，程序先加载并连接该类；假如该类的直接父类还没有被初始化，则先初始化其直接父类；假如类中有初始化语句，则系统依次执行这些初始化语句当执行第二步时，系统对直接父类的初始化也遵循此1、2、3步骤，如果该直接父类又有直接父类，系统再次重复这三步，所以JVM最先初始化的总是java.lang.Object类。
参考：
http://www.jb51.net/article/112006.htm
https://blog.csdn.net/justloveyou_/article/details/72466416