狂神说java_JVM快速入门

JVM探究
面试常见：

  • ●请你谈谈你对JVM的理解? java8虚拟机和之前的变化更新?
  • ●什么是OOM，什么是栈溢出StackOverFlowError? 怎么分析?
  • ●JVM的常用调优参数有哪些?
  • ●内存快照如何抓取，怎么分析Dump文件？
  • ●谈谈JVM中，类加载器你的认识


1.JVM的位置


图 JVM图解
2.JVM的体系结构

 

 

 图 .java->.class的变化

百分之99的JVM调优都是在堆中调优，Java栈、本地方法栈、程序计数器是不会有垃圾存在的。

 

 

 

 解释器：把源代码翻译成相对更加高效率的中间码，然后立即执行它。

 

 

3. 类加载器
作用：加载Class文件~

 

 

 

 

2：类加载器的作用

编译器：把.java文件编译为.class字节码文件，并做格式检查

字节码校验器: 

1.字节码验证：

检查class文件的把呢不能和jvm版本是否兼容

检查代码是否会破坏系统完整性

检查代码是否有栈溢出的情况

检查当前代码参数类型是否正确

 

 

 


图 类在经过Class Loader之后的变化
 1.虚拟机自带的加载器
 2.启动类(根)加载器
 3.扩展类加载器
 4.应用程序加载器
 5.百度:双亲委派机制

4. 双亲委派机制
 //双亲委派机制:安全
 // 1. APP–>EXC—B0OT(最终执行)
 // B0OT
 // EXC
 // APP
 1.类加载器收到类加载的请求
 2.将这个请求向上委托给父类加载器去完成，一 直向上委托，知道启动类加载器
 3.启动加载器检查是否能够加载当前这个类，能加载就结束， 使用当前的加载器，否则， 抛出异常，通知子加载器进行加载
 4.重复步骤3
 Class Not Found异常就是这么来的
 Java早期的名字：C+±-
 Java = C++:去掉繁琐的东西，指针，内存管理~

类加载器

  • JVM自带的加载器(3种)

    • 启动类加载器:Bootstrap ClassLoader,又名根类加载器或引导类加载器
    • 拓展类加载器:Extension ClassLoader
    • 系统类加载器:Application ClassLoader,又名应用类加载器

  • 用户自定义的类加载器,一般是java.lang.ClassLoader

    Java早期Java Applet需要从远程下载Java类文件到浏览器中并执行.

    在java.net包中，JDK提供了一个更加易于使用的类加载器URLClassLoader，来扩展ClassLoader，能够从本地或网络上指定的位置加载类。我们可以使用该类作为自定义的类加载器使用

    热部署类加载器

    • 相同的类被同一个类加载器多次加载，则会报错。因此热部署是让同一个类文件被不同的类加载器加载重复加载即可。
    • 我们不能调用loadClass方法，而应该调用findClass方法，避免双亲委派机制，从而实现同一个类被加载多次，实现热部署

类加载器的种类：

1-启动类加载器，负责加载%JAVA_HOME%\bin目录下的所有jar包，或者是-Xbootclasspath参数指定的路径jdk中的rt.jar；

2-扩展类加载器：负责加载%JAVA_HOME%\bin\ext目录下的所有jar包，或者是java.ext.dirs参数指定的路径；

3-应用程序类加载器：负责加载用户类路径上所指定的类库，如果应用程序中没有自定义加载器，那么次加载器就为默认加载器。

双亲委派机制

委派机制图:

img

双亲委派机制的工作过程:

  1. 类加载器收到类加载的请求;
  2. 把这个请求委托给父加载器去完成,一直向上委托,直到启动类加载器;
  3. 启动类加载器检查能不能加载(使用findClass()方法),能加载就结束;否则抛出异常,通知子加载器进行加载;
  4. 重复步骤三.

接下来举个例子：

