JVM学习总结

1 JVM内存管理

https://zhuanlan.zhihu.com/p/34426768

1.1 JVM运行时内存区域

作用 =》是否私有 =》 存储内容是什么 =》 是否出现OOM异常

Java 虚拟机在执行 Java 程序的过程中会把它管理的内存划分成若干个不同的数据区域。JDK. 1.8 和之前的版本略有不同，从图中可以看到方法区被替换成元空间。程序计数器、 虚拟机栈和本地方法栈为线程私有的，堆、方法区和直接内存是线程共享的:

JDK 1.8 之前：
JDK 1.8 之后：

1. 程序计数器

   线程私有 =》 不会出现OOM

   程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成。另外，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

   作用：

   • 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行、选择、循环、异常处理。
   • 在多线程的情况下，程序计数器用于记录当前线程执行的位置，从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了

   生命周期：

   随着线程的创建而创建，随着线程的消亡而结束

2. Java虚拟机栈

   线程私有 =》 会出现OOM和SOF

   每个方法被执行的时候，Java虚拟机都会同步创建一个栈帧，用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

   Java内存区域笼统地划分为堆内存（Heap）和栈内存（Stack）,而“栈”通常就是指这里讲的虚拟机栈，或者更多的情况下只是指虚拟机栈中局部变量表部分。局部变量表存放了编译期可知的各种Java虚拟机基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用

   生命周期：

   随着线程的创建而创建，随着线程的消亡而结束

3. 本地方法栈

   线程私有 =》 会出现OOM和SOF

   本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。

   本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

4. Java堆

   线程共享 =》 会出现OOM

   Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java世界里“几乎”所有的对象实例都在这里分配内存。Java堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。Java虚拟机都是按照可扩展来实现的（通过参数-Xmx和-Xms设定）。java堆又可细化分为：
   被视为连续的

5. 方法区

   线程共享 =》 会出现OOM

   方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

6. 运行时常量池

   线程共享 =》 会出现OOM

   运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表（Constant Pool Table），用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

7. 直接内存

   直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致 OutOfMemoryError 错误出现。

   JDK1.4 中新加入的 NIO(New Input/Output) 类，引入了一种基于通道（Channel） 与缓存区（Buffer） 的 I/O 方式，它可以直接使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样就能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆之间来回复制数据。

1.2 JVM 性能监控、故障处理工具

JVM 性能监控常用的工具有jps, jstat, jinfo, jmap, jhat, hstack

1. jps: (JVM Process Status Tool) 虚拟机进程状况工具

   可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class，main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（LVMID，Local Virtual Machine Identifier）。

   jps命令格式：

   jps [ options ] [ hostid ]
   

   jps执行样例：

   jps -l
   2388 D:\Develop\glassfish\bin\..\modules\admin-cli.jar
   2764 com.sun.enterprise.glassfish.bootstrap.ASMain
   3788 sun.tools.jps.Jps
   

   jps工具主要选项:
   

