jvm内存模型

JVM内存结构分为：方法区，栈内存(stack)，堆内存(heap)，本地方法栈，程序计数器
程序计数器：由于在JVM中，多线程是通过线程轮流切换来获得CPU执行时间的，因此，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令，因此，为了能够使得每个线程都在线程切换后能够恢复在切换之前的程序执行位置，每个线程都需要有自己独立的程序计数器，并且不能互相被干扰。可以说程序计数器是每个线程所私有的。
栈内存：Java栈中存放的是一个个的栈帧，每个栈帧对应一个被调用的方法，在栈帧中包括局部变量表、操作数栈、指向当前方法所属的类的运行时常量池的引用、方法返回地址和一些额外的附加信息。当线程执行一个方法时，就会随之创建一个对应的栈帧，并将建立的栈帧压栈。当方法执行完毕之后，便会将栈帧出栈。
本地方法栈：本地方法栈与Java栈的作用和原理非常相似。区别只不过是Java栈是为执行Java方法服务的，而本地方法栈则是为执行本地方法(Native Method：指java调用非java的方法，该方法的实现由非java语言实现，比如C)服务的。
堆内存：Java中的堆是用来存储对象本身的以及数组(数组引用是存放在Java栈中的)。堆是被所有线程共享的，在JVM中只有一个堆。
方法区：与堆一样，是被线程共享的区域。在方法区中，存储了每个类的信息（包括类的名称、方法信息、字段信息）、静态变量、final类型的常量以及编译器编译后的代码等。方法区也被叫为持久代 PermGen(因为是用到了堆内存)，不过在jdk1.8之后，持久代不存在了，被元空间Metaspace取代了，元空间占用的是本机内存，不再是占用虚拟机内存，可以通过-XX:MetaspaceSize=N设置大小。

从上可以看出，程序计数器、虚拟机栈、本地方法栈3个区域随线程而生、随线程而灭，因此这几个区域的内存分配和回收都具备确定性，就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆区和方法区这两部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分。

垃圾收集器在对堆区和方法区进行回收前，首先要确定这些区域的对象哪些可以被回收，哪些暂时还不能回收，这就要用到判断对象是否存活的算法，常见的有引用计数算法、标记-清除算法、复制算法和标记-整理算法。

• 引用计数算法：给对象添加一个引用计数器，每当有一个地方引用该对象时，计数器加1，当引用失效时，计数器减1，当计数器值为0时表示该对象不再被使用。需要注意的是：引用计数法很难解决对象之间相互循环引用的问题，主流Java虚拟机没有选用引用计数法来管理内存。
• 标记-清除算法：标记-清除算法采用从一些根集合（GC Roots）进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收。这种算法有一个比较严重的问题就是容易产生内存碎片，碎片太多可能会导致后续过程中需要为大对象分配空间时无法找到足够的空间而提前触发新的一次垃圾收集动作。
• 复制算法：此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。此算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。
• 标记-整理算法：该算法标记阶段和Mark-Sweep一样，但是在完成标记之后，它不是直接清理可回收对象，而是将存活对象都向一端移动，然后清理掉端边界以外的内存。这种算法因为要移动对象，所以成本也很高。

接下来引入我们的重点，分代收集算法：
分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。
年轻代（Young Generation）的回收算法 (回收主要以复制算法为主)：
1.所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
2.新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空(美团面试，问的太细，为啥保持survivor1为空，答案：为了让eden和survivor0 交换存活对象)， 如此往复。当Eden没有足够空间的时候就会 触发jvm发起一次Minor GC。
3.当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收。
4.新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。
年老代（Old Generation）的回收算法（Full GC回收主要以标记-整理算法为主）：
1.在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
2.内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

新生代和老年代的区别(阿里面试题目)：
所谓的新生代和老年代是针对于分代收集算法来定义的，新生代又分为Eden和Survivor两个区。加上老年代就这三个区。数据会首先分配到Eden区 当中(当然也有特殊情况，如果是大对象那么会直接放入到老年代(大对象是指需要大量连续内存空间的java对象))，当Eden没有足够空间的时候就会 触发jvm发起一次Minor GC。如果对象经过一次Minor GC还存活，并且又能被Survivor空间接受，那么将被移动到Survivor空间当中。并将其年龄设为1，对象在Survivor每熬过一次Minor GC，年龄就加1，当年龄达到一定的程度（默认为15）时，就会被晋升到老年代 中了，当然晋升老年代的年龄是可以设置的。如果老年代满了就执行：Full GC 因为不经常执行，因此采用了标记整理算法清理。

常见的垃圾收集器：

• Serial收集器(复制算法)(串行)
  新生代单线程收集器，标记和清理都是单线程，优点是简单高效。是client级别默认的GC方式，可以通过-XX:+UseSerialGC来强制指定。缺点是进行垃圾回收时，必须暂停其他所有的工作线程。
• Serial Old收集器(标记-整理算法)(串行)
  老年代单线程收集器，Serial收集器的老年代版本。