大家所熟知的Object类，直接告诉大家，Object默认情况下是启动类加载器进行加载的。假设我也自定义一个Object，并且制定加载器为自定义加载器。现在你会发现自定义的Object可以正常编译，但是永远无法被加载运行。

这是因为申请自定义Object加载时，总是启动类加载器，而不是自定义加载器，也不会是其他的加载器。


 

 

 

 

 

5. 沙箱安全机制
  Java安全模型的核心就是Java沙箱(sandbox) ,
  什么是沙箱?沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机(JVM)特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。
 沙箱主要限制系统资源访问，那系统资源包括什么? CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
 所有的Java程序运行都可以指定沙箱，可以定制安全策略。
 在Java中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码,可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱Sandbox)机制。如下图所示JDK1.0安全模型。

 

 

 


图 JDK1.0安全模型
 但如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。因此在后续的Java1.1版本中，针对安全机制做了改进，增加了安全策略，允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型

 

 

 


图 JDK1.1安全模型
 在Java1.2版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如下图所示

 

 

 


图 JDK1.2安全模型
 当前最新的安全机制实现，则引入了域(Domain)的概念。虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域(Protected Domain),对应不一样的权限(Permission)。存在于不同域中的类文件就具有了当前域的全部权限，如下图所示最新的安全模型(jdk 1.6)

 

 

   图 JDK1.6安全模型

 

组成沙箱的基本组件
●字节码校验器(bytecode verifier) :确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验，比如核心类。
●类裝载器(class loader) :其中类装载器在3个方面对Java沙箱起作用

  •   它防止恶意代码去干涉善意的代码;
  •   它守护了被信任的类库边界;
  •   它将代码归入保护域,确定了代码可以进行哪些操作。

 虚拟机为不同的类加载器载入的类提供不同的命名空间，命名空间由一系列唯一的名称组成， 每一个被装载的类将有一个名字，这个命名空间是由Java虚拟机为每一个类装载器维护的，它们互相之间甚至不可见。
 类装载器采用的机制是双亲委派模式。
 1.从最内层JVM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用;
 2.由于严格通过包来区分了访问域,外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。

  • ●存取控制器(access controller) :存取控制器可以控制核心API对操作系统的存取权限，而这个控制的策略设定,可以由用户指定。
  • ●安全管理器(security manager) : 是核心API和操作系统之间的主要接口。实现权限控制，比存取控制器优先级高。
  • ●安全软件包(security package) : java.security下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，包括:

  安全提供者
  消息摘要
  数字签名
  加密
　 鉴别

6.Native

  •  native :凡是带了native关键字的，说明java的作用范围达不到了，回去调用底层c语言的库!
  •  会进入本地方法栈
  •  调用本地方法本地接口 JNI (Java Native Interface)
  •  JNI作用:开拓Java的使用，融合不同的编程语言为Java所用!最初: C、C++
  •  Java诞生的时候C、C++横行，想要立足，必须要有调用C、C++的程序
  •  它在内存区域中专门开辟了一块标记区域: Native Method Stack，登记native方法
  •  在最终执行的时候，加载本地方法库中的方法通过JNI
  •  例如：Java程序驱动打印机，管理系统，掌握即可，在企业级应用比较少
  •  private native void start0();
  •  //调用其他接口:Socket. . WebService~. .http~

Native Method Stack
 它的具体做法是Native Method Stack中登记native方法，在( Execution Engine )执行引擎执行的时候加载Native Libraies。[本地库]

Native Interface本地接口
 本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序, Java在诞生的时候是C/C++横行的时候，想要立足，必须有调用C、C++的程序，于是就在内存中专门开辟了块区域处理标记为native的代码，它的具体做法是在Native Method Stack 中登记native方法,在( Execution Engine )执行引擎执行的时候加载Native Libraies。
 目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间通信很发达，比如可以使用Socket通信,也可以使用Web Service等等，不多做介绍!

