JVM

JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

JVM结构

​ JVM又被分为三大子系统，类加载子系统，运行时数据区，执行引擎。

• 类装载器ClassLoader： 用来装载.class文件
• 运行时数据区： 方法区、堆、Java栈、程序计数器、本地方法栈
• 执行引擎： 执行字节码，或者执行本地方法

JVM类加载机制

JVM把描述类数据的字节码.Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制。

1、类的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的生命周期包括了：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading) 七个阶段，其中验证、准备、解析三个部分统称链接。

其中加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的。解析阶段可以在初始化之后再开始(运行时绑定或动态绑定或晚期绑定)。

• 1.1、加载
  加载又叫装载，主要任务是：

  • 通过类全名来获取定义此类的二进制字节流；
  • 将字节流所代表的静态存储结构转换为方法区的运行时数据结构；
  • 在Java堆中生成一个代表此类的java.long.Class对象，作为方法区这些数据的访问入口。

• 1.2、验证
  主要目的是确保class文件字节流包含的信息符合当前虚拟机的要求，主要包括四个验证过程：文件格式验证、元数据验证、字节码验证、符号引用验证。

• 1.3、准备
  准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配

  • 只有类变量（static修饰）进行分配
  • 实例变量将会在对象实例化时随着变量一起分配在堆中
  • 此时分配的初始值“通常情况”是基本数据类型的零值：如定义 public static int value = 12;此时的初值是0。因为这时候尚未开始执行任何java方法，而把value赋值为12的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为12的动作将在初始化阶段才会被执行。
  • 特殊的情况，如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，建设上面类变量value定义为：public static final int value = 123;编译时javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value设置为123。

• 1.4、解析
  解析阶段是把常量池内的符号引用替换为直接引用的过程。

  • 符号引用：符号引用以一组符号来描述所引用的目标，符号可以使任何形式的字面量。
  • 直接引用可以是直接指向目标对象的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机内存布局实现相关的，如果有了直接引用，那引用的目标必定已经在内存中存在。

• 1.5、初始化
  前面过程都是以虚拟机主导，而初始化阶段开始执行类中的 Java 代码。为类加载最后阶段，若该类具有超类，则对其进行初始化，执行静态初始化器和静态初始化成员变量(如前面只初始化了默认值的static变量将会在这个阶段赋值，成员变量也将被初始化)。

2、类是如何加载到JVM中

Java文件通过编译为class文件，然后通过类的加载器装载到jvm中。

从 Java 虚拟机角度讲，只存在两种类加载器：一种是启动类加载器（C++ 实现，是虚拟机的一部分）；另一种是其他所有类的加载器（Java 实现，独立于虚拟机外部且全继承自 java.lang.ClassLoader）

类加载器的任务是根据一个类的全限定名来获取描述此类的二进制字节流到JVM中，然后转换为一个与目标类对应的java.lang.Class对象实例，在虚拟机提供了4种类加载器，启动（Bootstrap ClassLoader）类加载器、扩展（Extension ClassLoader）类加载器、应用程序（Application ClassLoader）类加载器、自定义（User ClassLoader）类加载器。

• A.启动类加载器： 这个类加载器负责放在<JAVA_HOME>中jre/lib/rt.jar里所有的class，或者被-Xbootclasspath参数所指定的路径中的class，并且是虚拟机识别的类库。用户无法直接使用。

• B.扩展类加载器： 这个类加载器由sun.misc.Launcher$AppClassLoader实现。它负责<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。用户可以直接使用。

• C.应用程序类加载器： 这个类由sun.misc.Launcher$AppClassLoader实现。是ClassLoader中getSystemClassLoader()方法的返回值。它负责用户路径（ClassPath）所指定的类库。用户可以直接使用。如果用户没有自己定义类加载器，默认使用这个。

• D.自定义加载器： 用户自己定义的类加载器。
  

• 2.1、双亲委派
  如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上。而当最顶层加载失败时，则会把请求交还给子加载器去完成，依次向下，最终Application ClassLoader也加载失败，则会报出异常ClassNotFoundException。

  • 防止内存浪费： 类加载器在成功加载某个类之后，会把得到的 java.lang.Class类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。
  • 避免重复加载： 采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
  • 避免核心类篡改： 假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java
    API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。
  • 破坏双亲委派模型或篡改核心类库： 由于以上的特点，通常我们不可以这样做。但是由于系统自带的三个类加载器都加载特定目录下的类，如果我们自定义一个自己的类加载器放在一个特殊的目录，那么系统的加载器就无法加载，也就是最终还是由我们自己的加载器加载。

