JVM学习(二)_第一次从eden区到from对象会加1吗-CSDN博客

本文链接：https://blog.csdn.net/qq_39995183/article/details/105401563

JVM内存模型

JVM

JVM内存区域分为非堆区和堆区，堆区分为两大块，一个是一个是Old区，一个是Young区。

Young区分为两大块，一个是Survivor区（S0+S1），一块是Eden区。 Eden:S0:S1=8:1:1

S0和S1一样大，也可以叫From和To。

对象创建所在区域

一般情况下，新创建的对象都会被分配到Eden区，一些特殊的大的对象会直接分配到Old区。

比如有对象A，B，C等创建在Eden区，但是Eden区的内存空间肯定有限，比如有100M，假如已经使用了100M或者达到一个设定的临界值，这时候就需要对Eden内存空间进行清理，即垃圾收集(Garbage Collect)，这样的GC我们称之为Minor GC，Minor GC指得是Young区的GC。

经过GC之后，有些对象就会被清理掉，有些对象可能还存活着，对于存活着的对象需要将其复制到Survivor区，然后再清空Eden区中的这些对象。

Survivor区

Survivor区分为两块S0和S1，也可以叫做Survivor From和Survivor To。

在同一个时间点上，S0和S1只能有一个区有数据，另外一个是空的。

如果一开始只有Eden区和From中有对象，To中是空的。此时进行一次GC操作，From区中对象的年龄就会+1， Eden区中所有存活的对象会被复制到To区，From区中还能存活的对象会有两个去处。

若对象年龄达到之前设置好的年龄阈值，此时对象会被移动到Old区
如果Eden区和From区没有达到阈值的对象会被复制到To区

此时Eden区和From区已经被清空。这时候From和To交换角色，之前的From变成了To，之前的To变成了From。也就是说无论如何都要保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到To区被填满，然后会将所有对象复制到老年代中。

Old区

一般Old区都是年龄比较大的对象，或者相对超过了某个阈值的对象。

在Old区也会有GC的操作，Old区的GC我们称作为Major GC。

总结

JVM_MEMORY

如何理解Minor/Major/Full GC

Minor GC:新生代
Major GC:老年代
Full GC:新生代+老年代

为什么需要Survivor区?只有Eden不行吗？

如果没有Survivor,Eden区每进行一次Minor GC,并且没有年龄限制的话，存活的对象就会被送到老年代。这样一来，老年代很快被填满,触发Major GC(因为Major GC一般伴随着Minor GC,也可以看做触发了Full GC)。老年代的内存空间远大于新生代,进行一次Full GC消耗的时间比Minor GC长得多。

假如增加老年代空间，更多存活对象才能填满老年代。虽然降低Full GC频率，但是随着老年代空间加大,一旦发生Full GC,执行所需要的时间更长。

假如减少老年代空间，虽然Full GC所需时间减少，但是老年代很快被存活对象填满,Full GC频率增加。

所以Survivor的存在意义,就是减少被送到老年代的对象,进而减少Full GC的发生,Survivor的预筛选保证,只有经历16 次Minor GC还能在新生代中存活的对象,才会被送到老年代。

为什么需要两个Survivor区？

最大的好处就是解决了碎片化，永远有一个Survivor space是空的,另一个非空的Survivor space无碎片。

新生代中Eden:S1:S2为什么是8:1:1？

新生代中的可用内存：复制算法用来担保的内存为9：1

可用内存中Eden：S1区为8：1

即新生代中Eden:S1:S2 = 8：1：1

使用Java VisualVM查看

安装Visual GC插件可查看内存区域

堆内存溢出

GIF 2020-4-8 13-56-33

方法区内存溢出

java.lang.OutOfMemoryError: Metaspace
	at java.lang.ClassLoader.defineClass1(Native Method) ~[na:1.8.0_211]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[na:1.8.0_211]
	at java.lang.ClassLoader.defineClass(ClassLoader.java:642) ~[na:1.8.0_211]

虚拟机栈

public class StackOverFlowDemo {

    public static long count=0;

    public static void method(long i){
        System.out.println(count++);
        method(i);
    }

    public static void main(String[] args) {
        method(1);
    }
}

设置JVM参数-Xss128k运行结果：

Exception in thread "main" java.lang.StackOverflowError
	at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77)
	at sun.nio.cs.UTF_8.access$200(UTF_8.java:57)
	at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:636)
	at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:691)
	......

Stack Space用来做方法的递归调用时压入Stack Frame(栈帧)。所以当递归调用太深的时候，就有可能耗尽Stack Space，爆出StackOverflow的错误。

-Xss128k：设置每个线程的堆栈大小。JDK 5以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。

线程栈的大小如果设置过小，可能会出现栈溢出，特别是在该线程内有递归、大的循环时出现溢出的可能性更大，如果该值设置过大，就有影响到创建栈的数量，如果是多线程的应用，就会出现内存溢出的错误。