7.PC寄存器
 程序计数器: Program Counter Register
 每个线程都有一个程序计数器，是线程私有的，就是一个指针, 指向方法区中的方法字节码(用来存储指向像一条指令的地址， 也即将要执行的指令代码)，在执行引擎读取下一条指令, 是一个非常小的内存空间，几乎可以忽略不计

8.方法区 Method Area
 方法区是被所有线程共享,所有字段和方法字节码，以及一些特殊方法，如构造函数,接口代码也在此定义,简单说，所有定义的方法的信息都保存在该区域,此区域属于共享区间;
 静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关

 

 

 


图 类实例化后
9.栈

 

 


图 为什么main()先执行，最后结束~
栈:先进后出
桶:后进先出
队列:先进先出( FIFO : First Input First Output )
栈:栈内存,主管程序的运行,生命周期和线程同步;
线程结束，栈内存也就是释放,对于栈来说,不存在垃圾回收问题
一旦线程结束，栈就Over!
栈内存中:

9大基本类型+对象引用+实例的方法

栈运行原理:栈帧
栈满了: StackOverflowError

 

 

 

 

图 栈的位置示意图


图 栈帧图解 栈底部子帧指向上一个栈的方法 上一个栈的父帧指向栈底部方法
10.三种JVM
●Sun公司HotSpot Java Hotspot™ 64-Bit Server VM (build 25.181-b13,mixed mode)
●BEA JRockit
●IBM J9VM
我们学习都是: Hotspot

11.堆
Heap, 一个JVM只有一个堆内存，堆内存的大小是可以调节的。
类加载器读取了类文件后，一般会把什么东西放到堆中?
类, 方法，常量,变量~，保存我们所有引用类型的真实对象;
堆内存中还要细分为三个区域:
●新生区(伊甸园区) Young/New
●养老区old
●永久区Perm

 

图 堆内存详细划分
GC垃圾回收,主要是在伊甸园区和养老区~
假设内存满了,OOM,堆内存不够! java.lang.OutOfMemoryError:Java heap space
永久存储区里存放的都是Java自带的 例如lang包中的类 如果不存在这些，Java就跑不起来了
在JDK8以后，永久存储区改了个名字(元空间)

 

 

图 堆内存溢出
12.新生区、老年区
新生区
●类:诞生和成长的地方，甚至死亡;
●伊甸园，所有的对象都是在伊甸园区new出来的!
●幸存者区(0,1)

 

 

 


图 重GC和轻GC
伊甸园满了就触发轻GC，经过轻GC存活下来的就到了幸存者区，幸存者区满之后意味着新生区也满了，则触发重GC，经过重GC之后存活下来的就到了养老区。
真理:经过研究，99%的对象都是临时对象!|

13.永久区
这个区域常驻内存的。用来存放JDK自身携带的Class对象。Interface元数据，存储的是Java运行时的一些环境~ 这个区域不存在垃圾回收，关闭虚拟机就会释放内存
●jdk1.6之前:永久代,常量池是在方法区;
●jdk1.7:永久代,但是慢慢的退化了，去永久代，常量池在堆中
●jdk1.8之后:无永久代,常量池在堆里面

 

 

 

 

图 JVM探究
元空间：逻辑上存在，物理上不存在 (因为存储在本地磁盘内) 所以最后并不算在JVM虚拟机内存中

 

 

 注意字符串常量池是在堆里面的，而不是元空间，我们所说的常量池是运行时常量池放在元空间里面，字符串常量池和类常量池是在编译期间诞生的

 

 

运行时常量池和字符串常量池的关系

 

 

 

 

 

 常量池具体包含的内容有

 

 

 

 方法区先是位于永久区和元空间，并不位于堆上，只是逻辑上在堆里面，但是被称为非堆。

元空间是方法区的一种实现，方法区是虚拟机规范规定的。

jdk7之前方法区由永久代实现，永久代和堆隔离。

jdk7时方法区由永久代实现，但静态变量和字符串常量池已经移到堆里面

