1、操作系统装入JVM是通过jdk中Java.exe来完成,通过下面4步来完成JVM环境.
1.创建JVM装载环境和配置
2.装载JVM.dll
3.初始化JVM.dll并挂界到JNIENV(JNI调用接口)实例
4.调用JNIEnv实例装载并处理class类。
2.JVM内存管理的机制
内存空间划分为：JDK在实现时遵照JVM规范，将内存空间划分为堆、JVM方法栈、方法区、本地方法栈、程序计数器。
- 堆： 堆用于存储对象实例及数组值，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中对象所占用的内存由GC进行回收，在32位操作系统上最大为2GB，在64位操作系统上则没有限制，其大小可通过-Xms和-Xmx来控制，-Xms为JVM启动时申请的最小Heap内存，默认为物理内存的1/64但小于1GB；-Xmx为JVM可申请的最大Heap内存，默认为物理内存的1/4但小于1GB，默认当空余堆内存小于40%时，JVM会增大Heap到-Xmx指定的大小，可通过-XX:MinHeapFreeRatio=来指定这个比例；当空余堆内存大于70%时，JVM会减小Heap的大小到-Xms指定的大小，可通过-XX:MaxHeapFreeRatio=来指定这个比例，对于运行系统而言，为避免在运行时频繁调整Heap 的大小，通常将-Xms和-Xmx的值设成一样。总结：堆存储了几乎所有对象实例和数组，是被所有线程进行共享的区域。在逻辑上是连续的，在物理上可以是不连续的内存空间（在存储一些类似于数组的这种大对象时，基于简单和性能考虑会使用连续的内存空间）
- 方法区： 要加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息。方法区域也是全局共享的，在一定条件下它也会被GC，当方法区域要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。在Sun JDK中这块区域对应Permanet Generation，又称为持久代，默认最小值为16MB，最大值为64MB，可通过-XX:PermSize及-XX:MaxPermSize来指定最小值和最大值。总结：存储了被虚拟机加载的类型信息，常量，静态变量等数据，在JDK8以后，存储在方法区的元空间中（以前是存储在堆中的永久代中，JDK8以后已经没有永久代了）。运行时常量池是方法区的一部分，会存储各种字面量和符号引用。具备动态性，运行时也可以添加新的常量入池（例如调用String的intern()方法时，如果常量池没有相应的字符串，会将它添加到常量池）。
JDK1.7 及之后版本的 JVM 已经将运行时常量池从方法区中移了出来，在 Java 堆（Heap）中开辟了一块区域存放运行时常量池。
JDK 1.8 的时候，方法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取而代之是元空间，元空间使用的是直接内存。 下面是一些常用参数： -XX:MetaspaceSize=N //设置 Metaspace 的初始（和最小大小） -XX:MaxMetaspaceSize=N //设置 Metaspace 的最大大小 与永久代很大的不同就是，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。
为什么要将永久代 (PermGen) 替换为元空间 (MetaSpace) 呢?
- 整个永久代有一个 JVM 本身设置固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。
当你元空间溢出时会得到如下错误：
java.lang.OutOfMemoryError: MetaSpace
你可以使用 -XX：MaxMetaspaceSize 标志设置最大元空间大小，默认值为 unlimited，这意味着它只受系统内存的限制。-XX：MetaspaceSize 调整标志定义元空间的初始大小如果未指定此标志，则 Metaspace 将根据运行时的应用程序需求动态地重新调整大小。
-
元空间里面存放的是类的元数据，这样加载多少类的元数据就不由
MaxPermSize控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。 -
在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了。
- JVM方法栈： 为线程私有，其在内存分配上非常高效。当方法运行完毕时，其对应的栈帧所占用的内存也会自动释放。每个方法被创建时，会创建一个栈帧，用于存储局部变量表、操作表、方法出口等信息。当JVM方法栈空间不足时，会抛出StackOverflowError的错误，在Sun JDK中可以通过-Xss来指定其大小。局部变量表主要存放了编译器可知的各种数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。总结：执行一个Java方法时，虚拟机都会创建一个栈帧，来存储局部变量表，操作数栈等，方法调用完毕后会对栈帧从虚拟机栈中移除。局部变量表中存储了Java基本类型，对象引用（可以是对象的存储地址，也可以是代表对象的句柄等）和returnAddress类型（存储了一条字节码指令的地址）
- 本地方法栈：和虚拟机栈所发挥的作用非常相似，区别是： 虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一
- 程序计数器： 当前线程所执行的字节码的行号指示器。程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。
程序计数器主要有两个作用：
- 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
- 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。
元空间(Metaspace）元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。
直接内存(Direct Memory) 直接内存并不是虚拟机运行时数据区的一部分，也不是Java 虚拟机规范中农定义的内存区域。在JDK1.4 中新加入了NIO(New Input/Output)类，引入了一种基于通道(Channel)与缓冲区（Buffer）的I/O 方式，它可以使用native 函数库直接分配堆外内存，然后通脱一个存储在Java堆中的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据
3、GC收集算法
Java内存分配和回收的机制概括的说，就是：分代分配，分代回收。对象将根据存活的时间被分为：年轻代（Young Generation）、年老代（Old Generation）、永久代（Permanent Generation，也就是方法区）。
年轻代：对象被创建时，内存的分配首先发生在年轻代（大对象可以直接 被创建在年老代），大部分的对象在创建后很快就不再使用，因此很快变得不可达，于是被年轻代的GC机制清理掉（IBM的研究表明，98%的对象都是很快消 亡的），这个GC机制被称为Minor GC或叫Young GC。注意，Minor GC并不代表年轻代内存不足，它事实上只表示在Eden区上的GC。
年轻代上的内存分配是这样的，年轻代可以分为3个区域：Eden区（伊甸园，亚当和夏娃偷吃禁果生娃娃的地方，用来表示内存首次分配的区域，再 贴切不过）和两个存活区（Survivor 0 、Survivor 1）
- 当Eden区满的时候，执行Minor GC，将消亡的对象清理掉，并将剩余的对象复制到一个存活区Survivor0（此时，Survivor1是空白的，两个Survivor总有一个是空白的）；
- 此后，每次Eden区满了，就执行一次Minor GC，并将剩余的对象都添加到Survivor0；
- 当Survivor0也满的时候，将其中仍然活着的对象直接复制到Survivor1，以后Eden区执行Minor GC后，就将剩余的对象添加Survivor1（此时，Survivor0是空白的）。
- 当两个存活区切换了几次（HotSpot虚拟机默认15次，用-XX:MaxTenuringThreshold控制，大于该值进入老年代）之后，仍然存活的对象（其实只有一小部分，比如，我们自己定义的对象），将被复制到老年代。
年老代（Old Generation）：对象如果在年轻代存活了足够长的时间而没有被清理掉（即在几次 Young GC后存活了下来），则会被复制到年老代，年老代的空间一般比年轻代大，能存放更多的对象，在年老代上发生的GC次数也比年轻代少。当年老代内存不足时， 将执行Major GC，也叫 Full GC。
如果对象比较大（比如长字符串或大数组），Young空间不足，则大对象会直接分配到老年代上（大对象可能触发提前GC，应少用，更应避免使用短命的大对象）
可能存在年老代对象引用新生代对象的情况，如果需要执行Young GC，则可能需要查询整个老年代以确定是否可以清理回收，这显然是低效的。解决的方法是，年老代中维护一个512 byte的块——”card table“，所有老年代对象引用新生代对象的记录都记录在这里。Young GC时，只要查这里即可，不用再去查全部老年代，因此性能大大提高。
永久代（方法区）：
永久代的垃圾回收主要包含两种：
1、废弃常量 当常量已经进入常量池，并且没有任何引用可以回收。
2、无用的类 当满足以下条件成为“无用类”:
1>、该类所有的实例都被收回，也就是java堆中不存在该类的实例
2>、加载该类的ClassLoader都被收回
3>、该类对应的java.lang.Class没有被引用，无法通过反射访问该类的方法
永久代的回收并不是必须的，可以通过参数来设置是否对类进行回收
4、HotSpot常用垃圾收集器
在介绍垃圾收集器之前，需要明确一点，就是在新生代采用的停止复制算法中，“停 止（Stop-the-world）”的意义是在回收内存时，需要暂停其他所 有线程的执行。这个是很低效的，现在的各种新生代收集器越来越优化这一点，但仍然只是将停止的时间变短，并未彻底取消停止。
Serial收集器：新生代收集器，使用停止复制算法，使用一个线程进行GC，其它工作线程暂停。新生代使用复制算法，老年代使用标记压缩算法。
ParNew收集器：新生代收集器，使用停止复制算法，Serial收集器的多线程版，用多个线程进行GC，其它工作线程暂停，关注缩短垃圾收集时间。新生代并行，老年代串行，使用复制算法
Parallel Scavenge 收集器：新生代收集器，使用停止复制算法，关注CPU吞吐量，即运行用户代码的时间/总时间，比如：JVM运行100分钟，其中运行用户代码99分钟，垃 圾收集1分钟，则吞吐量是99%，这种收集器能最高效率的利用CPU，适合运行后台运算（关注缩短垃圾收集时间的收集器，如CMS，等待时间很少，所以适 合用户交互，提高用户体验
Parallel Old收集器：老年代收集器，多线程，多线程机制与Parallel Scavenge差不错，使用标记整理（与Serial Old不同，这里的整理是Summary（汇总）和Compact（压缩），汇总的意思就是将幸存的对象复制到预先准备好的区域，而不是像Sweep（清 理）那样清理废弃的对象）算法，在Parallel Old执行时，仍然需要暂停其它线程。Parallel Old在多核计算中很有用。Parallel Old出现后（JDK 1.6），与Parallel Scavenge配合有很好的效果，充分体现Parallel Scavenge收集器吞吐量优先的效果。
Serial Old收集器：老年代收集器，单线程收集器，使用标记整理（整理的方法是Sweep（清理）和Compact（压缩），清理是将废弃的对象干掉，只留幸存 的对象，压缩是将移动对象，将空间填满保证内存分为2块，一块全是对象，一块空闲）算法，使用单线程进行GC，其它工作线程暂停（注意，在老年代中进行标 记整理算法清理，也需要暂停其它线程），在JDK1.5之前，Serial Old收集器与ParallelScavenge搭配使用。
CMS（Concurrent Mark Sweep）收集器：老年代收集器，致力于获取最短回收停顿时间，使用标记清除算法，多线程，优点是并发收集（用户线程可以和GC线程同时工作），停顿小。
5、垃圾回收器常用算法：
垃圾回收相关搜索相关算法：
1、引用计数器：有缺点，如果对象之间互相引用，GC不能够主动回收对象。（JAVA没有采用）
2、标记清除
3、标记压缩 将存活对象压到内存另外一端，然后清除边界外的对象
4、复制算法 将内存分成两块，然后将存活的对象复制到另外一块，清除正在使用的那块
5.Java堆和栈的区别
Java把内存划分成两种：一种是栈内存，一种是堆内存。
在函数中定义的一些基本类型的变量和对象的引用变量都在函数的栈内存中分配。当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。
堆内存用来存放由new创建的对象和数组。在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，在栈中的这个特殊的变量就变成了数组或者对象的引用变量，以后就可以在程序中使用栈内存中的引用变量来访问堆中的数组或者对象，引用变量相当于为数组或者对象起的一个别名，或者代号。
引用变量是普通变量，定义时在栈中分配内存，引用变量在程序运行到作用域外释放。而数组＆对象本身在堆中分配，即使程序运行到使用new产生数组和对象的语句所在地代码块之外，数组和对象本身占用的堆内存也不会被释放，数组和对象在没有引用变量指向它的时候，才变成垃圾，不能再被使用，但是仍然占着内存，在随后的一个不确定的时间被垃圾回收器释放掉。这个也是java比较占内存的主要原因。但是在写程序的时候，可以人为的控制。
6.Java内存泄露和内存溢出
内存泄漏：分配出去的内存回收不了
内存溢出：指系统内存不够用了
7.Java类加载机制
系统加载 Class 类型的文件主要三步:加载->连接->初始化。连接过程又可分为三步:验证->准备->解析。
- 装载（Load）：装载过程负责找到二进制字节码并加载至JVM中，JVM通过类的全限定名（com.bluedavy. HelloWorld）及类加载器（ClassLoaderA实例）完成类的加载；
类加载过程的第一步，主要完成下面3件事情：1、通过全类名获取定义此类的二进制字节流 2、将字节流所代表的静态存储结构转换为方法区的运行时数据结构 3、在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口
备注：加载阶段和连接阶段的部分内容是交叉进行的，加载阶段尚未结束，连接阶段可能就已经开始了
2、链接（Link）：链接过程负责对二进制字节码的格式进行校验、初始化装载类中的静态变量及解析类中调用的接口、类；
验证
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：
1、 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
2、这里所设置的初始值"通常情况"下是数据类型默认的零值（如0、0L、null、false等），比如我们定义了public static int value=111 ，那么 value 变量在准备阶段的初始值就是 0 而不是111（初始化阶段才会赋值）。特殊情况：比如给 value 变量加上了 fianl 关键字public static final int value=111 ，那么准备阶段 value 的值就被赋值为 111。
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，也就是得到类或者字段、方法在内存中的指针或者偏移量。
3、初始化（Initialize）：执行类中的静态初始化代码、构造器代码及静态属性的初始化。初始化是类加载的最后一步，也是真正执行类中定义的 Java 程序代码(字节码)，初始化阶段是执行类构造器 <clinit> ()方法的过程
8、内存回收
收集器：引用计数收集器、跟踪收集器
- 引用计数收集器：对于Java这种面向对象的会形成复杂引用关系(如ObjectB和ObjectC互相引用)的语言而言，引用计数收集器不是非常适合，Sun JDK在实现GC时也未采用这种方式。
- 跟踪收集器实现算法：复制（Copying）、标记-清除（Mark-Sweep）和标记-压缩（Mark-Compact）
复制：当要回收的空间中存活对象较少时，复制算法会比较高效，其带来的成本是要增加一块空的内存空间及进行对象的移动。
标记-清除：在空间中存活对象较多的情况下较为高效，但由于标记-清除采用的为直接回收不存活对象所占用的内存，因此会造成内存碎片。
标记-压缩：在标记-清除的基础上还须进行对象的移动，成本相对更高，好处则是不产生内存碎片
9、JVM优化：
Java虚拟机的内存优化应从两方面着手：Java虚拟机和Java应用程序。前者指根据应用程序的设计通过虚拟机参数控制虚拟机逻辑内存分区的大小以使虚拟机的内存与程序对内存的需求相得益彰；后者指优化程序算法，降低GC负担，提高GC回收成功率。
切实地调优
如果nGrinder测试的结果满足了预期，那么你不需要对程序进行性能调优。如果没有达到预期结果，你就应该执行调优来解决问题。接下来会通过实例讲解方法。
stop-the-world耗时过长
stop-the-world耗时过长可能是由于GC参数不合理或者代码实现不正确。你可以通过分析工具或堆内存转储文件（Heap dump）来定位问题，比如检查堆内存中对象的类型和数量。如果在其中找到了很多不必要的对象，那么最好去改进代码。如果没有发现创建对象的过程中有特别的问题，那么最好单纯地修改GC参数。
为了适当地调整GC参数，你需要获取一段足够长时间的GC日志，还必须知道哪些情况会导致长时间的stop-the-world。想了解更多关于如何选择合适的GC参数，可以阅读我同事的一篇博文：How to Monitor Java Garbage Collection。
CPU使用率过低
当系统发生阻塞，吞吐量和CPU使用率都会降低。这可能是由于网络系统或者并发的问题。为了解决这个问题，你可以分析线程转储信息（Thread dump）或者使用分析工具。阅读这篇文章可以获得更多关于线程转储分析的知识：How to Analyze Java Thread Dumps。
你可以使用商业的分析工具对线程锁进行精确的分析，不过大部分时候，只需使用JVisualVM中的CPU分析器，就能获得足够的信息。
CPU使用率过高
如果吞吐量很低但是CPU使用率却很高，很可能是低效率代码导致的。这种情况下，你应该使用分析工具定位代码中性能的瓶颈。可使用的工具有：JVisualVM、Eclipse TPTP或者JProbe。
从程序方面讲应该这样，优化程序代码：
1.尽早释放无用对象的引用(XX = null;)
2.谨慎使用集合数据类型，如数组，树，图，链表等数据结构，这些数据结构对GC来说回收更复杂。
3.避免显式申请数组空间，不得不显式申请时，尽量准确估计其合理值。
4.尽量避免在类的默认构造器中创建、初始化大量的对象，防止在调用其自类的构造器时造成不必要的内存资源浪费
5.尽量避免强制系统做垃圾内存的回收，增长系统做垃圾回收的最终时间
1.最基本的建议就是尽早释放无用对象的引用。大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域（scope）后，自动设置为null.我们在使用这种方式时候，必须特别注意一些复杂的对象图，例如数组，队列，树，图等，这些对象之间有相互引用关系较为复杂。对于这类对象，GC回收它们一般效率较低。如果程序允许，尽早将不用的引用对象赋为null.这样可以加速GC的工作。
2.尽量少用finalize函数。finalize函数是Java提供给程序员一个释放对象或资源的机会。但是，它会加大GC的工作量，因此尽量少采用finalize方式回收资源。
3.如果需要使用经常使用的图片，可以使用soft应用类型。它可以尽可能将图片保存在内存中，供程序调用，而不引起OutOfMemory.
4.注意集合数据类型，包括数组，树，图，链表等数据结构，这些数据结构对GC来说，回收更为复杂。另外，注意一些全局的变量，以及一些静态变量。这些变量往往容易引起悬挂对象（danglingreference），造成内存浪费。
5.当程序有一定的等待时间，程序员可以手动执行System.gc（），通知GC运行，但是Java语言规范并不保证GC一定会执行。使用增量式GC可以缩短Java程序的暂停时间。
10、常见OOM及应对策略
1、OOM for Heap=>例如：java.lang.OutOfMemoryError: Java heap space
【分析】
此OOM是由于JVM中heap的最大值不满足需要，将设置heap的最大值调高即可，参数样例为：-Xmx2G
【解决方法】
调高heap的最大值，即-Xmx的值调大。
2、OOM for Perm=>例如：java.lang.OutOfMemoryError: Java perm space
【分析】
此OOM是由于JVM中perm的最大值不满足需要，将设置perm的最大值调高即可，参数样例为：-XX:MaxPermSize=512M
【解决方法】
调高heap的最大值，即-XX:MaxPermSize的值调大。
另外，注意一点，Perm一般是在JVM启动时加载类进来，如果是JVM运行较长一段时间而不是刚启动后溢出的话，
很有可能是由于运行时有类被动态加载进来，此时建议用CMS策略中的类卸载配置。
如：-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled
3、OOM for GC=>例如：java.lang.OutOfMemoryError: GC overhead limit exceeded
【分析】
此OOM是由于JVM在GC时，对象过多，导致内存溢出，建议调整GC的策略，在一定比例下开始GC而不要使用默认的策略，或者将新代和老代设置合适的大小，
需要进行微调存活率。
【解决方法】
改变GC策略，在老代80%时就是开始GC，并且将-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）设置的更合理。
4、OOM for native thread created=>例如：java.lang.OutOfMemoryError: unable to create new native thread
【分析】
参考如下：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
MaxProcessMemory 指的是一个进程的最大内存
JVMMemory JVM内存
ReservedOsMemory 保留的操作系统内存
ThreadStackSize 线程栈的大小
如果JVM内存调的过大或者可利用率小于20%，可以建议将heap及perm的最大值下调，并将线程栈调小，即-Xss调小，如：-Xss128k
【解决方法】
在JVM内存不能调小的前提下，将-Xss设置较小，如：-Xss:128k
5、OOM for allocate huge array=>例如：Exception in thread "main": java.lang.OutOfMemoryError: Requested array size exceeds VM limit
【分析】
此类信息表明应用程序（或者被应用程序调用的APIs）试图分配一个大于堆大小的数组。例如，如果应用程序new一个数组对象，大小为512M，但是最大堆大小为256M，因此OutOfMemoryError会抛出，因 为数组的大小超过虚拟机的限制。
【解决方法】
（1）、首先检查heap的-Xmx是不是设置的过小
（2）、如果heap的-Xmx已经足够大，那么请检查应用程序是不是存在bug，例如：应用程序可能在计算数组的大小时，存在算法错误，导致数组的size很大，从而导致巨大的数组被分配。
6、 OOM for small swap=>例如：Exception in thread "main": java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?
【分析】
抛出这类错误，是由于从native堆中分配内存失败，并且堆内存可能接近耗尽。这类错误可能跟应用程序没有关系，例如下面两种原因也会导致错误的发生：
（1）操作系统配置了较小的交换区
（2）系统的另外一个进程正在消耗所有的内存
【解决方法】
（1）、检查os的swap是不是没有设置或者设置的过小
（2）、检查是否有其他进程在消耗大量的内存，从而导致当前的JVM内存不够分配。
注意：虽然有时<reason>部分显示导致OOM的原因，但大多数情况下，<reason>显示的是提示分配失败的源模块的名称，所以有必要查看日志文件，如crash时的hs文件。
11、对象的创建
Step1:类加载检查 虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
Step2:分配内存 分配方式有 “指针碰撞” 和 “空闲列表” 两种。
内存分配并发问题，通常来讲，虚拟机采用两种方式来保证线程安全：
PS:如何解决内存分配时的多线程并发竞争问题？
- CAS+失败重试： 虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。
- TLAB： 为每一个线程预先在 Eden 区分配一块儿内存，JVM 在给线程中的对象分配内存时，首先在 TLAB 分配，当对象大于 TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配
Step3:初始化零值
内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
Step4:设置对象头
初始化零值完成之后，虚拟机要对对象进行必要的设置，例如这个对象是那个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。
Step5:执行 init 方法
在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始，<init> 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 <init> 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。