JVM运行时数据区（内存模型）

类装载器装载编译后的字节码，并加载到运行时数据区。

JVM运行时会分配好方法区和堆，而JVM每遇到一个线程，就为其分配一个程序计数器、Java栈(虚拟机栈)、本地方法栈，当线程终止时，三者（程序计数器、Java栈、本地方法栈）所占用的内存空间也会释放掉。所以gc只发生在线程共享的区域（大部分发生在Heap上）。

1.各区域介绍

• 1.1、方法区：

  • 方法区和永久代和元空间：永久代和元空间都是对方法区的实现，在jdk1.8中移除了永久代改为元空间。永久代与元空间的区别是元空间并不在虚拟机中，而是使用本地内存。
  • 主要用于存储类的信息(版本，字段，方法，接口等信息)，成员常量，静态变量以及编译器编译后的代码等，逻辑上属于堆的一部分，但是为了与堆进行区分，通常又叫“非堆”。
  • 运行时常量池，方法区中非常重要的部分，用于存放静态编译产生的字面量和符号引用。运行时生成的常量也会存在这个常量池中，比如String的intern方法。 它是每一个类或接口的常量池的运行时表示形式，在类和接口被加载到JVM后，对应的运行时常量池就被创建出来。
  • 通常会抛出java.lang.OutOfMemoryError异常，永久代抛出PermGen space，元空间抛出堆异常Metadata space。

• 1.2、堆：

  • 主要是存放对象实例和数组（当然，数组引用是存放在Java栈中的）。
  • 堆是JVM中最大的一块内存区域，几乎所有的对象实例都在这里分配内存（垃圾回收的重点），但由于堆是线程共享的，所以在分配内存时需要加锁，这导致new对象的开销很大。
    Sun Hotspot JVM为了提升对象内存分配的效率，内部会划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer, TLAB，可以位于物理上不连续的空间，但是逻辑上要连续。)。在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配。
  • 堆中又分为新生代（Young Generation）和老年代（Tenured Generation），分配的内存比例2:1，刚创建的对象存放在新生代，而老年代中存放生命周期长久的实例对象（新建的大对象会直接放到老年代，当老年代放不下会直接抛出OutOfMemoryError（OOM））。
  • 新生代中又被分为Eden区和两个Survivor区(From Space和To Space)。新的对象分配是首先放在Eden区，Survivor区作为Eden区和Old区的缓冲，在Survivor区的对象经历若干次GC仍然存活的，就会被转移到老年代。
  • 通常会抛出OutOfMemoryError

• 1.3、程序计数器：

  • 程序计数器（Program Counter Register），也有称作为PC寄存器。
  • 在JVM中，多线程是通过线程轮流切换来获得CPU执行时间的，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰，否则就会影响到程序的正常执行次序。
  • 字节码解释器工作是就是通过改变这个计数器的值来选取下一条需要执行指令的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖计数器完成
  • 如果线程正在执行一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Native 方法，这个计数器的值则为 (Undefined)。
  • 由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变，因此此内存区域是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。

• 1.4、虚拟机栈：

  • 虚拟机栈（Java Vitual Machine Stack）也称作Java栈。
  • 虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。 每一个方法从调用直至执行结束，就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。
    • 局部变量表：用来存储方法中的局部变量（包括在方法中声明的非静态变量以及函数形参）。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。
    • 操作数栈：将变量之间的运算入栈，然后存储计算结果，再出栈赋值给局部变量表。
    • 方法出口：假如代码中main()方法调用了test()方法，这时test()执行完成后，需要继续执行main()方法，方法出口记录了test()方法执行完成后的一个出口，也就是回到main()
  • StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度。
  • OutOfMemoryError：如果虚拟机栈可以动态扩展，而扩展时无法申请到足够的内存。

• 1.5、本地方法栈：
  本地方法栈则是为虚拟机使用到的Native方法服务。
  本地方法栈与Java栈的作用和原理非常相似。

2.JVM垃圾回收机制