jdk8之后由元空间实现方法区，元空间移到本地内存中，永久代其他内容被转移到元空间里面。

所以字符串常量池和静态变量在堆里面，运行时常量池在元空间里面。元空间不再占用老年代空间，避免了老年代经常gc,同时本地内存为元空间提供了充足的空间。

 

 

 

 

 

 

 

 

 

 

 

轻gc和重gc分别在什么时候发生_什么是 Minor GC/Major GC

什么是 Minor GC/Major GC

 

 

 

 

 

 

 

 

 


首先我们先科普一下JVM 经典的堆布局:

对于经典的 JVM heap 布局，有两个区域比较清晰，首先是Young 区,一般会来存放年轻的对象或者刚被创建没多久的对象。其次是 Old 区，也就是老年代，一般会来存放比较长寿的对象，或者从 young 区晋升的对象。

对于young 区 我们又有三个区域，一个是 Eden 区，还有两个大小相等的 Survivor 区。

新生的对象会在 Eden 区创建。

Minor GC
此时如果新生的对象无法在 Eden 区创建（Eden 区无法容纳) 就会触发一次Young GC 此时会将 S0 区与Eden 区的对象一起进行可达性分析，找出活跃的对象，将它复制到 S1 区并且将S0区域和 Eden 区的对象给清空，这样那些不可达的对象进行清除，并且将S0 区 和 S1区交换。

但是这里会产生一个问题，Q:为啥会有两个 Survivor 区？

A: 因为假设设想一下只有一个 Survibor 区 那么就无法实现对于 S0 区的垃圾收集，以及分代年龄的提升。

Major GC
发生在老年代的GC ，基本上发生了一次Major GC 就会发生一次 Minor GC。并且Major GC 的速度往往会比 Minor GC 慢 10 倍。

什么时候发生Major GC
既然我们已经知道了 Minor GC 是在 Eden 区快满的情况下才会触发

Q:那么 Major GC 呢?
A:

对于一个大对象，我们会首先在Eden 尝试创建，如果创建不了，就会触发Minor GC
随后继续尝试在Eden区存放，发现仍然放不下
尝试直接进入老年代，老年代也放不下
触发 Major GC 清理老年代的空间
放的下 成功
放不下 OOM
详见下图:

 

 


避免频繁的Full GC
避免定义过大的对象(数组)
避免将过大对象定义为静态变量

1 为什么要有Survivor区

先不去想为什么有两个Survivor区，第一个问题是，设置Survivor区的意义在哪里？

 

 

如果没有Survivor，Eden区每进行一次Minor GC，存活的对象就会被送到老年代。老年代很快被填满，触发Major GC（因为Major GC一般伴随着Minor GC，也可以看做触发了Full GC）。老年代的内存空间远大于新生代，进行一次Full GC消耗的时间比Minor GC长得多。你也许会问，执行时间长有什么坏处？频发的Full GC消耗的时间是非常可观的，这一点会影响大型程序的执行和响应速度，更不要说某些连接会因为超时发生连接错误了。

好，那我们来想想在没有Survivor的情况下，有没有什么解决办法，可以避免上述情况：

方案优点缺点
增加老年代空间 更多存活对象才能填满老年代。降低Full GC频率 随着老年代空间加大，一旦发生Full GC，执行所需要的时间更长
减少老年代空间 Full GC所需时间减少 老年代很快被存活对象填满，Full GC频率增加

显而易见，没有Survivor的话，上述两种解决方案都不能从根本上解决问题。

我们可以得到第一条结论：Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保证，只有经历16次Minor GC还能在新生代中存活的对象，才会被送到老年代。

2 为什么要设置两个Survivor区

设置两个Survivor区最大的好处就是解决了碎片化，下面我们来分析一下。

