JVM的内存布局？

image.png

虚拟机栈：虚拟机栈是线程私有的内存区域，每个方法执行的时候都会在栈创建一个栈帧，方法的调用过程就对应着栈的入栈和出栈的过程。每个栈帧的结构又包含局部变量表、操作数栈、动态连接、方法返回地址。
局部变量表用于存储方法参数和局部变量。
操作数栈用于一些字节码指令从局部变量表中传递至操作数栈，也用来准备方法调用的参数以及接收方法返回结果。
动态连接用于将符号引用表示的方法转换为实际方法的直接引用。
方法区：方法区与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在Java1.7之前，永久代包含方法区，常量池就存在于方法区（永久代）中，而方法区本身是一个逻辑上的概念，在1.7之后则是把常量池移到了堆内，为了更容易管理方法区，从 JDK 1.8 开始，移除永久代，并把方法区移至元空间，它位于直接内存中，而不是虚拟机内存中。方法区是一个 JVM 规范，永久代与元空间都是其一种实现方式。在 JDK 1.8 之后，原来永久代的数据被分到了堆和元空间中。元空间存储类的元信息，静态变量和常量池等放入堆中。
本地方法栈：类似于虚拟机栈，主要用于执行本地native方法的区域
程序计数器：也是线程私有的区域，用于记录当前线程下虚拟机正在执行的字节码的指令地址。

类加载过程？

image.png

一个对象的创建过程(new)？

image.png

双亲委派模型？

类加载器自顶向下分为：
Bootstrap ClassLoader启动类加载器：默认会去加载JAVA_HOME/lib目录下的jar
Extention ClassLoader扩展类加载器：默认去加载JAVA_HOME/lib/ext目录下的jar
Application ClassLoader应用程序类加载器：当前应用classpathClassPath下的类
User ClassLoader用户自定义类加载器：由用户自己定义
双亲委派模型：
1、先检查类是否已经被加载过
2、若没有加载则调用父加载器的loadClass()方法进行加载
3、若父加载器为空则默认使用启动类加载器作为父加载器。
4、如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

好处：双亲委派模型保证了Java程序的稳定运行，可以避免类的重复加载（JVM 区分不同类的方式不仅仅根据类名，相同的类文件被不同的类加载器加载产生的是两个不同的类）。如果没有使用双亲委派模型，而是每个类加载器加载自己的话就会出现一些问题，比如我们编写一个称为 java.lang.Object 类的话，那么程序运行的时候，系统就会出现多个不同的 Object 类。另外，通过双亲委派的方式，还保证了安全性。因为Bootstrap ClassLoader在加载的时候，只会加载JAVA_HOME/lib中的jar包里面的类，如java.lang.Integer，那么这个类是不会被随意替换的，除非有人跑到你的机器上， 破坏你的JDK。那么，就可以避免有人自定义一个有破坏功能的java.lang.Integer被加载。这样可以有效的防止核心Java API被篡改。
如何破坏双亲委派模型？
因为双亲委派过程都是在loadClass方法中实现的，那么想要破坏这种机制，那么就自定义一个类加载器，重写其中的loadClass方法，使其不进行双亲委派即可。如果你想定义一个自己的类加载器，并且要遵守双亲委派模型，那么可以继承ClassLoader，并且在findClass中实现你自己的加载逻辑即可。
破坏双亲委派机制的场景：
第一种被破坏的情况是在双亲委派出现之前。由于双亲委派模型是在JDK1.2之后才被引入的，而在这之前已经有用户自定义类加载器在用了。所以，这些是没有遵守双亲委派原则的。
第二种，是JNDI、JDBC等需要加载SPI接口实现类的情况：DriverManager.getConnection
若按照双亲委任模型的话， DriverManager被Bootstrap类加载器加载，其内部引用到的connection也理应由Bootstrap类加载器加载，但Driver.class的实现类不在Bootstrap类加载器所能扫描到的范围里，所以交由Bootstrap类加载器是加载不了的，而双亲委任模型规定是先交由父类去加载，加载不了再由自己加载，而Bootstrap类加载器是最顶层的类加载器了，没有父类了，所以交由自己加载，但是自己也加载不了，所以为了能够加载到Driver.class的实现类，只能打破双亲委任模型了【使用子类加载器去加载Driver.class的实现类】，通过Thread.currentThread().getContextClassLoader()的方式，得到ApplicationClassLoader，而ApplicationClassLoader就能够扫描到添加进来的jar包【依赖的jar包都是在ClassPath下】，所以Driver.class的实现类就能够被加载到。
第三种是为了实现热插拔热部署工具。为了让代码动态生效而无需重启，实现方式时把模块连同类加载器一起换掉就实现了代码的热替换。
第四种是tomcat等web容器的出现：
一个web容器可能需要部署多个应用程序。不同的应用程序可能会依赖同一个第三方类库的不同版本，但是不同版本的类库中某一个类的全路径名可能是一样的。如多个应用都要依赖xxx.jar，但是A应用需要依赖1.0.0版本，但是B应用需要依赖1.0.1版本。这两个版本中都有一个类是com.xxx.Test.class。如果采用默认的双亲委派类加载机制，那么是无法加载多个相同的类。所以，Tomcat破坏双亲委派原则，提供隔离的机制，为每个web容器单独提供一个WebAppClassLoader加载器。Tomcat的类加载机制：为了实现隔离性，优先加载 Web 应用自己定义的类，所以没有遵照双亲委派的约定，每一个应用自己的类加载器——WebAppClassLoader负责加载本身的目录下的class文件，加载不到时再交给CommonClassLoader加载，这和双亲委派刚好相反。
第五种是OSGI、Jigsaw等模块化技术的应用