GC的基本原理：将内存中不再被使用的对象进行回收，GC中用于回收的方法称为收集器，由于GC需要消耗一些资源和时间，Java在对对象的生命周期特征进行分析后，按照新生代、旧生代的方式来对对象进行收集，以尽可能的缩短GC对应用造成的暂停。

程序计数器、虚拟机栈、本地方法栈 3 个区域随线程生灭(因为是线程私有)，栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。而Java堆区和方法区 则不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分。

• 2.1、对象已死？
  垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”。判断哪些对象“死去”常用有两种方式：

  • 引用计数法：早期策略。给对象添加一个引用计数器。 当任何其它变量被赋值为这个对象的引用时，计数加1；当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。
    • 无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0。
  • 可达性分析算法：通过一系列的 ‘GC Roots’ 的对象作为起始点，从这些节点出发所走过的路径称为引用链。当一个对象到 GC Roots 没有任何引用链相连的时候说明对象不可用。
    
  • 可作为GC Roots的对象包括下面几种：
    • a) 虚拟机栈中引用的对象（栈帧中的本地变量表）；
    • b) 方法区中类静态属性引用的对象；
    • c) 方法区中常量引用的对象；
    • d) 本地方法栈中JNI（Native方法）引用的对象。
  • 不同的对象引用类型， GC会采用不同的方法进行回收：
    • 强引用：类似于 Object obj = new Object(); 只要强引用在就不回收。
    • 软引用：SoftReference 类实现软引用。在系统要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。
    • 弱引用：WeakReference 类实现弱引用。对象只能生存到下一次垃圾收集之前。在垃圾收集器工作时，无论内存是否足够都会回收掉只被弱引用关联的对象。
    • 虚引用：PhantomReference 类实现虚引用。无法通过虚引用获取一个对象的实例，为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
  • 无论引用计数算法还是可达性分析算法都是基于强引用而言的。
  • 即使在可达性分析算法中不可达的对象，也并非是“非死不可”，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：
    • 第一次标记：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记；
    • 第二次标记：第一次标记后接着会进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法，在finalize（）方法中没有重新与引用链建立关联关系的，将被进行第二次标记。
    • 第二次标记成功的对象将真的会被回收，如果对象在finalize（）方法中重新与引用链建立了关联关系，那么将会逃离本次回收，继续存活。

• 2.2、方法区如何判断是否需要回收？
  在堆中，尤其是在新生代中，一次垃圾回收一般可以回收 70% ~ 95% 的空间，而方法区的垃圾收集效率远低于此。

  • 方法区主要回收的内容有：废弃常量和无用的类。
  • 废弃常量：一般是判断有没有该常量的引用。也可通过引用的可达性来判断。
  • 无用的类：要以下三个条件都满足：
    • 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
    • 加载该类的ClassLoader已经被回收；
    • 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

• 2.3、常用的垃圾回收算法
  现在已经可以判断哪些对象已经“死去”了，我们现在要对这些“死去”的对象进行回收，回收也有好几种算法：

  • 标记-清除（Mark-Sweep）算法： 分为标记阶段和清除阶段。标记阶段的任务是标记出所有需要被回收的对象，清除阶段就是回收被标记的对象所占用的空间。
    • 标记和清除过程的效率都不高。
    • 标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致：当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。
  • 复制（Copying）算法： 为了解决Mark-Sweep算法的缺陷。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用的内存空间一次清理掉，这样一来就不容易出现内存碎片的问题。
    • 对内存空间的使用做出了高昂的代价，因为能够使用的内存缩减到原来的一半。
    • 如果存活对象很多，那么Copying算法的效率将会大大降低。
  • 标记-整理（Mark-Compact）算法： 基于以上两种算法优劣，提出了Mark-Compact算法。该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。
  • 分代收集（Generational Collection）算法： 是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation）
    • 老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。
    • 新生代：采用复制算法。
      • 所有新生成的对象首先都是放在新生代的。新生代的目标就是尽可能快速的收集掉那些生命周期短的对象。
      • 新生代中98%的对象都是”朝生夕死”的，所以并不需要按照1 : 1的比例来划分内存空间，而是将内存(新生代内存)分为一块较大的Eden(伊甸园)空间和两块较小的Survivor(幸存者)空间（HotSpot默认Eden与Survivor的大小比例是8 : 1），每次使用Eden和其中一块Survivor（两个Survivor区域一个称为From区，另一个称为To区域）。
      • 大致流程为：1）当Eden区满的时候,会触发第一次Minor gc,把还活着的对象拷贝到Survivor From区；当Eden区再次触发Minor gc的时候,会扫描Eden区和From区域,对两个区域进行垃圾回收,经过这次回收后还存活的对象,则直接复制到To区域,并将Eden和From区域清空。2）当后续Eden又发生Minor gc的时候,会对Eden和To区域进行垃圾回收,存活的对象复制到From区域,并将Eden和To区域清空。3）部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这个参数默认是15),最终如果还是存活,就存入到老年代。
      • 当Survivor1区不足以存放 Eden和Survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收。
      • 新生代发生的GC也叫做Minor GC、新生代GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。
    • 老年代：一般采用标记整理算法。
      • 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
      • 老年代中对象存活率较高、没有额外的空间分配对它进行担保。所以必须使用 标记 —— 清除 或者 标记 —— 整理 算法回收。
      • 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC或Full GC，Full GC发生频率比较低。Major GC的速度一般会比Minor GC慢10倍以上。