为什么一个Survivor区不行？第一部分中，我们知道了必须设置Survivor区。假设现在只有一个survivor区，我们来模拟一下流程：
刚刚新建的对象在Eden中，一旦Eden满了，触发一次Minor GC，Eden中的存活对象就会被移动到Survivor区。这样继续循环下去，下一次Eden满了的时候，问题来了，此时进行Minor GC，Eden和Survivor各有一些存活对象，如果此时把Eden区的存活对象硬放到Survivor区，很明显这两部分对象所占有的内存是不连续的，也就导致了内存碎片化。
我绘制了一幅图来表明这个过程。其中色块代表对象，白色框分别代表Eden区（大）和Survivor区（小）。Eden区理所当然大一些，否则新建对象很快就导致Eden区满，进而触发Minor GC，有悖于初衷。

 

 

碎片化带来的风险是极大的，严重影响JAVA程序的性能。堆空间被散布的对象占据不连续的内存，最直接的结果就是，堆中没有足够大的连续内存空间，接下去如果程序需要给一个内存需求很大的对象分配内存。。。画面太美不敢看。。。这就好比我们爬山的时候，背包里所有东西紧挨着放，最后就可能省出一块完整的空间放相机。如果每件行李之间隔一点空隙乱放，很可能最后就要一路把相机挂在脖子上了。

那么，顺理成章的，应该建立两块Survivor区，刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到第一块survivor space S0，Eden被清空；等Eden区再满了，就再触发一次Minor GC，Eden和S0中的存活对象又会被复制送入第二块survivor space S1（这个过程非常重要，因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生）。S0和Eden被清空，然后下一轮S0与S1交换角色，如此循环往复。如果对象的复制次数达到16次，该对象就会被送到老年代中。下图中每部分的意义和上一张图一样，就不加注释了。

 

 


上述机制最大的好处就是，整个过程中，永远有一个survivor space是空的，另一个非空的survivor space无碎片。

那么，Survivor为什么不分更多块呢？比方说分成三个、四个、五个?显然，如果Survivor区再细分下去，每一块的空间就会比较小，很容易导致Survivor区满，因此，我认为两块Survivor区是经过权衡之后的最佳方案。

 

14.堆内存调优
测试代码

public static void main(String[] args) {
String s = "";
while (true) {
s += "11111111111111111111111111111111111111111111111111111";
}
}

 



 

 

 

 

 

 


图 虚拟机放入参数

 


图 控制台报错 到最后会报OOM（OutOfMemory）堆内存溢出报错


在一个项目中，突然出现了OOM故障,那么该如何排除 研究为什么出错~
●能够看到代码第几行出错:内存快照分析工具，MAT, Jprofiler
●Dubug, 一行行分析代码!

MAT, Jprofiler作用
●分析Dump内存文件,快速定位内存泄露;
●获得堆中的数据
●获得大的对象~

MAT是eclipse集成使用 在这里不学
Jprofile使用
1.在idea中下载jprofile插件
2.联网下载jprofile客户端
3.在idea中VM参数中写参数 -Xms1m -Xmx8m -XX: +HeapDumpOnOutOfMemoryError
4.运行程序后在jprofile客户端中打开找到错误 告诉哪个位置报错
命令参数详解
// -Xms设置初始化内存分配大小/164
// -Xmx设置最大分配内存，默以1/4
// -XX: +PrintGCDetails // 打印GC垃圾回收信息
// -XX: +HeapDumpOnOutOfMemoryError //oom DUMP

MAT,Jprofiler作用

分析Dump内存文件,快速定位内存泄漏

获得堆中的数据,获得大的对象.

MAt是集成在Eclipse中使用.

img

IDEA+Jprofile https://blog.csdn.net/wytocsdn/article/details/79258247
Jprofile https://blog.csdn.net/a294039255/article/details/84863892

堆内存分配的原则

 

 

 

 

 

 

12.GC

GC:Garbage Collection 垃圾收集

Java中,GC的对象是Java堆和方法区(即永久区)

img

img

Eden与Survivor的内存大小比例为8:1:1

1.引用计数法

1.引用计数法