如何判断对象是否死亡（可回收）？

• 引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1；当引用失效，计数器就减 1；任何时候计数器为 0 的对象就是不可能再被使用的。这个方法实现简单，效率高，但是它很难解决对象之间相互循环引用的问题。

• 可达性分析算法

Java通过可达性分析算法来达到标记存活对象的目的，定义一系列的GC ROOT为起点，从起点开始向下开始搜索，搜索走过的路径称为引用链，当一个对象到GC ROOT没有任何引用链相连的话，则对象可以判定是可以被回收的。
可作为 GC Roots 的对象包括下面几种:
虚拟机栈(栈帧中的本地变量表)中引用的对象
本地方法栈(Native 方法)中引用的对象
方法区中静态变量引用的对象
方法区中常量引用的对象
所有被同步锁持有的对象

• 回收对象的两次标记过程

一次标记：当可达性分析确认该对象没有引用链与GC Roots相连，则对其进行第一次标记和筛选，筛选的条件是重写了finalize()方法并没有执行过，对于重写了且并没有执行finalize()方法的对象这将其放置在一个F-Queue队列中，并在稍后由一个由虚拟机自动建立的低优先级的Finalizer线程去执行它。此处执行只保证执行该方法，但是不保证等待该方法执行结束，之所以这样子设计是为了系统的稳定性和健壮性考虑，以免该方法执行时间较长或者死循环导致系统崩溃。在此之后，系统会对对象进行第二次标记，如果在第一次标记之后的对象在执行finalize()方法时没有被引用到一个新的变量，这该对象将被回收掉。

垃圾回收算法？

• 标记-清除

先根据可达性算法统一标记出需要回收的对象，标记完成之后统一回收所有被标记的对象，而由于标记的过程需要遍历所有的GC ROOT，清除的过程也要遍历堆中所有的对象，所以标记-清除算法的效率低下，同时也带来了内存碎片的问题

• 复制算法

为了解决上面的问题，复制算法应运而生，它将内存分为大小相等的两块区域，每次使用其中的一块，当一块内存使用完之后，将还存活的对象拷贝到另外一块内存区域中，然后把当前内存清空，这样性能和内存碎片的问题得以解决。但是同时带来了另外一个问题，可使用的内存空间缩小了一半。

• 标记整理

前面两步和标记清除法一样，不同的是它在标记清除法的基础上添加了一个整理的过程 ，即将所有的存活对象都往一端移动,紧邻排列，再清理掉另一端的所有区域，这样的话就解决了内存碎片的问题。