• 2.4、常见的垃圾收集器
  上面所讲的垃圾收集算法只能算是方法论，落地实现的是垃圾收集器：

  • Serial收集器（复制算法)： 新生代单线程收集器，标记和清理都是单线程，意味着它只会使用一个 CPU 或一条收集线程去完成收集工作，并且在进行垃圾回收时必须暂停其它所有的工作线程直到收集结束。
    • 需要STW（Stop The World），停顿时间长。
    • 简单高效，对于单个CPU环境而言，Serial收集器由于没有线程交互开销，可以获取最高的单线程收集效率。
    • 是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定。
  • Serial Old收集器（标记-整理算法)：老年代单线程收集器，Serial收集器的老年代版本。
  • ParNew收集器(复制算法)：新生代收集器，可以认为是Serial收集器的多线程版本。
    • 在多核CPU环境下有着比Serial更好的表现。
    • 是Server模式下的虚拟机首选的新生代收集器。除了Serial收集器外，目前只有它能与CMS收集器配合工作。
    • 它默认开启的收集线程数与CPU数量相同，在CPU数量非常多的情况下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。
  • 并行（Parallel）和并发（Concurrent）：
    • 并行：指多条垃圾收集线程并行工作，此时用户线程处于等待状态。
    • 并发：指用户线程和垃圾回收线程同时执行(不一定是并行，有可能是交叉执行)，用户进程在运行，而垃圾回收线程在另一个 CPU 上运行。
  • Parallel Scavenge收集器(复制算法)：新生代的多线程收集器（并行收集器）。 也被称为“吞吐量优先收集器”。
    • 回收期间不需要暂停其他用户线程。
    • 追求高吞吐量(Throughput = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间))，高效利用CPU，主要是为了达到一个可控的吞吐量。
    • Parallel Scavenge收集器是虚拟机运行在Server模式下的默认垃圾收集器。
    • 适合后台应用等对交互相应要求不高的场景。可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数。
  • Parallel Old收集器(标记-整理算法)： Parallel Scavenge收集器的老年代版本，多线程，并行收集器，吞吐量优先。
  • CMS(Concurrent Mark Sweep)收集器（标记-清除算法）：以获取最短回收停顿时间为目标的并发收集器。
    • 高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，多核cpu 追求高响应时间的选择。
    • 收集过程分为如下四步：
      • 1、初始标记(CMS initial mark)：标记 GC Roots 能直接关联到的对象，时间很短。
      • 2、并发标记(CMS concurrent mark)：进行 GC Roots Tracing（可达性分析）过程，时间很长。
      • 3、重新标记(CMS remark)：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间较长。
      • 4、并发清除(CMS concurrent sweep)，时间很长。
    • 对CPU资源非常敏感，可能会导致应用程序变慢，吞吐率下降。
    • 无法处理浮动垃圾，因为在并发清理阶段用户线程还在运行，自然就会产生新的垃圾，而在此次收集中无法收集他们，只能留到下次收集，这部分垃圾为浮动垃圾
    • 由于采用的标记 - 清除算法，会产生大量的内存碎片，不利于大对象的分配，可能会提前触发一次Full GC。
  • G1 收集器：面向服务端的垃圾回收器。 它能充分利用多CPU、多核环境。因此它是一款并行与并发收集器，并且它能建立可预测的停顿时间模型。
    • 优点：并行与并发、分代收集、空间整合、可预测停顿。
    • 并行和并发：使用多个CPU来缩短Stop The World停顿时间，与用户线程并发执行。
    • 分代收集：独立管理整个堆，但是能够采用不同的方式去处理新创建对象和已经存活了一段时间、熬过多次GC的旧对象，以获取更好的收集效果。
    • 空间整合：基于标记 - 整理算法，无内存碎片产生。
    • 可预测的停顿。能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
    • 使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分（可以不连续）Region的集合。