引用计数算法算是实现最简单的了，它只需要一个简单的递归即可实现。现代编程语言比如Lisp，Python，Ruby等的垃圾收集算法采用的就是引用计数算法。现在就让我们来看下引用计数算法(reference counting)是如何工作的。

原理:实际上是通过在对象头中分配一个空间来保存该对象被引用的次数。如果该对象被其它对象引用，则它的引用计数+1，如果删除对该对象的引用，那么它的引用计数就-1，当该对象的引用计数为0时，那么该对象就会被回收。

GC的时候会将计数器为0的对象C给销毁.

引用计数法无法解决循环引用的问题

img

1,1根搜索算法的概念：

　　由于引用计数算法的缺陷，所以JVM一般会采用一种新的算法，叫做根搜索算法。它的处理方式就是，设立若干种根对象，当任何一个根对象到某一个对象均不可达时，则认为这个对象是可以被回收的。

2.复制算法(新生代)

复制算法的概念：

将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。

  • 与标记-清除算法相比，复制算法是一种相对高效的回收方法

  • 不适用于存活对象较多的场合，如老年代（复制算法适合做新生代的GC）

  • 幸存区from和幸存区to中谁空谁是to,我们会将to中的数据复制到from中保持to中数据为空;

  • from和to区实际上为逻辑上的概念,保证to区一直空;

  • 默认对象经过15次GC后还没有被销毁就会进入养老区.

    ff1e1846-e49c-4663-aee1-7c63628f567c

  • img

流程:

  • 将Eden区进行GC存活对象放入空的to区,将from区存活的放到空的to区

  • 此时from区为空变成了to区,to区有数据变为from区

  • 经过15次GCfrom区还存活的对象会被移动到养老区

    img

好处:没有内存碎片

坏处:浪费了内存空间(to区为空)

复制算法最佳使用场景:对象存货度较低(如果存活度较高,则from区空间全部被占满导致会将全部内容复制到to区)

3.标记-清除算法

标记清除算法的概念：

标记-清除算法是现代垃圾回收算法的思想基础。标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段，首先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象；然后，在清除阶段，清除所有未被标记的对象。

它的做法是当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被成为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

  • 需要两次扫描,第一次扫描标记存活对象,第二次扫描清除没有被标记的对象

  • 7de44970-2e02-46a1-a5d0-0663b21906c6

    img

优点:不需要额外的空间

缺点:两次扫描严重浪费时间,并且还会产生内存碎片

4.标记-压缩/整理算法(老年代)

概念：

标记-压缩算法适合用于存活对象较多的场合，如老年代。它在标记-清除算法的基础上做了一些优化。和标记-清除算法一样，标记-压缩算法也首先需要从根节点开始，对所有可达对象做一次标记；但之后，它并不简单的清理未标记的对象，而是将所有的存活对象压缩到内存的一端；之后，清理边界外所有的空间。

cc79889a-0856-4018-92c3-c51108c9caea

  • 在标记清除算法上进行优化,再扫描一次将存活对象移动到一起

    img

总结:

内存效率:复制算法>标记清除算法>标记压缩算法(时间复杂度)

内存整齐度:复制算法=标记压缩算法>标记清除算法

内存利用率:标记压缩算法=标记清除算法>复制算法

没有最好的算法,只有最合适的算法 GC:分代收集算法

​ 年轻代:

  • 存活率低

  • 复制算法

    老年代:

    • 区域大:存活率
    • 标记清除(内存碎片不是太多)+标记压缩混合实现

5.分代收集算法（新生代的GC+老年代的GC）

当前商业虚拟机的GC都是采用的“分代收集算法”，这并不是什么新的思想，只是根据对象的存活周期的不同将内存划分为几块儿。一般是把Java堆分为新生代和老年代：短命对象归为新生代，长命对象归为老年代。

  • 少量对象存活，适合复制算法：在新生代中，每次GC时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成GC。
  • 大量对象存活，适合用标记-清理/标记-整理：在老年代中，因为对象存活率高、没有额外空间对他进行分配担保，就必须使用“标记-清理”/“标记-整理”算法进行GC。