• 分代收集算法

当前虚拟机的垃圾收集都采用分代收集算法，这种算法没有什么新的思想，只是根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样就可以根据各个年代的特点选择合适的垃圾收集算法。比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

垃圾收集器

image.png

• Serial 收集器
  单线程版本收集器，进行垃圾回收的时候会STW（Stop The World），也就是进行垃圾回收的时候其他的工作线程都必须暂停，采用复制算法。
• ParNew 收集器
  Serial的多线程版本，用于和CMS配合使用。
• Parallel Scavenge
  Parallel Scavenge 收集器也是一个使用复制算法，多线程，工作于新生代的垃圾收集器。Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值，也就是说 CMS 等垃圾收集器更适合用到与用户交互的程序，因为停顿时间越短，用户体验越好，而 Parallel Scavenge 收集器关注的是吞吐量，所以更适合做后台运算等不需要太多用户交互的任务。JDK1.8 默认使用的是 Parallel Scavenge + Parallel Old。

• Serial Old 收集器
  Serial 收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。它主要有两大用途：一种用途是在 JDK1.5 以及以前的版本中与 Parallel Scavenge 收集器搭配使用，另一种用途是作为 CMS 收集器的后备方案。
• Parallel Old收集器
  Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。
• CMS收集器
  CMS 收集器是以实现最短 STW 时间为目标的收集器，如果应用很重视服务的响应速度，希望给用户最好的体验，则 CMS 收集器是个很不错的选择！CMS 虽然工作于老年代，但采用的是标记清除法，主要有以下四个步骤：
  初始标记：标记GC ROOT能关联到的对象，需要STW
  并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，不需要STW
  重新标记：为了修正并发标记期间，因用户程序继续运作而导致标记产生改变的标记，需要STW
  并发清除：清理删除掉标记阶段判断的已经死亡的对象，不需要STW
  从整个过程来看，并发标记和并发清除的耗时最长，但是不需要停止用户线程，而初始标记和重新标记的耗时较短，但是需要停止用户线程，总体而言，整个过程造成的停顿时间较短，大部分时候是可以和用户线程一起工作的。三个缺点：
  对 CPU 资源敏感；
  无法处理浮动垃圾；
  它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。
• G1收集器
  G1作为JDK9之后的服务端默认收集器，且不再区分年轻代和老年代进行垃圾回收，他把内存划分为多个Region。对于大对象的存储则衍生出Humongous的概念，超过Region大小一半的对象会被认为是大对象，而超过整个Region大小的对象被认为是超级大对象，将会被存储在连续的N个Humongous Region中，G1在进行回收的时候会在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间优先回收收益最大的Region。
  G1的回收过程分为以下四个步骤：
  初始标记：标记GC ROOT能关联到的对象，需要STW
  并发标记：从GCRoots的直接关联对象开始遍历整个对象图的过程，扫描完成后还会重新处理并发标记过程中产生变动的对象
  最终标记：短暂暂停用户线程，再处理一次，需要STW
  筛选回收：更新Region的统计数据，对每个Region的回收价值和成本排序，根据用户设置的停顿时间制定回收计划。再把需要回收的Region中存活对象复制到空的Region，同时清理旧的Region。需要STW
  总的来说除了并发标记之外，其他几个过程也还是需要短暂的STW，G1的目标是在停顿和延迟可控的情况下尽可能提高吞吐量。
  G1 优点：
  停顿时间短；
  用户可以指定最大停顿时间；
  不会产生内存碎片：G1 的内存布局并不是固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域 (Region)，G1 从整体来看是基于“标记-整理”算法实现的收集器，但从局部 (两个Region 之间)上看又是基于“标记-复制”算法实现，不会像 CMS (“标记-清除”算法) 那样产生内存碎片。
  G1 缺点：
  G1 需要记忆集 (具体来说是卡表)来记录新生代和老年代之间的引用关系，这种数据结构在 G1 中需要占用大量的内存，可能达到整个堆内存容量的 20% 甚至更多。而且 G1 中维护记忆集的成本较高，带来了更高的执行负载，影响效率。

内存分配策略