执行引擎

物理机的执行引擎是由硬件实现的，和物理机的执行过程不同的是虚拟机的执行引擎由于自己实现的。

执行引擎负责具体的代码调用及执行过程：
输入：字节码文件
处理：字节码解析
输出：执行结果。

类装载器装载负责装载编译后的字节码，并加载到运行时数据区（Runtime Data Area），然后执行引擎执行会执行这些字节码。

执行引擎以指令为单位读取Java字节码。它就像一个CPU一样，一条一条地执行机器指令。每个字节码指令都由一个1字节的操作码和附加的操作数组成。执行引擎取得一个操作码，然后根据操作数来执行任务，完成后就继续执行下一条操作码。不过Java字节码是用一种人类可以读懂的语言编写的，而不是用机器可以直接执行的语言。因此，执行引擎必须把字节码转换成可以直接被JVM执行的语言。 字节码可以通过以下两种方式转换成合适的语言：

• 解释器：一条一条地读取，解释并且执行字节码指令。因为它一条一条地解释和执行指令，所以它可以很快地解释字节码，但是执行起来会比较慢。这是解释执行的语言的一个缺点。字节码这种“语言”基本来说是解释执行的。
• 即时(Just-In-Time)编译器：即时编译器被引入用来弥补解释器的缺点。执行引擎首先按照解释执行的方式来执行，然后在合适的时候，即时编译器把整段字节码编译成本地代码。然后，执行引擎就没有必要再去解释执行方法了，它可以直接通过本地代码去执行它。执行本地代码比一条一条进行解释执行的速度快很多。编译后的代码可以执行的很快，因为本地代码是保存在缓存里的。

总结和调优

1、Minor GC、Full GC触发条件

• Minor GC触发条件
  • Eden区域满了，或者新创建的对象大小 > Eden所剩空间
  • Full GC的时候会先触发Minor GC
  • CMS设置了CMSScavengeBeforeRemark参数，这样在CMS的Remark之前会先做一次Minor GC来清理新生代，加速之后的Remark的速度。这样整体的stop-the-world时间反而短。
• Full GC触发条件
  • Minor GC后存活的对象晋升到老年代时由于悲观策略的原因，有两种情况会触发Full GC, 一种是之前每次晋升的对象的平均大小 > 老年代剩余空间；一种是Minor GC后存活的对象超过了老年代剩余空间。属于promotion failure。
  • 新生代直接晋升到老年代的大对象超过了老年代的剩余空间，引发Full GC。注意于promotion failure的区别，promotion failure指的是Minor GC后发生的担保失败
  • Perm永久代空间不足会触发Full GC，可以让CMS清理永久代的空间。设置CMSClassUnloadingEnabled即可
  • System.gc()引起的Full GC，可以设置DisableExplicitGC来禁止调用System.gc引发Full GC。
  • CMS失败，发生concurrent mode failure会引起Full GC，原因是老年代剩余的空间不够，导致了和gc线程并发执行的用户线程创建的大对象不能进入到老年代，只能stop the world来暂停用户线程，执行GC清理。可以通过设置CMSInitiatingOccupancyFraction预留合适的CMS执行时剩余的空间。

2、stop-the-world

不管选择哪种GC算法，stop-the-world都是不可避免的。Stop-the-world意味着从应用中停下来并进入到GC执行过程中去。一旦Stop-the-world发生，除了GC所需的线程外，其他线程都将停止工作，中断了的线程直到GC任务结束才继续它们的任务。GC调优通常就是为了改善stop-the-world的时间。

3、降低GC的调优的策略