2. jstat: （JVM Statistics Monitoring Tool）虚拟机统计信息监视工具

   jstat是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程 虚拟机进程中的类加载、内存、垃圾收集、即时编译等运行时数据。

   jstat命令格式：

   jstat [ option vmid [interval[s|ms] [count]] ]
   
   // 对于命令格式中的VMID与LVMID需要特别说明一下：如果是本地虚拟机进程，VMID与LVMID是一致的；如果是远程虚拟机进程，那VMID的格式应当是：
   [protocol:][//]lvmid[@hostname[:port]/servername]
   
   // 参数interval和count代表查询间隔和次数，如果省略这2个参数，说明只查询一次。假设需要每250毫秒查询一次进程2764垃圾收集状况，一共查询20次，那命令应当是：
   jstat -gc 2764 250 20
   

   jstat执行样例：

   jstat -gcutil 2764
   S0 S1 E O P YGC YGCT FGC FGCT GCT
   0.00 0.00 6.20 41.42 47.20 16 0.105 3 0.472 0.577
   
   查询结果表明：这台服务器的新生代Eden区（E，表示Eden）使用了6.2%的空间;
   2个Survivor区（S0、S1，表示Survivor0、Survivor1）里面都是空的，老年代（O，表示Old）和永久代（P，表示Permanent）则分别使用了41.42%和47.20%的空间;
   程序运行以来共发生Minor GC（YGC，表示YoungGC）16次，总耗时0.105秒；
   发生Full GC（FGC，表示Full GC）3次，总耗时（FGCT，表示Full GCTime）为0.472秒；
   所有GC总耗时（GCT，表示GC Time）为0.577秒。
   

   选项option代表用户希望查询的虚拟机信息，主要分为三类：类加载、垃圾收集、运行期编译状况。详细请参考:
   

3. jinfo:（Configuration Info for Java） Java配置信息工具

   jinfo的作用是实时查看和调整虚拟机各项参数。

   jinfo命令格式：

   jinfo [ option ] pi
   

   jinfo执行样例：

   执行样例：查询CMSInitiatingOccupancyFraction参数值
   
   jinfo -flag CMSInitiatingOccupancyFraction 1444 -XX:CMSInitiatingOccupancyFraction=85
   

4. jmap: （Memory Map for Java）Java内存映像工具
   jmap命令用于生成堆转储快照（一般称为heapdump或dump文件）。jmap的作用并不仅仅是为了获取堆转储快照，它还可以查询finalize执行队列、Java堆和方法区的详细信息，如空间使用率、当前用的是哪种收集器等。
   jmap命令格式：

   jmap [ option ] vmid
   

   jmap执行样例：

   jmap -dump:format=b,file=eclipse.bin 3500
   Dumping heap to C:\Users\IcyFenix\eclipse.bin ...
   Heap dump file created
   

   option选项的合法值与具体含义如下：
   

5. ```jhat``: （JVM Heap Analysis Tool）虚拟机堆转储快照分析工具

   JDK提供jhat命令与jmap搭配使用，来分析jmap生成的堆转储快照。

   jhat执行样例：

   jhat eclipse.bin
   Reading from eclipse.bin...
   Dump file created Fri Nov 19 22:07:21 CST 2010
   Snapshot read, resolving...
   Resolving 1225951 objects...
   Chasing references, expect 245 dots....
   Eliminating duplicate references...
   Snapshot resolved.
   Started HTTP server on port 7000
   Server is ready.
   

   屏幕显示“Server is ready.”的提示后，用户在浏览器中输入http://localhost:7000/可以看到分析结果。

   分析结果默认以包为单位进行分组显示，分析内存泄漏问题主要会使用到其中的“HeapHistogram”（与jmap-histo功能一样）与OQL页签的功能，前者可以找到内存中总容量最大的对象，后者是标准的对象查询语言，使用类似SQL的语法对内存中的对象进行查询统计。

6. jstack： （Stack Trace for Java）Java堆栈跟踪工具

   jstack（Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照（一般称为threaddump或者javacore文件）。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的目的通常是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间挂起等，都是导致线程长时间停顿的常见原因。线程出现停顿时通过jstack来查看各个线程的调用堆栈，就可以获知没有响应的线程到底在后台做些什么事情，或者等待着什么资源。

   jstack命令格式：

   jstack [ option ] vmid
   

   jstack执行样例：

   使用jstack查看Eclipse线程堆栈的例子，例子中的3500是通过jps命令查询到的LVMID
   
   jstack -l 3500
   2010-11-19 23:11:26
   Full thread dump Java HotSpot(TM) 64-Bit Server VM (17.1-b03 mixed mode):
   "[ThreadPool Manager] - Idle Thread" daemon prio=6 tid=0x0000000039dd4000 nid= 0xf50 in Object.wait() [ 0x000000003c96f000]
   java.lang.Thread.State: WAITING (on object monitor)
   at java.lang.Object.wait(Native Method)
   - waiting on <0x0000000016bdcc60> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor)
   at java.lang.Object.wait(Object.java:485)
   at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run (Executor. java:106)
   - locked <0x0000000016bdcc60> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor)
   Locked ownable synchronizers:
   - None
   

7. 基础工具：用于支持基本的程序创建和运行

   

1.3 JVM OutOfMemoryError异常

1. 堆 OOM

   Java堆用于储存对象实例，我们只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么随着对象数量的增加，总容量触及最大堆的容量限制后就会产生内存溢出异常。

   限制Java堆的大小为20MB，不可扩展（将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展），通过参数-XX：+HeapDumpOnOutOf-MemoryError可以让虚拟机在出现内存溢出异常的时候Dump出当前的内存堆转储快照以便进行事后分析：

   代码：

   /**
   * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
   */
   public class HeapOOM {
      static class OOMObject {
   
      }
   
      public static void main(String[] args) {
          List<OOMObject> list = new ArrayList<>();
   
          while (true) {
              list.add(new OOMObject());
          }
      }
   
   }
   

   输出结果：

   java.lang.OutOfMemoryError: Java heap space
   Dumping heap to java_pid23220.hprof ...
   Heap dump file created [28250156 bytes in 0.075 secs]
   Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
   	at java.util.Arrays.copyOf(Arrays.java:3210)
   	at java.util.Arrays.copyOf(Arrays.java:3181)
   	at java.util.ArrayList.grow(ArrayList.java:261)
   	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
   	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
   	at java.util.ArrayList.add(ArrayList.java:458)
   	at 深入理解JVM.第二章.HeapOOM.main(HeapOOM.java:18)
   

2. 虚拟机栈和本地方法栈 OOM
   对于HotSpot来说，-Xoss参数（设置本地方法栈大小）虽然存在，但实际上是没有任何效果的，栈容量只能由-Xss参数来设定。关于虚拟机栈和本地方法栈，在《Java虚拟机规范》中描述了两种异常：

   • 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常
   • 如果虚拟机的栈内存允许动态扩展，当扩展栈容量无法申请到足够的内存时，将抛出OutOfMemoryError异常

   《Java虚拟机规范》明确允许Java虚拟机实现自行选择是否支持栈的动态扩展，而HotSpot虚拟机的选择是不支持扩展，所以除非在创建线程申请内存时就因无法获得足够内存而出现OutOfMemoryError异常，否则在线程运行时是不会因为扩展而导致内存溢出的，只会因为栈容量无法容纳新的栈帧而导致StackOverflowError异常。为了验证这点，我们可以做两个实验，先将实验范围限制在单线程中操作，尝试下面两种行为是否能让HotSpot虚拟机产生OutOfMemoryError异常：

   • 使用-Xss参数减少栈内存容量。

     结果：抛出StackOverflowError异常，异常出现时输出的堆栈深度相应缩小。

     代码：

     /**
      * VM Args：-Xss128k
      */
     public class JavaVMStackSOF {
         private int stackLength = 1;
         public void stackLeak() {
             stackLength++;
             stackLeak();
         }
     
         public static void main(String[] args) throws Throwable {
             JavaVMStackSOF oom = new JavaVMStackSOF();
             try {
                 oom.stackLeak();
             } catch (Throwable e) {
                 System.out.println("stack length:" + oom.stackLength);
                 throw e;
             }
         }
     }
     

     输出结果：

     stack length:984
     Exception in thread "main" java.lang.StackOverflowError
     	at 深入理解JVM.第二章.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:9)
     	at 深入理解JVM.第二章.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:10)
     	at 深入理解JVM.第二章.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:10)
     	at 深入理解JVM.第二章.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:10)
     

   • 定义了大量的本地变量，增大此方法帧中本地变量表的长度。
     结果：抛出StackOverflowError异常，异常出现时输出的堆栈深度相应缩小。

     代码：

     public class JavaVMStackSOF2 {
     private static int stackLength = 0;
     
     public static void test() {
         long unused1, unused2, unused3, unused4, unused5,
                 unused6, unused7, unused8, unused9, unused10,
                 unused11, unused12, unused13, unused14, unused15,
                 unused16, unused17, unused18, unused19, unused20,
                 unused21, unused22, unused23, unused24, unused25,
                 unused26, unused27, unused28, unused29, unused30,
                 unused31, unused32, unused33, unused34, unused35,
                 unused36, unused37, unused38, unused39, unused40,
                 unused41, unused42, unused43, unused44, unused45,
                 unused46, unused47, unused48, unused49, unused50,
                 unused51, unused52, unused53, unused54, unused55,
                 unused56, unused57, unused58, unused59, unused60,
                 unused61, unused62, unused63, unused64, unused65,
                 unused66, unused67, unused68, unused69, unused70,
                 unused71, unused72, unused73, unused74, unused75,
                 unused76, unused77, unused78, unused79, unused80,
                 unused81, unused82, unused83, unused84, unused85,
                 unused86, unused87, unused88, unused89, unused90,
                 unused91, unused92, unused93, unused94, unused95,
                 unused96, unused97, unused98, unused99, unused100;
     
         stackLength ++;
         test();
     
         unused1 = unused2 = unused3 = unused4 = unused5 =
         unused6 = unused7 = unused8 = unused9 = unused10 =
         unused11 = unused12 = unused13 = unused14 = unused15 =
         unused16 = unused17 = unused18 = unused19 = unused20 =
         unused21 = unused22 = unused23 = unused24 = unused25 =
         unused26 = unused27 = unused28 = unused29 = unused30 =
         unused31 = unused32 = unused33 = unused34 = unused35 =
         unused36 = unused37 = unused38 = unused39 = unused40 =
         unused41 = unused42 = unused43 = unused44 = unused45 =
         unused46 = unused47 = unused48 = unused49 = unused50 =
         unused51 = unused52 = unused53 = unused54 = unused55 =
         unused56 = unused57 = unused58 = unused59 = unused60 =
         unused61 = unused62 = unused63 = unused64 = unused65 =
         unused66 = unused67 = unused68 = unused69 = unused70 =
         unused71 = unused72 = unused73 = unused74 = unused75 =
         unused76 = unused77 = unused78 = unused79 = unused80 =
         unused81 = unused82 = unused83 = unused84 = unused85 =
         unused86 = unused87 = unused88 = unused89 = unused90 =
         unused91 = unused92 = unused93 = unused94 = unused95 =
             unused96 = unused97 = unused98 = unused99 = unused100 = 0;
         }
     
     	    public static void main(String[] args) {
     	        try {
     	            test();
     	        }catch (Error e){
     	            System.out.println("stack length:" + stackLength);
     	            throw e;
     	        }
     	    }
     	}
     }
     

     输出结果：

     stack length:7000
     Exception in thread "main" java.lang.StackOverflowError
     	at 深入理解JVM.第二章.JavaVMStackSOF2.test(JavaVMStackSOF2.java:29)
     	at 深入理解JVM.第二章.JavaVMStackSOF2.test(JavaVMStackSOF2.java:29)
     	at 深入理解JVM.第二章.JavaVMStackSOF2.test(JavaVMStackSOF2.java:29)
     	at 深入理解JVM.第二章.JavaVMStackSOF2.test(JavaVMStackSOF2.java:29)
     

     实验结果表明：无论是由于栈帧太大还是虚拟机栈容量太小，当新的栈帧内存无法分配的时候，HotSpot虚拟机抛出的都是StackOverflowError异常。可是如果在允许动态扩展栈容量大小的虚拟机上，相同代码则会导致不一样的情况。

3. 方法区和运行时常量池 OOM
   由于运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放到一起进行。HotSpot从JDK 7开始逐步“去永久代”的计划，并在JDK 8中完全使用元空间来代替永久代，在此我们就以测试代码来观察一下，使用“永久代”还是“元空间”来实现方法区，对程序有什么实际的影响。

   String::intern()是一个本地方法，它的作用是如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象的引用；否则，会将此String对象包含的字符串添加
   到常量池中，并且返回此String对象的引用。在JDK 6或更早之前的HotSpot虚拟机中，常量池都是分配在永久代中，我们可以通过-XX：PermSize和-XX：MaxPermSize限制永久代的大小，即可间接限制其中常量池的容量，具体实现如下代码所示，测试时首先以JDK 6来运行代码：

   /**
    * VM Args：-XX:PermSize=6M -XX:MaxPermSize=6M
    * @author zzm
    */
   public class RuntimeConstantPoolOOM {
       public static void main(String[] args) {
   // 使用Set保持着常量池引用，避免Full GC回收常量池行为
           Set<String> set = new HashSet<String>();
   // 在short范围内足以让6MB的PermSize产生OOM了
           short i = 0;
           while (true) {
               set.add(String.valueOf(i++).intern());
           }
       }
   }
   

   运行结果：

   Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
   at java.lang.String.intern(Native Method)
   at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java: 18)
   

   从运行结果中可以看到，运行时常量池溢出时，在OutOfMemoryError异常后面跟随的提示信息是“PermGen space”，说明运行时常量池的确是属于方法区（即JDK 6的HotSpot虚拟机中的永久代）的一部分。

   而使用JDK 7或更高版本的JDK来运行这段程序并不会得到相同的结果，无论是在JDK 7中继续使用-XX：MaxPermSize参数或者在JDK 8及以上版本使用-XX：MaxMeta-spaceSize参数把方法区容量同样限制在6MB，也都不会重现JDK 6中的溢出异常，循环将一直进行下去，永不停歇 。出现这种变化，是因为自JDK 7起，原本存放在永久代的字符串常量池被移至Java堆之中。

   String.intern()返回引用的测试
   代码：

   public class RuntimeConstantPoolOOM {
       public static void main(String[] args) {
           String str1 = new StringBuilder("计算机").append("软件").toString();
           System.out.println(str1.intern() == str1);
           String str2 = new StringBuilder("ja").append("va").toString();
           System.out.println(str2.intern() == str2);
       }
   }
   

   这段代码在JDK 6中运行，会得到两个false，而在JDK 7中运行，会得到一个true和一个false。产生差异的原因是，在JDK 6中，intern()方法会把首次遇到的字符串实例复制到永久代的字符串常量池中存储，返回的也是永久代里面这个字符串实例的引用，而由StringBuilder创建的字符串对象实例在Java堆上，所以必然不可能是同一个引用，结果将返回false。

   而JDK 7（以及部分其他虚拟机，例如JRockit）的intern()方法实现就不需要再拷贝字符串的实例到永久代了，既然字符串常量池已经移到Java堆中，那只需要在常量池里记录一下首次出现的实例引用即可，因此intern()返回的引用和由StringBuilder创建的那个字符串实例就是同一个。而对str2比较返回false，这是因为“java”这个字符串在执行String-Builder.toString()之前就已经出现过了，字符串常量池中已经有它的引用，不符合intern()方法要求“首次遇到”的原则，“计算机软件”这个字符串则是首次出现的，因此结果返回true。

1.4 JVM堆内存

https://www.cnblogs.com/snowwhite/p/9532311.html

Java 中的堆是 JVM 所管理的最大的一块内存空间，主要用于存放各种类的实例对象，如下图所示：

在 Java 中，堆被划分成两个不同的区域：新生代 ( Young )、老年代 ( Old)。新生代 ( Young ) 又被划分为三个区域：Eden、S0、S1。 这样划分的目的是为了使 JVM 能够更好的管理堆内存中的对象，包括内存的分配以及回收。

Java 中的堆也是 GC 收集垃圾的主要区域。GC 分为两种：Minor GC、Full GC ( 或称为 Major GC )。

1. 新生代(年轻代)

   年轻代用来存放新近创建的对象，尺寸随堆大小的增大和减小而相应的变化，默认值是保持为堆大小的1/15，可以通过 -Xmn 参数设置年轻代为固定大小，也可以通过 -XX:NewRatio 来设置年轻代与年老代的大小比例，年青代的特点是对象更新速度快，在短时间内产生大量的“死亡对象”。

   年轻代的特点是产生大量的死亡对象,并且要是产生连续可用的空间, 所以使用复制清除算法和并行收集器进行垃圾回收.对年轻代的垃圾回收称作初级回收 (minor gc)。

   初级回收将年轻代分为三个区域, 一个新生代 , 2个大小相同的复活代, 应用程序只能使用一个新生代和一个复活代, 当发生初级垃圾回收的时候,gc挂起程序, 然后将新生代和复活代中的存活对象复制到另外一个非活动的复活代中,然后一次性清除新生代和复活代，将原来的非复活代标记成为活动复活代。将在指定次数回收后仍然存在的对象移动到老年代中，初级回收后，得到一个空的可用的新生代。

   新生代几乎是所有 Java 对象出生的地方，即 Java 对象申请的内存以及存放都是在这个地方。Java 中的大部分对象通常不需长久存活，具有朝生夕灭的性质。 当一个对象被判定为 “死亡” 的时候，GC 就有责任来回收掉这部分对象的内存空间。新生代是 GC 收集垃圾的频繁区域。 当对象在 Eden 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域中，然后清理所使用过的 Eden 以及 Survivor 区域，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定 )，这些对象就会成为老年代。 但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。

2. 老年代

   Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。

   现实的生活中，老年代的人通常会比新生代的人 “早死”。堆内存中的老年代(Old)不同于这个，老年代里面的对象几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 “死掉” 了的。因此，Full GC 发生的次数不会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。 另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 ( 即不连续的内存空间 )，此后需要为较大的对象分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。

1.5 对象的创建

1. 对象的创建过程
   下图便是 Java 对象的创建过程，我建议最好是能默写出来，并且要掌握每一步在做什么：
   

   1、类加载检查：虚拟机遇到一条 new 指令时，首先将去检查这个指令的参数是否能在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否已被加载过、解析和初始化过。如果没有，那必须先执行相应的类加载过程。
   2、分配内存：在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定，为对象分配空间的任务等同于把一块确定大小的内存从 Java 堆中划分出来。分配方式有 “指针碰撞” 和 “空闲列表” 两种，选择哪种分配方式由 Java 堆是否规整决定，而 Java 堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。
   3、初始化零值: 内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），这一步操作保证了对象的实例字段在 Java 代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。
   4、设置对象头:初始化零值完成之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。 这些信息存放在对象头中。 另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。
   4、执行 init 方法:在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了，但从 Java 程序的视角来看，对象创建才刚开始， 方法还没有执行，所有的字段都还为零。所以一般来说，执行 new 指令之后会接着执行 方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

   补充（对象的内存布局、 对象的访问定位、内存分配并发问题）：

   1. 对象的内存布局

      在 Hotspot 虚拟机中，对象在内存中的布局可以分为 3 块区域：对象头、实例数据和对齐填充。

      • 对象头: Hotspot 虚拟机的对象头包括两部分信息，第一部分用于存储对象自身的运行时数据（哈希码、GC 分代年龄、锁状态标志等等），另一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是那个类的实例。
      • 实例数据: 实例数据部分是对象真正存储的有效信息，也是在程序中所定义的各种类型的字段内容。
      • 对齐填充: 对齐填充部分不是必然存在的，也没有什么特别的含义，仅仅起占位作用。 因为 Hotspot 虚拟机的自动内存管理系统要求对象起始地址必须是 8 字节的整数倍，换句话说就是对象的大小必须是 8 字节的整数倍。而对象头部分正好是 8 字节的倍数（1 倍或 2 倍），因此，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

   2. 对象的访问定位

      主流的访问方式主要有使用句柄和直接指针两种,选择以上两种方式中的哪一种，取决于 Java 堆内存是否规整。而 Java 堆内存是否规整，取决于 GC 收集器的算法是"标记-清除"，还是"标记-整理"（也称作"标记-压缩"），值得注意的是，复制算法内存也是规整的。
      如果使用句柄访问的话，Java堆中将可能会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息，其结构如图所示。
      
      如果使用直接指针访问的话，Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息，reference中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问的开销，如图所示。
      这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要被修改。使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访问在Java中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本。HotSpot主要使用第二种方式进行对象访问。

   3. 内存分配并发问题

      在创建对象的时候有一个很重要的问题，就是线程安全，因为在实际开发过程中，创建对象是很频繁的事情，作为虚拟机来说，必须要保证线程是安全的，通常来讲，虚拟机采用两种方式来保证线程安全：

      • CAS+失败重试： CAS 是乐观锁的一种实现方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用 CAS 配上失败重试的方式保证更新操作的原子性。
      • TLAB： 为每一个线程预先在 Eden 区分配一块儿内存，JVM 在给线程中的对象分配内存时，首先在 TLAB 分配，当对象大于 TLAB 中的剩余内存或 TLAB 的内存已用尽时，再采用上述的 CAS 进行内存分配。

   4. 指针碰撞和空闲列表

      假设Java堆中内存是绝对规整的，所有被使用过的内存都被放在一边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump ThePointer）。但如果Java堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”（Free List）。

1.6 JVM内存分配原则

大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 s0 或者 s1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold来设置。

• 对象优先在 eden 区分配
  对象在新生代中 eden 区分配。当 eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。
• 大对象直接进入老年代
  大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。（之所以这样，是为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。）
• 长期存活的对象将进入老年代
• 动态对象年龄判定

1.7 如何判断对象是否可回收

对于判断一个对象是否可以回收，我们通常使用引用计数法和可达性分析算法。

引用计数法： 在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

可达性分析算法： 这个算法的基本思路就是通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

如图所示对象object 5、object 6、object 7虽然互有关联，但是它们到GC Roots是不可达的，因此它们将会被判定为可回收的对象。

重要！！！在Java技术体系里面，固定可作为GC Roots的对象包括以下几种：

• 在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
• 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
• 在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
• 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
• Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
• 所有被同步锁（synchronized关键字）持有的对象。
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。

补充问题：

• 对象的引用问题
  无论是通过引用计数法判断对象引用数量，还是通过可达性分析法判断对象的引用链是否可达，判定对象的存活都与“引用”有关。

  JDK1.2 之前，Java 中引用的定义很传统：如果 reference 类型的数据存储的数值代表的是另一块内存的起始地址，就称这块内存代表一个引用。

  JDK1.2 以后，Java 对引用的概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）。

  强引用: 如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。
  
  软引用: 软引用是用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2版之后提供了SoftReference类来实现软引用。
  
  弱引用: 弱引用也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2版之后提供了WeakReference类来实现弱引用。(弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。)
  
  虚引用: 虚引用也称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2版之后提供了PhantomReference类来实现虚引用。
  

• 不可达的对象是否“非死不可”
  即使在可达性分析法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑阶段”，要真正宣告一个对象死亡，至少要经历两次标记过程；可达性分析法中不可达的对象被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行 finalize 方法。当对象没有覆盖 finalize 方法，或 finalize 方法已经被虚拟机调用过时，虚拟机将这两种情况视为没有必要执行。

  如果这个对象被判定为确有必要执行finalize()方法，那么该对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法。这里所说的“执行”是指虚拟机会触发这个方法开始运行，但并不承诺一定会等待它运行结束。这样做的原因是，如果某个对象的finalize()方法执行缓慢，或者更极端地发生了死循环，将很可能导致F-Queue队列中的其他对象永久处于等待，甚至导致整个内存回收子系统的崩溃。finalize()方法是对象逃脱死亡命运的最后一次机会，稍后收集器将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this关键字）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的集合；如果对象这时候还没有逃脱，那基本上它就真的要被回收了。从代码清单3-2中我们可以看到一个对象的finalize()被执行，但是它仍然可以存活。

• 如何判断一个常量是废弃常量
  假如一个字符串“java”曾经进入常量池中，但是当前系统又没有任何一个字符串对象的值是“java”，换句话说，已经没有任何字符串对象引用常量池中的“java”常量，且虚拟机中也没有其他地方引用这个字量。如果在这时发生内存回收，而且垃圾收集器判断确有必要的话，这个“java”常量就将会被系统清理出常量池。常量池中其他类（接口）、方法、字段的符号引用也与此类似。

• 如何判断一个类是无用的类
  要判定一个类型是否属于“不再被使用的类”的条件比较苛刻了。需要同时满足下面三个条件：

  1. 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例
  2. 加载该类的类加载器已经被回收(这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的)
  3. 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

2 垃圾收集器与垃圾回收算法

2.1 垃圾收集算法

1. 分代收集

   当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。

   比如在新生代中，每次收集都会有大量对象死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

   为什么要采用分代收集方法？

   如果一个区域中大多数对象都是朝生夕灭，难以熬过垃圾收集过程的话，那么把它们集中放在一起，每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象，就能以较低代价回收到大量的空间；如果剩下的都是难以消亡的对象，那把它们集中放在一块，虚拟机便可以使用较低的频率来回收这个区域，这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。

   注意：

   部分收集（Partial GC）：指目标不是完整收集整个Java堆的垃圾收集，其中又分为：

   新生代收集（Minor GC/Young GC）：指目标只是新生代的垃圾收集。
   老年代收集（Major GC/Old GC）：指目标只是老年代的垃圾收集。目前只有CMS收集器会有单独收集老年代的行为。另外请注意“Major GC”这个说法现在有点混淆，在不同资料上常有不同所指，读者需按上下文区分到底是指老年代的收集还是整堆收集。
   混合收集（Mixed GC）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有G1收 集器会有这种行为。

   整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。

2. 标记-清除

   如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。

   它的主要缺点有两个：第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低；第二个是内存空间的碎片化问题，标记、清除之后会产生大
   量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

   标记-清除算法的执行过程如图：
   

3. 标记-复制

   它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

   缺点：如果内存中多数对象都是存活的，这种算法将会产生大量的内存间复制的开销，将可用内存缩小为了原来的一半，空间浪费未免太多了一点。

   优点：但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。这样实现简单，运行高效。

   标记-复制算法的执行过程如图：
   
   补充（分配担保，Appel式回收）：

   Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也即每次新生代中可用内存空间为整个新生代容量的90%（Eden的80%加上一个Survivor的10%），只有一个Survivor空间，即10%的新生代是会被“浪费”的。当然，98%的对象可被回收仅仅是“普通场景”下测得的数据，任何人都没有办法百分百保证每次回收都只有不多于10%的对象存活，因此Appel式回收还有一个充当罕见情况的“逃生门”的安全设计，当Survivor空间不足以容纳一次Minor GC之后存活的对象时，就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保（Handle Promotion）。

4. 复制-整理

   标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存，“标记-整理”算法的示意图如图：
   缺点： 会出现Stop The World。

   如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行 ，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机设计者形象地描述为“Stop The World” 。

2.2 HotSpot算法实现细节

2.3 垃圾收集器

图中展示了七种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用 ，图中收集器所处的区域，则表示它是属于新生代收集器抑或是老年代收集器。

Serial收集器（新生代）

这个收集器是一个单线程工作的收集器，意味着这个它只会使用一个处理器或一条收集线程去完成垃圾收集工作。进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。即会出现“stop the world”。

通常用于客户端，适用于单核心CPU环境，没有线程交互的开销，有最高的单线程收集效率。

ParNew收集器（新生代）

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。它是许多运行在 Server 模式下的虚拟机的首要选择，除了 Serial 收集器外，只有它能与 CMS 收集器（真正意义上的并发收集器，后面会介绍到）配合工作。

Parallel Scavenge收集器（新生代）

Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值。 Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量，如果对于收集器运作不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。

Parallel Scavenge收集器是JDK8默认的垃圾收集器。

-XX:+UseParallelGC 

    使用 Parallel 收集器+ 老年代串行

-XX:+UseParallelOldGC

    使用 Parallel 收集器+ 老年代并行

使用java -XX:+PrintCommandLineFlags -version命令查看:

-XX:InitialHeapSize=262921408 -XX:MaxHeapSize=4206742528 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC 
java version "1.8.0_211"
Java(TM) SE Runtime Environment (build 1.8.0_211-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)

JDK1.8默认使用的是Parallel Scavenge + Parallel Old，如果指定了-XX:+UseParallelGC参数，则默认指定了-XX:+UseParallelOldGC，可以使用-XX:-UseParallelOldGC来禁用该功能

Serial Old收集器(老年代)

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。如果在服务端模式下，它也可能有两种用途：一种是在JDK 5以及之前的版本中与Parallel Scavenge收集器搭配使用 ，另外一种就是作为CMS收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用。
Parallel Old收集器 （老年代）

Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。
CMS收集器（老年代）

CMS收集器是基于标记清除算法，并发收集、低停顿实现的垃圾收集器。

它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为四个步骤，包括：

• 初始标记（CMS initial mark） 会出现“Stop The World”

  初始标记仅仅只是标记一下GCRoots能直接关联到的对象，速度很快；

• 并发标记（CMS concurrent mark）

  并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；

• 重新标记（CMS remark） 会出现“Stop The World”

  而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；

• 并发清除（CMS concurrent sweep）

  并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面三个明显的缺点：

• CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用程序变慢，降低总吞吐量。
• 由于CMS收集器无法处理“浮动垃圾”（Floating Garbage），有可能出现“Con-current ModeFailure”失败进而导致另一次完全“Stop The World”的Full GC的产生。在CMS的并发标记和并发清理阶段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。
• CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。可能回导致频繁full gc。

Garbage First收集器（G1）

G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征。

G1跳出了分代收集这个樊笼，它可以面向堆内存任何部分来组成回收集（Collection Set，一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，Region中还有一类特殊Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。

G1被视为 JDK1.7 中 HotSpot 虚拟机的一个重要进化特征。它具备以下特点：

• 并行与并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。
• 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。
• 空间整合：与 CMS 的“标记–清理”算法不同，G1 从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。
• 可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。

G1收集器的运作过程大致可划分为以下四个步骤：

• 初始标记
  仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
• 并发标记
  从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引用变动的对象。
• 最终标记
  对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。
• 筛选回收
  负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

3 JVM类加载

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称为连接（Linking）。这七个阶段的发生顺序如图：

3.1 JVM类加载过程/时机

1. 加载

   在加载阶段，Java虚拟机需要完成以下三件事情：

   1. 通过一个类的全限定名来获取定义此类的二进制字节流。
   2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
   3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

   Java虚拟机规范》对这三点要求其实并不是特别具体，例如“通过一个类的全限定名来获取定义此类的二进制字节流”这条规则，它并没有指明二进制字节流必须得从某个Class文件中获取，确切地说是根本没有指明要从哪里获取、如何获取。仅仅这一点空隙，Java虚拟机的使用者们就可以在加载阶段搭构建出一个相当开放广阔的舞台。
   例如：
   1. 从ZIP压缩包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
   2. 从网络中获取，这种场景最典型的应用就是Web Applet。
   3. 运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass()来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
   4. 由其他文件生成，典型场景是JSP应用，由JSP文件生成对应的Class文件。
   等等。。。

   注意：加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的一部分，这两个阶段的开始时间仍然保持着固定的先后顺序。

2. 连接（验证 =》准备 =》 解析）

   1. 验证

      验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证和符号引用验证。

      文件格式验证
      第一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证点：

      1. 是否以魔数0xCAFEBABE开头。
      2. 主、次版本号是否在当前Java虚拟机接受范围之内。
      3. 常量池的常量中是否有不被支持的常量类型（检查常量tag标志）
      4. 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
      5. ......

      元数据验证
      
      第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要求，这个阶段可能包括的验证点如下：

      1. 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
      2 . 这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
      3. 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
      4. ......

      字节码验证
      
      第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流分析和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型校验完毕以后，这阶段就要对类的方法体（Class文件中的Code属性）进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为，例如：

      1. 证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于“在操作栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中”这样的情况。
      2. 保证任何跳转指令都不会跳转到方法体以外的字节码指令上。
      3. ……

      符号引用验证
      
      符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。本阶段通常需要校验下列内容：

      1. 符号引用中通过字符串描述的全限定名是否能找到对应的类。
      2. 在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。
      3. 符号引用中的类、字段、方法的可访问性（privateprotected、public、）是否可被当前类访问。
      4. ……

   2. 准备

      准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

      (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。

      Java中所有基本数据类型的零值（默认初始化值）如下：
      

   3. 解析

      解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行。

      符号引用就是一组符号来描述目标，可以是任何字面量。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。在程序实际运行时，只有符号引用是不够的，举个例子：在程序执行方法时，系统需要明确知道这个方法所在的位置。Java 虚拟机为每个类都准备了一张方法表来存放类中所有的方法。当需要调用一个类的方法的时候，只要知道这个方法在方发表中的偏移量就可以直接调用该方法了。通过解析操作符号引用就可以直接转变为目标方法在类中方法表的位置，从而使得方法可以被调用。

      综上，解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，也就是得到类或者字段、方法在内存中的指针或者偏移量。

3. 初始化

   初始化是类加载的最后一步，也是真正执行类中定义的 Java 程序代码(字节码)，初始化阶段是执行初始化方法 ()方法的过程。

   对于（） 方法的调用，虚拟机会自己确保其在多线程环境中的安全性。因为 （） 方法是带锁线程安全，所以在多线程环境下进行类初始化的话可能会引起死锁，并且这种死锁很难被发现。

   对于初始化阶段，虚拟机严格规范了有且只有5种情况下，必须对类进行初始化(只有主动去使用类才会初始化类)：

   1. 当遇到 new 、 getstatic、putstatic或invokestatic 这4条直接码指令时，比如 new 一个类，读取一个静态字段(未被 final 修饰)、或调用一个类的静态方法时。
      （1）当jvm执行new指令时会初始化类。即当程序创建一个类的实例对象。
      （2）当jvm执行getstatic指令时会初始化类。即程序访问类的静态变量(不是静态常量，常量会被加载到运行时常量池)。
      （3）当jvm执行putstatic指令时会初始化类。即程序给类的静态变量赋值。
      （4）当jvm执行invokestatic指令时会初始化类。即程序调用类的静态方法。
   2. 使用 java.lang.reflect 包的方法对类进行反射调用时如Class.forname("…"),newInstance()等等。 ，如果类没初始化，需要触发其初始化。
   3. 初始化一个类，如果其父类还未初始化，则先触发该父类的初始化。
   4. 当虚拟机启动时，用户需要定义一个要执行的主类 (包含 main 方法的那个类)，虚拟机会先初始化这个类。
   5. MethodHandle和VarHandle可以看作是轻量级的反射调用机制，而要想使用这2个调用， 就必须先使用findStaticVarHandle来初始化要调用的类。
   6. 当一个接口中定义了JDK8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

3.2 JVM类加载器

Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”（Class Loader）。

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

3.2.1 双亲委派模型

站在Java虚拟机的角度来看，只存在两种不同的类加载器：一种是启动类加载器（BootstrapClassLoader），这个类加载器使用C++语言实现 ，是虚拟机自身的一部分；另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

自JDK 1.2以来，Java一直保持着三层类加载器、双亲委派的类加载架构，绝大多数Java程序都会使用到以下3个系统提供的类加载器来进行加载：

• 启动类加载器（Bootstrap Class Loader）：前面已经介绍过，这个类加载器负责加载存放在<JAVA_HOME>\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。（启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可）
• 扩展类加载器（Extension Class Loader）：这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。
• 应用程序类加载器（Application Class Loader）：这个类加载器由sun.misc.Launcher$AppClassLoader来实现。由于应用程序类加载器是ClassLoader类中的getSystem-ClassLoader()方法的返回值，所以有些场合中也称它为“系统类加载器”。它负责加载用户类路径
  （ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

JDK 9之前的Java应用都是由这三种类加载器互相配合来完成加载的，如果用户认为有必要，还可以加入自定义的类加载器来进行拓展，典型的如增加除了磁盘位置之外的Class文件来源，或者通过类加载器实现类的隔离、重载等功能。这些类加载器之间的协作关系“通常”会如下图：

上图中展示的各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents DelegationModel）”。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

双亲委派模型的实现源码：

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
{
	// 首先，检查请求的类是否已经被加载过了
	Class c = findLoadedClass(name);
	if (c == null) {
		try {
			if (parent != null) {
				c = parent.loadClass(name, false);
			} else {
				c = findBootstrapClassOrNull(name);
			}
		} catch (ClassNotFoundException e) {
		// 如果父类加载器抛出ClassNotFoundException
		// 说明父类加载器无法完成加载请求
	}
	if (c == null) {
			// 在父类加载器无法加载时
			// 再调用本身的findClass方法来进行类加载
			c = findClass(name);
		}
	}
	if (resolve) {
		resolveClass(c);
	}
	return c;
}

这段代码的逻辑清晰易懂：先检查请求加载的类型是否已经被加载过，若没有则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。假如父类加载器加载失败，抛出ClassNotFoundException异常的话，才调用自己的findClass()方法尝试进行加载。

3.2.2 破坏双亲委派模型

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK 1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题（越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK 1.3时加入到rt.jar的），肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口（Service Provider Interface，SPI）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContext-ClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的，这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等。说白了就是希望Java应用程序能像我们的电脑外设那样，接上鼠标、U盘，不用重启机器就能立即使用，鼠标有问题或要升级就换个鼠标，不用关机也不用重启。对于个人电脑来说，重启一次其实没有什么大不了的，但对于一些生产系统来说，关机重启一次可能就要被列为生产事故，这种情况下热部署就对软件开发者，尤其是大型系统或企业级软件开发者具有很大的吸引力。OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：

• 将以java.*开头的类，委派给父类加载器加载。
• 否则，将委派列表名单内的类，委派给父类加载器加载。
• 否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。
• 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
• 否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
• 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
• 否则，类查找失败。

上面的查找顺序中只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的。

其他一些JVM面试问题

1 深拷贝和浅拷贝

浅拷贝（shallowCopy）只是增加了一个指针指向已存在的内存地址，深拷贝（deepCopy）是增加了一个指针并且申请了一个新的内存，使这个增加的指针指向这个新的内存，使用深拷贝的情况下，释放内存的时候不会因为出现浅拷贝时释放同一个内存的错误。

浅复制：仅仅是指向被复制的内存地址，如果原地址发生改变，那么浅复制出来的对象也会相应的改变。深复制：在计算机中开辟一块新的内存地址用于存放复制的对象。

2 JVM线上内存、CPU占用率百分之百如何分析及解决

==》线上Java 高CPU占用、高内存占用排查思路

3 Java有没有主动触发GC的方式

Java的公有API可以主动调用GC的有两种办法：

// 只是告诉JVM尽快GC，并不一定立刻进行GC
System.gc();
// 或者下面，两者等价
Runtime.getRuntime().gc();

关于GC是如何发起（触发）的：看过无数Java GC文章，这5个问题你也未必知道！

上述文章还包含以下问题解答：

• Q1: GC工作是如何发起的？
• Q2: Stop The World到底如何让Java线程都停下来？
• Q3: 如何找到GC Roots？
• Q4: GC时如何处理四种特殊引用？
• Q5: 对象移动后，引用如何修正？

4 dump文件如何分析

==》 jvm系列：dump文件深度分析

5 jvm内存模型，int a=1 这个数据存在哪里

==》 java中，成员变量 int a = 1, a存在哪, 1存在哪 (存在JVM哪)?

java 栈内存问题，int a=1;int b=1;分配了几块内存？（评论中留下你的想法）

6 string str = new string(“abc”) 创建了几个对象？这些变量分别存储在哪里

string str = new string(“abc”) 创建了几个对象

7 一个父类加载器能不能加载一个子类加载器，为什么

深入理解Java类加载器(ClassLoader)

8 Tomcat容器是如何隔离多个应用的（通过使用不同的类加载器来加载来区分不同应用中的对象）

Tomcat是如何隔离Web应用的