1. 多数情况，对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时，虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存(这里是把已经在的对象转移到老年代，要分配的新对象还是在会存在Eden)。

• Minor GC 是指发生在新生代的 GC，因为 Java 对象大多都是朝生夕死，所有 Minor GC 非常频繁，一般回收速度也非常快；
• Major GC/Full GC 是指发生在老年代的 GC，出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。

2. 大对象直接进入老年代
   所谓大对象是指需要大量连续内存空间的对象(虚拟机提供参数-XX：PretenureSizeThreshold参数（这个参数只在serial和ParNew起作用），当对象比这个值大，就直接存入老年代)，频繁出现大对象是致命的，会导致在内存还有不少空间的情况下提前触发 GC 以获取足够的连续空间来安置新对象。新生代使用的是复制算法来处理垃圾回收的，如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分配。

3. 长期存活对象将进入老年代
   虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须判断哪些对象应该放在新生代，哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器，如果对象在 Eden 区出生，并且能够被 Survivor 容纳，将被移动到 Survivor 空间中，这时设置对象年龄为 1。对象在 Survivor 区中每「熬过」一次 Minor GC 年龄就加 1，当年龄达到一定程度（默认 15，可以通过参数 -XX:MaxTenuringThreshold 来设置） 就会被晋升到老年代。

4. 动态对象年龄判定
   虚拟机并不是永远要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄。

5. 空间分配担保
   在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 可以确认是安全的。如果不成立的话虚拟机会查看 HandlePromotionFailure 的值是否允许担保失败，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC；如果小于，或者 HandlePromotionFailure 的值不允许冒险，那么就要进行一次 Full GC。

Full GC 的触发条件

对于 Minor GC，其触发条件非常简单，当 Eden 空间满时，就将触发一次 Minor GC。而 Full GC 则相对复杂，有以下条件：

1. 调用 System.gc()
   只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。

2. 老年代空间不足
   老年代空间不足的常见场景为大对象直接进入老年代、长期存活的对象进入老年代等。为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。除此之外，可以通过 -Xmn 虚拟机参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。

3. 空间分配担保失败
   使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC。

4. JDK 1.7 及以前的永久代空间不足
   在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 Class 的信息、常量、静态变量等数据。当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么虚拟机会抛出 java.lang.OutOfMemoryError。为避免以上原因引起的 Full GC，可采用的方法为增大永久代空间或转为使用 CMS GC。

5. Concurrent Mode Failure
   执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足（可能是 GC 过程中浮动垃圾过多导致暂时性的空间不足），便会报 Concurrent Mode Failure 错误，并触发 Full GC。

JVM调优

JDK 监控和故障处理工具总结

[JDK 命令行工具]
这些命令在 JDK 安装目录下的 bin 目录下：

• jps (JVM Process Status）: 类似 UNIX 的 ps 命令。用户查看所有 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息；
• jstat（ JVM Statistics Monitoring Tool）: 用于收集 HotSpot 虚拟机各方面的运行数据;
• jinfo (Configuration Info for Java) : Configuration Info forJava,显示虚拟机配置信息;
• jmap (Memory Map for Java) :生成堆转储快照;
• jhat (JVM Heap Dump Browser ) : 用于分析 heapdump 文件，它会建立一个 HTTP/HTML 服务器，让用户可以在浏览器上查看分析结果;
• jstack (Stack Trace for Java):生成虚拟机当前时刻的线程快照，线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合。

JDK可视化分析工具
JConsole 是基于 JMX 的可视化监视、管理工具。可以很方便的监视本地及远程服务器的 java 进程的内存使用情况。可以在控制台输出入console命令启动或者在 JDK 目录下的 bin 目录找到jconsole.exe然后双击启动。JConsole 可以显示当前内存的详细信息。不仅包括堆内存/非堆内存的整体信息，还可以细化到 eden 区、survivor 区等的使用情况

VisualVM是到目前为止随 JDK 发布的功能最强大的运行监视和故障处理程序，官方在 VisualVM 的软件说明中写上了“All-in-One”的描述字样，预示着他除了运行监视、故障处理外，还提供了很多其他方面的功能，如性能分析（Profiling）。VisualVM 的性能分析功能甚至比起 JProfiler、YourKit 等专业且收费的 Profiling 工具都不会逊色多少，而且 VisualVM 还有一个很大的优点：不需要被监视的程序基于特殊 Agent 运行，因此他对应用程序的实际性能的影响很小，使得他可以直接应用在生产环境中。这个优点是 JProfiler、YourKit 等工具无法与之媲美的。

JVM参数

1. 标准参数（-），所有的 JVM 实现都必须实现这些参数的功能，而且向后兼容；例如 -verbose:gc（输出每次GC的相关情况)