• ParNew收集器(停止-复制算法)(并行)
  新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。但是也同样会暂停工作线程，ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，因为它是除了Serial收集器外，唯一一个能与CMS收集器配合工作的。
• Parallel Scavenge收集器(停止-复制算法)(并行)
  属于新生代收集器也是采用复制算法的收集器，又是并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量=用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。是server级别默认采用的GC方式，可用-XX:+UseParallelGC来强制指定，用-XX:ParallelGCThreads=4来指定线程数。
• Parallel Old收集器(停止-复制算法)(并行)
  Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先。
• CMS(Concurrent Mark Sweep)收集器(标记-清除算法)(并发)
  一种以获取最短回收停顿时间为目标的收集器。特点是基于标记-清除算法实现，并发收集、低停顿。缺点是会存在空间碎片的问题，导致大对象无法分配空间，不得不提前触发一次Full GC。具体来说，CMS 垃圾回收器的回收过程包含几个阶段：
  1.初始标记阶段：此阶段会短暂地暂停应用程序线程，进行 GC Roots 的直接扫描，标记出 GC Roots 可达的对象。
  2.并发标记阶段：在此阶段，应用程序线程和垃圾回收线程并发执行，对标记出来的对象进行全局标记，找出所有存活对象。这个阶段的标记过程和应用程序的执行是同时进行的，所以对应用程序的停顿时间影响较小。
  3.重新标记阶段：在并发标记阶段结束后，需要对在并发标记期间发生变化的对象进行重新标记。这个阶段会稍微暂停应用程序线程，但通常比初始标记阶段的停顿时间要短。
  4.并发清除阶段：在重新标记阶段完成后，CMS 垃圾回收器会与应用程序线程并发地进行清理，回收不再使用的对象。
  虽然 CMS 垃圾回收器尽可能地减少了停顿时间，但在并发标记和重新标记阶段，仍然会产生一定的停顿。
• G1收集器(分代收集算法)(并发)
  jdk1.7开始引入的一款面向服务端应用的垃圾收集器，目的是为了取代CMS收集器，特点如下：
  1.并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿时间。
  2.分代收集：G1能够独自管理整个Java堆，并且采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
  3.空间整合：G1运作期间不会产生空间碎片，收集后能提供规整的可用内存，这相比CMS收集器有明显的优势，
  4.可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型。能让使用者明确指定在一个长度为M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1为什么能建立可预测的停顿时间模型？
因为它有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这样就保证了在有限的时间内可以获取尽可能高的收集效率。

G1与其他收集器的区别？
其他收集器的工作范围是整个新生代或者老年代、G1收集器的工作范围是整个Java堆。在使用G1收集器时，它将整个Java堆划分为多个大小相等的独立区域（Region）。虽然也保留了新生代、老年代的概念，但新生代和老年代不再是相互隔离的，他们都是一部分Region（不需要连续）的集合。

G1收集器存在的问题？
Region不可能是孤立的，分配在Region中的对象可以与Java堆中的任意对象发生引用关系。在采用可达性分析算法来判断对象是否存活时，得扫描整个Java堆才能保证准确性。其他收集器也存在这种问题（G1更加突出而已）。会导致Minor GC效率下降。

G1收集器是如何解决上述问题的？
采用Remembered Set来避免整堆扫描。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用对象是否处于多个Region中（即检查老年代中是否引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆进行扫描也不会有遗漏。

GC的触发时机
由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Minor GC和Full GC。

• Minor GC
  一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Minor GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。
• Full GC
  对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比Minor GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：
  a) 年老代（Tenured）被写满；
  b) 持久代（Perm）被写满；
  c) System.gc()被显示调用；
  d) 上一次GC之后Heap的各域分配策略动态变化；

类加载机制
JVM的类加载是通过ClassLoader及其子类来完成的，类的层次关系和加载顺序可以由下图来描述：

图1.png

1.Bootstrap ClassLoader
负责加载JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类
2.Extension ClassLoader
负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目录下的jar包
3.App ClassLoader
负责记载classpath中指定的jar包及目录中class
4.Custom ClassLoader
属于应用程序根据自身需要自定义的ClassLoader，如tomcat、jboss都会根据j2ee规范自行实现ClassLoader

加载过程中会先检查类是否被已加载，检查顺序是自底向上，从Custom ClassLoader到BootStrap ClassLoader逐层检查，只要某个classloader已加载就视为已加载此类，保证此类只所有ClassLoader加载一次。而加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。这样的加载机制也被称为双亲委派机制，这种机制的好处是假如有人想替换系统级别的类，Bootstrap ClassLoader已经加载过了，即使再进行修改，也不会再被加载了，可以防止危险代码的植入。

引用：
https://blog.csdn.net/qq_36704549/article/details/109390566
https://www.cnblogs.com/aspirant/p/8662690.html
https://www.cnblogs.com/chenpt/p/9803298.html
https://www.cnblogs.com/lishun1005/p/6019678.html