• 代大小优化：-Xms、 -Xmx 、-Xmn 、-XX:SurvivorRatio、-XX:MaxTenuringThreshold、-XX:PermSize、-XX:MaxPermSize

  • -Xms、 -Xmx 通常设置为相同的值，避免运行时要不断扩展JVM内存，这个值决定了JVM heap所能使用的最大内存。
  • -Xmn 决定了新生代空间的大小，新生代Eden、S0、S1三个区域的比率可以通过-XX:SurvivorRatio来控制(假如值为 4 表示：Eden:S0:S1 = 4:3:3 )。
  • -XX:MaxTenuringThreshold 控制对象在经过多少次minor GC之后进入老年代，此参数只有在Serial 串行GC时有效。
  • -XX:PermSize、-XX:MaxPermSize 用来控制方法区的大小，通常设置为相同的值。
  • 策略：
    • 避免新生代大小设置过小：一是minor GC次数频繁，二是可能导致 minor GC对象直接进入老年代，当老年代内存不足时，会触发Full GC。
    • 避免新生代大小设置过大：一是老年代变小，可能导致Full GC频繁执行；二是 minor GC 执行回收的时间大幅度增加。
    • 避免Survivor区过大或过小：minor GC次数会降低或增加。
    • 合理设置对象在新生代存活的周期：新生代存活周期的值决定了新生代对象在经过多少次Minor GC后进入老年代。因此这个值要根据自己的应用来调优，Jvm参数上这个值对应的为-XX:MaxTenuringThreshold，默认值为15次。

• 减少GC开销的措施

  • 不要显式调用System.gc()：增加主GC的频率，也即增加了间歇性停顿的次数。大大的影响系统性能。
  • 尽量减少临时对象的使用。
  • 对象不用时最好显式置为Null：一般而言,为Null的对象都会被作为垃圾处理，所以将不用的对象显式地设为Null，有利于GC收集器判定垃圾，从而提高了GC的效率。
  • 尽量使用StringBuffer,而不用String来累加字符串：累加String对象时，并非在一个String对象中扩增，而是重新创建新的String对象，只会增加更多的垃圾。
  • 能用基本类型如int，就不用Integer对象：基本类型变量占用的内存资源比相应对象占用的少得多。
  • 尽量少用静态对象变量：静态变量属于全局变量，不会被GC回收，它们会一直占用内存。
  • 分散对象创建或删除的时间。

4、内存泄漏（MemoryLeak）和内存溢出（OutOfMemory）

• 内存泄漏：指程序在申请内存后，无法释放已申请的内存空间，一次内存泄漏似乎不会有大的影响，但内存泄漏堆积后的后果就是内存溢出。

• 内存溢出：指程序在申请内存时，没有足够的内存供申请者使用，或者说，给了你一块存储int类型数据的存储空间，但是你却存储long类型的数据，那么结果就是内存不够用，此时就会报错OOM,即所谓的内存溢出。

• 内存泄漏的分类：

  • 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
  • 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
  • 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。
  • 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

• 内存溢出的原因及解决方法：

  • 内存溢出原因：
    • 内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
    • 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
    • 代码中存在死循环或循环产生过多重复的对象实体；
    • 使用的第三方软件中的BUG；
    • 启动参数内存值设定的过小；
    • nio直接操作内存，内存过大导致溢出。
  • 内存溢出的解决方案：
    • 修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加)
    • 检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。
    • 对代码进行走查和分析，找出可能发生内存溢出的位置。
    • 查看是否使用了nio直接操作内存。

4、年轻代到年老代的晋升过程的判断条件

• 部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这个参数默认是15),最终如果还是存活,就存入到老年代。
• 如果对象的大小大于Eden的二分之一会直接分配在old，如果old也分配不下，会做一次major GC，如果小于eden的一半但是没有足够的空间，就进行minor gc也就是新生代GC。minor gc后，survivor仍然放不下，则放到老年代。
• 动态年龄判断 ，大于等于某个年龄的对象超过了survivor空间一半 ，大于等于某个年龄的对象直接进入老年代。

多有参考这两篇：
https://www.cnblogs.com/Java3y/p/9296496.html
https://blog.csdn.net/know9163/article/details/80574488
https://www.cnblogs.com/semi-sub/p/12827335.html