2. 非标准参数（-X），默认 JVM 实现这些参数的功能，但是并不保证所有 JVM 实现都满足，且不保证向后兼容，栈，堆大小的设置都是通过这个参数来配置的,用得最多的如下
   参数示例 表示意义
   -Xms512m JVM 启动时设置的初始堆大小为 512M
   -Xmx512m JVM 可分配的最大堆大小为 512M
   -Xmn200m 设置的年轻代大小为 200M
   -Xss128k 设置每个线程的栈大小为 128k

3. 非Stable参数（-XX），此类参数各个 jvm 实现会有所不同，将来可能会随时取消，需要慎重使用, -XX:-option 代表关闭 option 参数，-XX:+option 代表要打开 option 参数,例如要启用串行 GC，对应的 JVM 参数即为 -XX:+UseSerialGC。非 Stable 参数主要有三大类行为参数（Behavioral Options）：用于改变 JVM 的一些基础行为，如启用串行/并行 GC
   参数示例 表示意义
   -XX:+DisableExplicitGC 禁止调用System.gc()；但jvm的gc仍然有效
   -XX:+UseConcMarkSweepGC 对老生代采用并发标记交换算法进行GC
   -XX:+UseParallelGC 启用并行GC
   -XX:+UseParallelOldGC 对Full GC启用并行，当-XX:-UseParallelGC启用时该项自动启用
   -XX:+UseSerialGC 启用串行GC
   性能调优（Performance Tuning）：用于 jvm 的性能调优，如设置新老生代内存容量比例
   参数示例 表示意义
   -XX:MaxHeapFreeRatio=70 GC后java堆中空闲量占的最大比例
   -XX:NewRatio=2 新生代内存容量与老生代内存容量的比例
   -XX:NewSize=2.125m 新生代对象生成时占用内存的默认值
   -XX:ReservedCodeCacheSize=32m 保留代码占用的内存容量
   -XX:ThreadStackSize=512 设置线程栈大小，若为0则使用系统默认值
   调试参数（Debugging Options）：一般用于打开跟踪、打印、输出等 JVM 参数，用于显示 JVM 更加详细的信息
   参数示例 表示意义
   -XX:HeapDumpPath=./java_pid.hprof 指定导出堆信息时的路径或文件名
   -XX:-HeapDumpOnOutOfMemoryError 当首次遭遇OOM时导出此时堆中相关信息
   -XX:-PrintGC 每次GC时打印相关信息
   -XX:-PrintGC Details 每次GC时打印详细信息

参数设置

1、首先 Oracle 官方推荐堆的初始化大小与堆可设置的最大值一般是相等的，即 Xms = Xmx，因为起始堆内存太小（Xms），会导致启动初期频繁 GC，起始堆内存较大（Xmx）有助于减少 GC 次数

2、调试的时候设置一些打印参数，如-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log，这样可以从gc.log里看出一些端倪出来

3、系统停顿时间过长可能是 GC 的问题也可能是程序的问题，多用 jmap 和 jstack 查看，或者killall -3 Java，然后查看 Java 控制台日志，能看出很多问题

4、 采用并发回收时，年轻代小一点，老年代要大，因为老年代用的是并发回收，即使时间长点也不会影响其他程序继续运行，网站不会停顿

5、仔细了解自己的应用，如果用了缓存，那么年老代应该大一些，缓存的HashMap不应该无限制长，建议采用LRU算法的Map做缓存，LRUMap的最大长度也要根据实际情况设定