Garbage Collect(垃圾回收)

如何确定一个对象是垃圾？

要想进行垃圾回收，得先知道什么样的对象是垃圾。

引用计数法

对于某个对象而言，只要应用程序中持有该对象的引用，就说明该对象不是垃圾，如果一个对象没有任
何指针对其引用，它就是垃圾。

弊端 : 如果AB相互持有引用，导致永远不能被回收。

可达性分析

通过GC Root的对象，开始向下寻找，看某个对象是否可达

能作为GC Root:类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法
栈的变量等。

垃圾收集算法

标记-清除(Mark-Sweep)

标记：找出内存中需要回收的对象，并且把它们标记出来

此时堆中所有的对象都会被扫描一遍，从而才能确定需要回收的对象，比较耗时
清除：清除掉被标记需要回收的对象，释放出对应的内存空间

缺点：

标记和清除两个过程都比较耗时，效率不高
会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无
法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

复制(Copying)

将内存划分为两块相等的区域，每次只使用其中一块，当其中一块内存使用完了，就将还存活的对象复制到另外一块上面，然后把已经使用过的内存空间一次清除掉。

缺点: 空间利用率降低。

标记-整理(Mark-Compact)

标记过程仍然与"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

分代收集算法

Young区：复制算法(对象在被分配之后，可能生命周期比较短，Young区复制效率比较高)
Old区：标记清除或标记整理(Old区对象存活时间比较长，复制来复制去没必要，不如做个标记再清理)

垃圾收集器

收集器	串行、并行or并发	新生代/老年代	算法	目标	适用场景
Serial	串行	新生代	复制算法	响应速度优先	单CPU环境下的Client模式
Serial Old	串行	老年代	标记-整理	响应速度优先	单CPU环境下的Client模式、CMS的后备预案
ParNew	并行	新生代	复制算法	响应速度优先	多CPU环境时在Server模式下与CMS配合
Parallel Scavenge	并行	新生代	复制算法	吞吐量优先	在后台运算而不需要太多交互的任务
Parallel Old	并行	老年代	标记-整理	吞吐量优先	在后台运算而不需要太多交互的任务
CMS	并发	老年代	标记-清除	响应速度优先	集中在互联网站或B/S系统服务端上的Java应用
G1	并发	both	标记-整理+复制算法	响应速度优先	面向服务端应用，替换CMS

Serial收集器

Serial收集器是最基本、发展历史最悠久的收集器，曾经（在JDK1.3.1之前）是虚拟机新生代收集的唯
一选择。
它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更
重要的是其在进行垃圾收集的时候需要暂停其他线程。

优点：简单高效，拥有很高的单线程收集效率
缺点：收集过程需要暂停所有线程
算法：复制算法
适用范围：新生代
应用：Client模式下的默认新生代收集器

ParNew收集器

可以把这个收集器理解为Serial收集器的多线程版本。

优点：在多CPU时，比Serial效率高。
缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差。
算法：复制算法
适用范围：新生代
应用：运行在Server模式下的虚拟机中首选的新生代收集器

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集
器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量。

吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。
若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序
的运算任务。

Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算
法"，运行过程和Serial收集器一样。

Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾
回收。

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。

采用的是"标记-清除算法",整个过程分为4步

初始标记 CMS initial mark (标记GC Roots能关联到的对象 Stop The World—>速度很快）
并发标记 CMS concurrent mark （进行GC Roots Tracing）
重新标记 CMS remark （修改并发标记因用户程序变动的内容 Stop The World）
并发清除 CMS concurrent sweep

由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

优点：并发收集、低停顿
缺点：产生大量空间碎片、并发阶段会降低吞吐量

G1收集器

G1特点

并行与并发
分代收集（仍然保留了分代的概念）
空间整合（整体上属于“标记-整理”算法，不会导致空间碎片）
可预测的停顿（比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒）

使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

工作过程可以分为如下几步：

初始标记（Initial Marking）标记一下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程
并发标记（Concurrent Marking）从GC Roots进行可达性分析，找出存活的对象，与用户线程并发执行
最终标记（Final Marking）修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程
筛选回收（Live Data Counting and Evacuation）对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划

判断是否需要使用G1收集器？

50%以上的堆被存活对象占用
对象分配和晋升的速度变化非常大
垃圾回收时间比较长

垃圾收集器分类

串行收集器->Serial和Serial Old

只能有一个垃圾回收线程执行，用户线程暂停。适用于内存比较小的嵌入式设备。
并行收集器[吞吐量优先]->Parallel Scanvenge、Parallel Old

多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。适用于科学计算、后台处理等若交互场景。
并发收集器[停顿时间优先]->CMS、G1

用户线程和垃圾收集线程同时执行(但并不一定是并行的，可能是交替执行的)，垃圾收集线程在执行的时候不会停顿用户线程的运行。适用于相对时间有要求的场景，比如Web 。