云南建设厅网站,凡科2网站需要备案吗,ztjs登录,中国建设网官网首页概述
Java是支持自动垃圾回收的#xff0c;有些语言不支持自动垃圾回收#xff08;C#xff09;自动垃圾回收不是Java的首创
垃圾是什么#xff1f;
在 JVM 中垃圾是指在运行程序中没有任何指针指向的对象#xff0c;这个对象就是需要被回收的垃圾。
哪些区域需要回收…概述
Java是支持自动垃圾回收的有些语言不支持自动垃圾回收C自动垃圾回收不是Java的首创
垃圾是什么
在 JVM 中垃圾是指在运行程序中没有任何指针指向的对象这个对象就是需要被回收的垃圾。
哪些区域需要回收垃圾
堆方法区
为什么要GC
如果不及时对内存进行垃圾清理那么这些垃圾所占的内存空间会一直保留到应用程序结束被保留的空间无法被其他对象使用甚至可能导致内存溢出也就是常说的 OOM在回收时还可以将内存碎片进行整理数组必须使用连续空间
内存溢出和内存泄露
内存溢出经过垃圾回收后内存中仍然无法储存创建的新对象内存不够用溢出。内存泄露IO流 close jdbc连接 close 没有关闭一些对象已经不使用了但是垃圾回收器不能将其判定为垃圾这些对象就在后台默默占用内存这种情况被称为内存泄露大量的这种对象存在一是导致内存溢出的原因。
自动垃圾回收
好处 解放程序员对内存的管理更加合理自动化坏处 会影响程序员在内存管理方面的能力如果出现异常无法精准定位问题所在 在回收次数上频繁收集新生代Young区较少收集Old区基本不手机方法区元空间
垃圾回收相关算法
标记阶段算法
判断你对象是否是垃圾对象是否有引用指向对象
引用计数法Reference Couting在现在的JVM中没有使用
有个计数器来计算对象的引用数量 String s1 new String(aaa);String s2 s1; //有两个引用变量指向aaas2 null; -1s1 null; -1//最终指向aaa的引用变量为0优点 实现简单垃圾对象容易辨识判定效率高回收没有延迟性 确定 需要单独的字段存储计数器这样的做法增加了存储空间的开销每次赋值都需要更新计数器伴随着加法和减法操作这增加了时间开销最严重的问题是无法处理循环引用的情况多个对象之间互相引用没有其他外部引用指向他们计数器不为0不能回收产生内存泄露因此在Java中垃圾回收器中没有这类算法。
可达性分析算法跟搜索算法
实现思路从一些为跟对象GCRoots的对象出发去查找与根据对象直接或间接连接的对象就是存活对象不与跟对象引用连接的对象就是垃圾对象
GC Roots 可以是哪些元素
在虚拟机栈中引用的对象方法区中存储的静态成员指向的独享作为同步锁使用的synchronized在虚拟机内部使用的对象
对象的finalization机制 在对象销毁之前还会调用finalize()方法 当一个对象被标记为垃圾后在真正被回收之前会调用一次object类中的finalize方法 -ps自己不要调用finalize留给垃圾回收器去调用 由于 finalize()方法的存在虚拟机中的对象一般处于三种可能的状态 可触及的从根节点开始可以到达这个对象。这种对象不是垃圾不用回收 可复活的对象的所有引用都被释放但是对象有可能在 finalize()中复活。 不可触及的对象的 finalize()被调用并且没有复活那么就会进入不可触及状态。此时这种对象就是必须被回收的垃圾。 以上 3 种状态中是由于 finalize()方法的存在进行的区分。只有在对象不可触及时才可以被回收
具体流程 判定一个对象obj是否被能被回收需要进行两次标记过程
如果obj 到GCRoot没有引用链进行第一次标记进行进一步筛选 如果obj没有重写finalize方法或者已经被调用过一次则obj被判定为不可触及的进行回收如果obj重写了finalize方法且没有被执行过则obj会被插入到队列中由一个由jvm自动创建的低优先级Finalizer线程触发其finalize方法在该线程中如果obj在finalize方法中与GCRoots上的任何一个对象创建了联系那么在第二次标记的时候obj就会被移出“即将被回收”的集合里完成复活。如果再次出现没有引用的情况finalize方法就不会再次触发
public class CanReliveObj {public static CanReliveObj obj;//类变量属于 GC Root//此方法只能被调用一次Overrideprotected void finalize() throws Throwable {//super.finalize();System.out.println(调用当前类重写的finalize()方法);obj this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系}public static void main(String[] args) {try {obj new CanReliveObj();// 对象第一次成功拯救自己obj null;System.gc();//调用垃圾回收器,触发FULL GC 也不是调用后立刻就回收的,因为线程的执行权在操作系统System.out.println(第1次 gc);// 因为Finalizer线程优先级很低暂停2秒以等待它Thread.sleep(2000);if (obj null) {System.out.println(obj is dead);} else {System.out.println(obj is still alive);}System.out.println(第2次 gc);// 下面这段代码与上面的完全相同但是这次自救却失败了obj null;System.gc();// 因为Finalizer线程优先级很低暂停2秒以等待它Thread.sleep(2000);if (obj null) {System.out.println(obj is dead);} else {System.out.println(obj is still alive);}} catch (InterruptedException e) {e.printStackTrace();}}
}/**
控制台输出结果第一次 gc调用当前重写的finalize()方法obj is still alive第二次 gcobj is dead
*/垃圾回收阶段算法
标记-复制算法
将内存分为大小相等的两份把当前使用的空间中存活的对象复制到另一个空间中将正在使用的空间中垃圾对象清除。 优点可以减少内存碎片 缺点如果需要复制的对象数量多效率就会低 适用场景存活对象少 新生代适合使用标记复制算法
标记-清除算法
清除不是真正的把对象垃圾清除掉将垃圾对象地址维护到一个空闲列表中后面有新对象到来时覆盖掉垃圾对象即可。特点 实现简单效率低回收后有碎片产生 标记-压缩算法标记-整理
先从根节点标记所有被应用对象然后将所有存活对象压到内存的一端按顺序排放。之后清除边界外的所有空间特点 消除了标记-清除算法中的碎片空间解决了标记-复制算法需要2倍空间的问题从效率上来说是三种算法中最慢的移动对象的同时如果对象被其他对象引用还需要引用对象的地址在移动过程中会暂停用户应用程序造成STW 标记-压缩算法与标记-清除算法的比较
标记-压缩算法的最终效果等同于标记-清除算法执行完成后再进行一次内存碎片整理因此也可以把它称为标记-清除-压缩Mark-Sweep-Compact算法二者的本质差异在于标记-清除算法是一种非移动式的回收算法空闲列表记录位置标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。可以看到标记的存活对象将会被整理按照内存地址依次排列而未被标记的内存会被清理掉。如此一来当我们需要给新对象分配内存时JVM 只需要持有一个内存的起始地址即可这比维护一个空闲列表显然少了许多开销。
垃圾回收算法小结
效率上来说复制算法是当之无愧的老大但是却浪费了太多内存。 而为了尽量兼顾上面提到的三个指标标记-压缩算法相对来说更平滑一些但是效率上不尽如人意它比复制算法多了一个标记的阶段比标记-清除多了一个整理内存的阶段。 垃圾回收相关概念
System.gc()
默认情况下通过System.gc()或者Runtime.getRuntime().gc()的调用会显示触发Full GC同时对老年代新生代进行回收尝试释放丢弃对象占用的内存一般情况下不手动进行System.gc()在特殊情况下可以使用
STWStop The World
指的是在进行GC时会产生应用程序的停顿这种停顿会让整个应用程序线程都停掉无响应有点像卡顿这样的情况被称为STW
垃圾回收器
垃圾回收器是垃圾回收的具体实现者垃圾回收算法是垃圾回收器的方法论
垃圾回收器分类
按照线程数量 单线程回收器SerialSerial old 多线程回收器Parallel 单线程垃圾回收器 只有一个线程进行垃圾回收适用于简单小型的使用场景垃圾回收时其他用户线程会暂停。
多线程垃圾回收器 使用多个线程进行垃圾回收在多CPU的情况下大大的提升了垃圾回收的效率 同样会停止用户线程 按照工作模式 独占式垃圾回收线程执行时其他线程暂停 并行式垃圾回收线程可以和用户线程同时执行只在一部分阶段并行 按照工作内存区间 老年代垃圾回收器 年轻代垃圾回收器 *下图展示了7种作用于不同分代的收集器如果两个收集器之间存在连线则说明他们能搭配使用。虚拟机所处的区域则代表他们存在于新生代还是老年代收集器。
垃圾回收指标
吞吐量运行用户代码占总运行代码的时间垃圾收集开销垃圾收集占用的时间与总运行时间的比例暂停时间执行垃圾收集时占用的时间回收的速度占用内存大小Java堆区所占用内存的大小
CMS垃圾回收器
CMSConcurrentMarkSweep并发标记清除是以获取最短停顿时间为目标的垃圾回收器它在垃圾回收时使得用户线程和回收线程并发执行因此在垃圾收集过程中用户也不会感到明显的卡顿
垃圾回收的过程
初始标记先进行STW使用一条初始线程对所有与GCRoots直接关联的对象进行标记并发标记垃圾回收线程与用户线程并行在此过程中进行可达性分析标记处所有需要回收的废弃对象重新标记STW使用多条标记线程并发执行并将刚才过程中新出现的废弃对象标记出来并发清除使用一条GC线程与用户线程并发执行清除刚才标记的对象这个过程最耗时。 由于并发标记和并发清除耗时最长且可以与用户线程同时工作因此总体上来说CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS的优点 可以做到并发收集
CMS的弊端 1.CMS 是基于标记-清除算法来实现的,会产生内存碎片。 2.CMS 在并发阶段它虽然不会导致用户线程停顿但是会因为占用了一部分 线程而导致应用程序变慢总吞吐量会降低。 3.CMS 收集器无法处理浮动垃圾floating garbage。
三色标记算法CMS
由于CMS有并发执行的过程所以在标记垃圾对象时有不确定性。所以在标记时将对象分为三种状态黑色例如GCRoots 确定是存活的对象灰色与黑色对象关联的对象其中还有未扫描完的之后还需要再次扫描白色与黑色灰色都无关联的垃圾收集算法不可达的对象
三色标记的过程 1.先确立GCRoots把GCRoots标记为黑色 2.与GCRoots相连接的标记为灰色 3.再次遍历灰色灰色变为黑色如果原来灰色下面有关联其他对象则将其变为灰色。 4.重复步骤3最终只保留黑色灰色回收白色对象 可能会出现漏标和错标的现象
漏标假设 GC 已经在遍历对象 B 了而此时用户线程执行了 A.Bnull 的操作切断了 A 到 B 的引用本来执行了 A.Bnull 之后B、D、E 都可以被回收了但是由于 B 已经变为灰色它仍会被当做存活对象继续遍历下去。最终的结果就是本轮 GC 不会回收 B、D、E留到下次 GC 时回收也算是浮动垃圾的一部分。 错标假设 GC 线程已经遍历到 B 了此时用户线程执行了以下操作B.Dnull;//B 到 D 的引用被切断A.xxD;//A 到 D 的引用被建立B 到 D 的引用被切断且 A 到 D 的引用被建立。此时 GC 线程继续工作由于 B 不再引用 D 了尽管 A 又引用了 D但是因为 A 已经标记为黑色GC 不会再遍历 A 了所以 D 会被标记为白色最后被当做垃圾回收。可以看到错标的结果比漏表严重的多浮动垃圾可以下次 GC 清理而把不该回收的对象回收掉将会造成程序运行错误。
解决错标的问题 错标只有满足灰色指向白色的引用全部断开黑色建立了指向白色的引用这两种情况才会发生只需要解决这两种的其中一种原因就能避免错标的问题 解决办法原始快照和增量更新。 原始快照打破的是第一个条件当灰色对象指向白色对象的引用被断开时就将这条引用关系记录下来。当扫描结束后再以这些灰色对象为根重新扫描一次。增量更新打破的是第二个条件当黑色指向白色的引用被建立时就将这个新的引用关系记录下来等扫描结束后再以这些记录中的黑色对象为根重新扫描一次。相当于黑色对象一旦建立了指向白色对象的引用就会变为灰色对象。 G1回收器Garbage-First
将堆内存的各个区域又分为较小的多个区对这些个区域进行监测对某一个区域中垃圾数量大的区域优先回收也是并发收集的。G1主要针对配备多核 CPU 及大容量内存的机器以极高概率满足 GC 停顿时间的同时还兼具高吞吐量的性能特征 适用场景要求尽可能可控 GC 停顿时间内存占用较大的应用
查看 JVM 垃圾回收器设置垃圾回收
//打印默认垃圾回收器
-XX:PrintCommandLineFlags -version
JDK 8 默认的垃圾回收器
//年轻代使用 Parallel Scavenge GC
//老年代使用 Parallel Old GC
//打印垃圾回收详细信息
-XX:PrintGCDetails -version
//设置默认垃圾回收器
//Serial 回收器
-XX:UseSerialGC 年轻代使用 Serial GC 老年代使用 Serial Old GC
//ParNew 回收器
-XX:UseParNewGC 年轻代使用 ParNew GC,不影响老年代。CMS 回收器
-XX:UseConcMarkSweepGC 老年代使用 CMS GC。G1 回收器
-XX:UseG1GC 手动指定使用 G1 收集器执行内存回收任务。
-XX:G1HeapRegionSize 设置每个 Region 的大小