注：老年代的对象中，有一小部分是因为在新生代回收时，老年代做担保，进来的对象；绝大部分对象是因为很多次GC都没有被回收掉而进入老年代。

//当执行GC时，会执行finalize方法，并且只会执行一次
system.gc();

Stop-The-World(part的清洁工,终止part来打扫)：

Java中一种全局暂停的现象。全局停顿，所有Java代码停止，native代码可以执行，但不能和JVM交互

多半情况下是由于GC引起。

少数情况下由其他情况下引起，如：Dump线程、死锁检查、堆Dump。

危害:长时间服务停止，没有响应（将用户正常工作的线程全部暂停掉）

https://www.cnblogs.com/qianguyihao/p/4744233.html

13.垃圾收集器

如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现

1.serial(串行)收集器

2.并行收集器

2.1 PartNew
2.2 Parallel收集器

3.CMS收集器(并发标记清除)

  • Concurrent Mark Sweep 并发标记清除（应用程序线程和GC线程交替执行）
  • 使用标记-清除算法
  • 并发阶段会降低吞吐量（停顿时间减少，吞吐量降低）
  • 老年代收集器（新生代使用ParNew）
  • -XX:+UseConcMarkSweepGC

4.G1收集器

https://blog.csdn.net/laomo_bible/article/details/83112622

14.finalize()方法详解

1. finalize的作用

(1)finalize()是Object的protected方法，子类可以覆盖该方法以实现资源清理工作，GC在回收对象之前调用该方法。
(2)finalize()与C++中的析构函数不是对应的。C++中的析构函数调用的时机是确定的（对象离开作用域或delete掉），但Java中的finalize的调用具有不确定性
(3)不建议用finalize方法完成“非内存资源”的清理工作，但建议用于：① 清理本地对象(通过JNI创建的对象)；② 作为确保某些非内存资源(如Socket、文件等)释放的一个补充：在finalize方法中显式调用其他资源释放方法。其原因可见下文[finalize的问题]

2. finalize的问题

(1)一些与finalize相关的方法，由于一些致命的缺陷，已经被废弃了，如System.runFinalizersOnExit()方法、Runtime.runFinalizersOnExit()方法
(2)System.gc()与System.runFinalization()方法增加了finalize方法执行的机会，但不可盲目依赖它们
(3)Java语言规范并不保证finalize方法会被及时地执行、而且根本不会保证它们会被执行
(4)finalize方法可能会带来性能问题。因为JVM通常在单独的低优先级线程中完成finalize的执行
(5)对象再生问题：finalize方法中，可将待回收对象赋值给GC Roots可达的对象引用，从而达到对象再生的目的
(6)finalize方法至多由GC执行一次(用户当然可以手动调用对象的finalize方法，但并不影响GC对finalize的行为)

3. finalize的执行过程(生命周期)

(1) 首先，大致描述一下finalize流程：当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。否则，若对象未执行过finalize方法，将其放入F-Queue队列，由一低优先级线程执行该队列中对象的finalize方法。执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活”。
(2) 具体的finalize流程：
对象可由两种状态，涉及到两类状态空间，一是终结状态空间 F = {unfinalized, finalizable, finalized}；二是可达状态空间 R = {reachable, finalizer-reachable, unreachable}。

finalize方法的使用总结：

  • 经验：避免使用finalize()，操作不慎可能导致错误。
  • 优先级低，何时被调用，不确定

何时发生GC不确定，自然也就不知道finalize方法什么时候执行

  • 如果要使用finalize去释放资源，我们可以使用try-catch-finally来替代它

14.JMM

img

img

总的来说，就是保证共享变量进行加锁保证数据的一致性。

 

 

 

posted @ 2021-06-04 23:11  你的雷哥  阅读(650)  评论(1)  编辑  收藏  举报