域名申请好了 怎么做网站,如何将自己做的网站,单页面网站怎么做优化排名,百度下载安装20191.垃圾收集的经典问题 1.哪些内存需要回收2.什么时候回收3.如何回收1.你知道哪几种垃圾回收器#xff0c;各自的优缺点#xff0c;重点讲一下cms和g12.JVM GC算法有哪些#xff0c;目前的JDK版本采用什么回收算法3.G1回收器的回收过程 1.Java中垃圾的定义#xff08;Garbag… 1.垃圾收集的经典问题 1.哪些内存需要回收2.什么时候回收3.如何回收1.你知道哪几种垃圾回收器各自的优缺点重点讲一下cms和g12.JVM GC算法有哪些目前的JDK版本采用什么回收算法3.G1回收器的回收过程 1.Java中垃圾的定义Garbage 1.垃圾是指在运行程序中没有任何指针指向的对象这个对象就是需要被回收的垃圾 1.垃圾的危害 1.如果不及时对内存中的垃圾进行清理那么这些垃圾对象所占的内存空间会一直保留到应用程序结束被保留的空间无法被其他对象使用甚至可能导致内存溢出 2.磁盘碎片整理 1.机械硬盘需要碎片整理通过改变磁极用于表示01机械硬盘会有坏点2.固态硬盘不断添加电子表示数据剩余檫取次数如果没有了会丢失数据 3.为什么需要GC 1.对于高级语言来说一个基本认知是如果不进行垃圾回收内存迟早都会被消耗完2.除了释放1没用的对象垃圾回收也可以清除内存里的记录碎片碎片整理将所占用的堆内存移到堆的一端以便JVM将整理出的内存分配给新的对象3.随着应用程序所应付的业务越来越庞大复杂用户越来越多没有GC就不能保证应用程序的正常优化 4.自动内存管理 1.无需开发人员手动参与内存的分配与回收这样降低内存泄漏和内存溢出的风险自动内存管理机制将程序员从繁重的内存管理中释放出来可以更专心地专注于业务开发2.问题对于Java开发人员而已如果过度依赖于自动会弱化Java开发人员在程序出现内存溢出时定位问题和解决问题的能力3.只有真正了解JVM的自动内存分配和内存回收原理才能在遇到OutOfMemoryError时快速地根据错误异常日志定位问题和解决问题 1.对象的finalization机制 1.Java语言提供了对象终止机制(finalization)来允许开发人员提供对象被销毁之前的自定义处理逻辑2.当垃圾回收器发现一个对象没有引用指向即垃圾回收对象之前总会先调用这个对象的finalize()方法3.finalize()方法允许在子类中被重写用于在对象被回收时进行资源释放通常在该方法中进行一些资源释放和清理的工作如关闭文件套接字和数据连接等4.永远不要主动调用某个对象的finalize()方法应该交给垃圾回收机制调用 1.finalize()时可能会导致对象复活2.finalize()方法的执行时间是没有保障的它完全由GC线程决定极端情况下若不发生GC则finalize()方法将没有执行机会3.一个糟糕的finalize()会引用影响GC的性能 从功能上来说finalize()方法与C中的析构函数比较相似但是Java采用的是基于垃圾回收器的自动内存管理机制所以finalize()方法在本质上不同于C的析构函数由于finalize()方法的存在虚拟机中的对象一般处于三种可能的状态如果从所有的根节点都无法访问到某个对象说明对象已经不再使用了一般来说。此对象需要被回收但事实上也并非是非死不可的这时候他们暂时处于缓刑阶段一个无法触及的对象有可能在某一个条件下复活自己如果这样那么对它的回收就是不合理的为此定义虚拟机中对象可能的三种状态可触及的从根节点开始可以到达这个对象可复活的对象的所有引用都被释放但是对象有可能在finalize()中复活不可触及的对象的finalize()被调用并且没有复活那么就会进入不可触及状态不可触及状态的对象不可能被复活因为finalize()只会被调用一次以上3种状态中是由于finalize()方法的存在进行的区分只有在对象不可触及时才可以被回收具体过程判定一个对象ObjA是否可回收至少要经历两次标记过程1.如果对象objA到GCRoots没有引用链则进行第一次标记2.进行筛选判断此对象是否有必要执行finalize()方法1.如果对象objA没有重写finalize()方法或者finalize()方法已经被虚拟机调用过则虚拟机视为没有必要执行objA被判定为不可触及的2.如果对象objA重写了finalize()方法且还未执行过那么objA会被插入到F-Queue队列中由一个虚拟机自动创建的低优先级的Finalizer线程触发其finalize()方法执行3.finalize()方法是对象逃脱死亡的最后就会稍后GC会对F-Queue队列中的对象进行第二次标记如果objA在finalize()方法中与引用链上的任何一个对象建立了联系那么在第二次标记时objA会被处于即将回收集合。之后对象会再次出现没有引用存在的情况在这个情况下finalize方法不会被再次调用对象会直接变成不可触及的状态也就是说一个对象的iinalize方法只会内调用一次 1.MAT与JProfiler的GC Roots溯源 MAT是Memory Analyer的简称它是一款功能强大的Java堆内存分析器用于查找内存泄露以及查看内存消耗情况MAT是基于Eclipse开发的是一块免费的性能分析工具获取dump文件方式1命令行使用jmap 2.GC的作用区域 1.GC的作用区域 1.方法区并不要求具体的垃圾回收器一定要回收方法区2.堆主要存放对象 2.垃圾回收期间可对年轻代回收也可对老年代回收甚至是全堆和方法区的回收3.其中Java堆是垃圾回收器的工作重点,从次数上讲 1.频繁收集Young区(新生代)2.较少收集old区(老年代)3.基本不动方法区(JDK1.7永久代/JDK1.8元空间) 3.垃圾回收相关算法 1.GC的过程分为两个阶段 1.标记阶段标记出哪些对象不再使用2.清除阶段清除标记的对象 1.标记阶段 1.垃圾标记阶段即判断对象是否存活2.JVM的堆中存放着几乎所有的Java对象实例GC执行垃圾回收之前首先要区分出内存中哪些是存活对象哪些是已经死亡的对象3.只有被标记为已经死亡的对象GC才会在执行垃圾回收时释放掉其所占用的内存空间因此这个过程可称为垃圾标记阶段4.JVM中标记死亡对象即当一个对象已不再被任何的存活对象引用指针继续引用时即可宣判为已死亡5.判断对象存活一般有两种方式 1.引用计数算法2.可达性分析算法 1.引用计数算法未使用 1.引用计数算法(Reference Counting) 1.为每个对象保存一个整型的引用计数器属性用于记录对象被引用的情况2.对于一个对象A只要有任何一个对象引用了A则A的引用计数器就加1当引用失效时引用计数器就减1只要对象A的引用计数器值为0即表示对象A不可再被使用可进行回收 2.优点实现简单垃圾对象便于辨识判定效率高回收没有延迟性(随时可回收)3.缺点 1.需要单独的字段存储计数器增加了存储空间的开销2.每次赋值都需要更新计数器伴随着加法和减法操作这增加了时间开销3.引用计数器有一个严重的问题即无法处理循环引用的情况这是一条致命缺陷导致在Java的垃圾回收器中没有使用这类算法 4.证明Java未使用引用计算算法 -XXPrintGCDetails查看垃圾回收的细节证明java使用的不是引用计数算法 5.应用范围引用计数算法是很多语言的资源回收选择其中Python支持垃圾收集机制且使用了引用计数算法以提高吞吐量6.解决方式Java没有选择引用计数是因为其存在一个基本的难题即很难处理循环引用关系Python采用以下方式解决循环引用的问题 1.手动解除合适的时机解除引用关系2.使用弱引用weakref只要发现弱引用无论内存空间是否足够都进行回收weakref是Python提供的标准库旨在解决循环引用 2.可达性分析算法使用中 1.可达性分析算法也叫根搜索算法/追踪性垃圾收集(Tracing Garbage Collection)JavaC# 1.根对象集合(GC Roots)即一组必须活跃的引用2.可达性分析算法是以根对象集合(GC Roots)为起始点按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达3.使用可达性分析算法后内存中的存活对象都会被根对象集合直接或间接连接着搜索所走过的路径称为引用链(Reference Chain)4.如果目标对象没有与任何引用链相连则是不可达的即意味着该对象已死亡可标记为垃圾对象 2.相对于引用计数算法可达性分析算法不仅同样具备实现简单和执行高效等特点更重要该算法可有效解决在引用计数算法中循环引用的问题防止内存泄露的发生3.可达性分析算法中只有能够被根对象集合直接或间接连接的对象才是存活对象Java语言中GC Roots包括以下几类元素 1.虚拟机栈中引用的对象如各个线程被调用的方法中使用到的参数局部变量等2.本地方法栈内(说的本地方法(JNI)引用的对象3.方法区中类静态属性引用的对象如Java类的引用型静态变量4.方法区中常量引用的对象如字符串常量池(String Table)里的引用5.所有被同步锁synchronized持有的对象6.Java虚拟机内部的引用基本数据类型对应的Class对象一些常驻的异常对象(如NullPointerExceptionOutOfMemoryError)系统类加载器7.反映java虚拟机内部情况的JMXBeanJVMTI中注册的回调本地代码缓存等8.除了上述固定的GC Roots集合以外根据用户所选用的垃圾收集器以及当前回收的内存区域不同还可有其他对象临时性地加入共同构成完整的GC Roots集合如分代收集和局部回收(Partial GC) 4.局部回收如果只针对Java堆中的某一块区域进行垃圾回收(例只针对新生代)须考虑到内存区域是虚拟机自己的实现细节一个区域的对象完全有可能被其他区域的对象所引用这时需要一并将关联的区域对象也加入GC Roots集合中去考虑才能保证可达性分析的准确性5.总结 由于Root采用栈方式存放变量和指针所以如果一个指针其保存了堆内存中的对象但是本身又不存放堆内存里面那其就是一个Root6.注意 1.如果使用可达性分析算法来判断内存是否可回收那么分析工作必须在一个能保障一致性分析过程中引用关系不能变化的快照中进行这点不满足的话分析结果的准确性就无法保证2.这点也是导致GC时必须Stop The World的一个重要原因即使是几乎不会发生停顿的CMS收集器中枚举根节点时也必须要停顿 2.清除阶段 1.标记-清除算法 垃圾清除阶段当成功区分出内存中存活对象和死亡对象后GC接下来的任务就是执行垃圾回收释放掉无用对象所占用的内存空间以便有足够的可用内存空间对新对象分配内存目前在JVM中比较常见的三种垃圾收集算法是标记-清除算法(Mark-Sweep)复制算法(Copying),标记-压缩算法(Mark-Compact)背景标记-清除suanfa(Mark-Sweep)是一种非常基础和常见的垃圾收集算法该算法被J.McCarthy等人在1960年提出并应用于Lisp语言执行过程 当堆中的有效内存空间(available memory)被耗尽的时候就会停止整个程序(也被成为stop the world)然后进行两项工作第一项则是标记第二项则是清除标记Collection从引用根节点开始遍历标记所有被引用的对象一般是在对象的Header中记录为可达对象清除Collector对堆内存从头到尾进行线性遍历如果发现某个对象在其Header中没有标记为可达对象则将其回收 缺点效率不高在进行GC的时候需要停止整个应用程序导致用户体验差这种方式清理出来的空间内存是不连续的产生内存碎片需要维护一个空闲列表注意何为清除这里所谓的清除并不是真的置空而是把需要清除的对象地址保存在空间的地址列表里下次有新对象需要加载时判断垃圾的位置空间是否够如果够就存放(覆盖) 清除阶段复制算法 为了解决标记-清除算法在垃圾收集效率方面的缺陷核心思想将活着的内存空间分为两块每次只使用其中一块在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中之后清除正在使用的内存块中的所有对象交换两个内存的角色最后完成垃圾回收 优点没有标记和清除的过程实现简单运行高效复制过去以后保证空间的连续性不会出现碎片问题缺点需要两倍的内存空间对于G1这种分拆成为大量region(分区)的GC复制而不是移动意味着GC需要维护region之间对象引用关系(指针位置)不管是内存占用或者时间开销也不小特别如果系统中的垃圾对象很少复制算法不会很理想复制算法需要复制的存活对象数量并不会太大或者说非常低才行(否则就会造成额外的复制)应用场景在新生代对常规应用的垃圾回收一次通常可以回收70%-99%的内存空间回收性价比很高所以现在的商业虚拟机都是用这种收集算法回收新生代 清除阶段标记-压缩算法 或者叫标记整理背景复制算法的高效性是建立在存活对象少垃圾对象多的前提下的这种情况在新生代经常发生但是在老年代更常见的情况是大部分对象都是存活对象如果依然使用复制算法由于存活对象较多复制的成本也将很高因此基于老年代垃圾回收的特性需要使用其他的算法标记-清除算法的确可以应用在老年代但是该算法不仅执行效率低下而且在执行完内存回收后还会产生内存碎片所以JVM的设计者需要在此基础上进行改进标记-压缩(Mark-Compact)算法由此诞生执行过程第一阶段和标记-清除算法一样从根节点开始标记所有被引用对象第二阶段将所有的存活对象压缩到内存的一端按顺序排放之后清理边界外所有的空间 标记-压缩算法的最终效果等同于标记-清除算法执行完成后再进行一次内存碎片整理因此也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法二者的本质差异在于标记-清除算法是一种非移动式的回收算法标记压缩是移动式的是否移动回收后的存活对象是项优缺点并存的风险决策可以看到标记的存活对象将会被整理按照内存地址依次排列而未被标记的内存会被清理掉如此一来当我们需要给新对象分配内存时JVM只需要持有一个内存的起始地址即可这比维护一个空闲列表显然少了许多开销指针碰撞(Bump the Pointer)如果内存空间以规整和有序的方式分布即已用和未用的内存都各自一边彼此之间维系着一个记录下一次分配起始点的标记指针当为新对象分配内存时只需要通过修改指针的偏移量将新对象分配在第一个空闲内存位置上这种分配方式就叫做指针碰撞标记压缩的优点消除了标记-清除算法当中内存区域分散的缺点我们需要给新对象分配内存时JVM只需要持有一个内存的起始地址即可消除了复制算法当中内存减半的高额代价缺点从效率上来说标记整理算法要低于复制算法移动对象的同时如果对象被其他对象引用则还需要调整引用的地址移动过程中需要全程暂停用户应用程序即STWStop the world 小结 效率上复制算法最快但是却浪费了太多内存兼顾三个指标标记整理算法相对来说更平滑一些但是效率上不高它比复制算法多了一个标记的阶段比标记-清除多了一个整理内存的阶段 分代收集算法 前面所有这些算法中并没有一种算法可以完全替代其他算法它们都具有自己独特的优势和特点分代收集算法应运而生分代收集算法是基于这样一个事实不同的对象的生命周期是不一样的因此不同生命周期的对象可以采取不同的收集方式以便提高回收效率一般是把Java堆分为新生代和老年代这样就可以根据各个年代的特点使用不同的回收算法以提高垃圾回收的效率在Java程序运行的过程中会产生大量的对象其中有些对象是与业务信息相关比如Http请求中的Session对象线程Socket连接这类对象根业务直接挂钩因此生命周期比较长但是还有一些对象主要是程序运行过程中生成的临时变量这些对象生命周期会比较短比如String对象由于其不变类的特性系统会产生大量的这些对象有效对象甚至只用回收一次即可回收目前几乎所有的GC都是采用分代收集(Generational Collecting)算法执行垃圾回收的在HostSpot中基于分代的概念GC所使用的内存回收算法必须节后年轻代和老年代各自的特点年轻代(Young Gen)年轻代特点区域相对老年代较小对象生命周期短存活率低回收频繁这种情况复制算法的回收整理速度是最快的复制算法的效率只和当前存活对象大小有关因此很合适年轻代的回收而复制算法内存利用率不高的问题通过HotSpot中的两个survivor的设计得到缓解老年代(Tenured Gen)老年代特点区域较大对象生命周期长存活率高回收不及年轻代频繁这种情况存在大量存活率高的对象复制算法明显变得不合适一般是由标记-清除或者是标记-清除与标记整理的混合实现Mark阶段的开销与存活对象的数量成正比Sweep阶段的开销与所管理区域的大小成正相关Compact阶段的开销与存活对象的数据成正比以HotSpot中的CMS回收器为例CMS是基于Mark-Sweep实现的对于对象的回收效率很高。而对于碎片问题CMS采用基于Mark-Compact算法的Serial Old 回收器作为补偿措施当内存回收不佳(碎片导致的Concurrent Mode Failure时)将采用Serial Old执行Full GC以达到对老年代内存的整理分代的思想被现有的虚拟机广泛使用几乎所有的垃圾回收器都区分新生代和老年代 增量收集算法 上述现有的算法在垃圾回收过程中应用软件将处于一种stop the world的状态在stop the world状态下应用程序所有的线程都会挂起暂停一起正常的工作等待垃圾回收的完成如果垃圾回收时间过长应用程序会被挂起很久将严重影响用户体验或者系统的稳定性为了解决这个问题即对实时垃圾收集算法的研究直接导致了增量收集(Incremental Collecting)算法的诞生基本思想如果一次性将所有的垃圾进行处理需要造成系统长时间的停顿那么就可以让垃圾收集线程和应用程序线程交替执行每次垃圾收集线程只收集一小片区域的内存空间接着切换到应用程序线程依次反复直到垃圾收集完成总的来说增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理允许垃圾收集线程以分阶段的方式完成标记清理或复制工作缺点使用这种方式由于在垃圾回收过程中间断性还执行了应用程序代码所以能减少系统的停顿时间但是因为线程切换和上下文切换的消耗会使得垃圾回收的总体成本上升造成系统吞吐量的下降 分区算法 一般来说在相同条件下堆空间越大一次GC时所需要的时间就越长有关GC产生的停顿也越长为了更好地控制GC产生的停顿时间将一块大的内存区域分割成多个小块根据目标的停顿时间每次合理地回收若干个小区间而不是整个堆空间从而减少一次GC所产生的停顿分代算法将安装对象的生命周期长短划分成两个部分分区算法将整个堆空间划分成连续的不同小区间每一个小区间都独立使用独立回收这种算法的好处时可以控制一次回收多少个小区间 垃圾回收概念 System.gc()的理解 在默认情况下通过System.gc()或者Runtime.getRuntime().gc()的调用会显示触发Full GC,同时对老年代和新生代进行回收尝试释放被丢弃对象占用的内存然而System.gc()调用附带一个免责声明无法保证对垃圾收集器的调用不一定立马执行JVM实现者可以通过System.gc()调用来决定JVM的GC行为而一般情况下垃圾回收应该是自动进行的无需手动触发否则就太过麻烦了在一些特殊情况下如我们在编写一个性能基准(测试)我们可以在运行之间调用System.gc() 内存溢出 内存溢出(OOM)相对于内存泄露来说尽管更容易被理解但是同样的内存溢出也是引发程序崩溃的罪魁祸首之一Java doc中对OutOfMemortyError的解释是没有空闲内存并且垃圾收集器也无法提供更多内存首先说没有空闲内存的情况说明Java虚拟机的堆内存不够原因有二1.Java虚拟机的堆内存设置不够比如可能存在内存泄露问题也很有可能就是堆的大小不合理比如我们要处理比较可观的数据量但是没有显示指定JVM堆大小或者指定数值偏小我们可以通过参数-Xms,-Xmx来调整2.代码中创建了大量大对象并且长时间不同被垃圾收集器收集(存在被引用)对于老版本的Oracle JDK,因为永久代的大小是有限的并且JVM对永久代垃圾回收(如常量池回收卸载不再需要的类型)非常不积极所以当我们不断添加新类型的时候永久代出现OutOfMemoryError非常多见尤其是在运行时存在大量动态类型生成的场合类似intern字符串缓存占用太多空间也会导致OOM问题对应的异常信息会标记出来和永久代相关java.lang.OutOfMemoryErrorPermGen space随着元数据的引入方法区内存已经不再那么窘迫所以相应的OOM有所改观出现OOM异常信息则变成了java.lang.OutOfMemoryError:Metaspace.直接内存不足也会导致OOM这里隐含着一层意思是在抛出OutOfMemoryError之前通常垃圾收集器会被触发尽其所能去清理出空间例如在引用机制分析中涉及到JVM会去尝试回收软引用指向的对象等在java.nio.BIts.reserveMemory()方法中我们能清除的看到System.gc()会被调用以清理空间当然也不是在任何情况下垃圾收集器都会被触发的如果我们去分配一个超大对象类似一个超大数组超过堆的最大值JVM可以判断出垃圾收集并不能解决这个问题所以直接抛出OutOfMemoryError 内存泄露(Memory Leak) 也称作存储泄露。严格来说只有对象不会再被程序用到了(自己的代码无法再被引用了)但是GC又不能回收他们的情况才叫内存泄露但实际情况很多时候一些不太好的实践会导致对象的生命周期变得很长甚至导致OOM也可以叫做宽泛意义上的内存泄露尽管内存泄露并不会立即引起程序崩溃但是一旦发生内存泄露程序中可用内存就会逐步蚕食直至耗尽所有内存最终出现OutOfMemory异常导致程序崩溃注意这里的存储空间并不是指物理内存而是指虚拟内存大小这个虚拟内存大小取决于磁盘交换区设定的大小 举例1.单例模式单例的生命周期和应用程序是一样长的所以单例程序中如果持有对外部对象的引用的话那么这个外部对象是不能被回收的则会导致内存泄露的产生(例runtime)2.一些提供close的资源未关闭导致内存泄露数据库连接(dataSource.getConnection())网络连接(socket)和io连接必须手动close否则是不能被回收的 Stop The World Stop the world简称STW指的是GC时间发生过程中会产生应用程序的停顿停顿产生时整个应用程序线程都会被暂停没有任何响应优点像卡死的感觉这个停顿称为STW可达性分析算法中枚举根节点(GC Roots)会导致所有Java执行线程停顿分析工作必须在一个能确保一致性的快照中进行一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上如果出现分析过程中对象引用关系还不断变化则分析结果的准确性无法保证被STW中断的应用程序线程会在完成GC后恢复频繁中断会让用户感觉像是网速不快造成电影卡带一样所以我们需要减少STW的发生STW事件和采用哪款GC无关所有的GC都有这个事件哪怕是G1也不能完全避免Stop-the-world情况发生只能说垃圾回收器越来越优秀回收效率越来越高尽可能地缩短了暂停时间STW是JVM在后台自动发起和自动完成的在用户不可见的情况下把用户正常的工作线程全部停掉开发中不要用System.gc()会导致Stop-the-world的发生 程序的并行与并发 并发(Concurrent)在操作系统中是指一个时间段中有几个程序都处于已启动运行到运行完毕之间且这几个程序都是在同一个处理器上运行并发不是真正意义上的同时进行只是CPU把一个时间段划分成几个时间片段(时间区间)然后在这几个时间区间之间来回切换由于CPU处理的速度非常快只要时间间隔处理得当即可让用户感觉是多个应用程序同时在进行并行(Parallel)当系统有一个以上CPU时当一个CPU执行一个进程时另一个CPU可以执行另一个进程两个进程互不抢占CPU资源可以同时进行我们称之为并行(Parallel)其实决定并行的因素不是CPU的数量而是CPU的核心数量比如一个CPU有多个核也可以并行并发指多个事情在同一时间段内同时发生并行指多个事情在同一时间点上同时发生了并发的多个任务之间是互相抢占资源的并行的多个任务之间是不互相抢占资源的只有在多CPU或者一个CPU多核才会发生并行 垃圾回收的并行与并发 并行(Paralle)指多条垃圾收集线程并行工作但此时用户线程仍处于等待状态如ParNew,Paralel Scavenge,Parallel Old串行(Serial)相比较并行的概念单线程执行如果内存不够则程序暂停启动JVM垃圾回收器进行垃圾回收回收完再启动程序的线程并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不一定是并行的可能交替执行)垃圾首先线程在执行时不会停顿用户程序的运行例如CMS,G1 安全点与安全区域 安全点(Safepoint):程序执行时并非在所有地方都能停顿下来开始GC只有在特定的位置才能停顿下来开始GC这些位置成为安全点(Safepoint)Safe Point的选择很重要如果太少可能导致GC等待的时间太长如果太频繁可能导致运行时的性能问题大部分指令的执行时间都非常短暂通常会根据“是否具有让程序长时间”为标准比如选择一些执行时间较长的指令作为Safe Point,如方法调用循环跳转和异常跳转等如何在GC发生时检查所有线程都跑到最近的安全点停顿下来呢抢先式中断(目前没有虚拟机采用)首先中断所有线程如果还有线程不再安全点就恢复线程让线程跑到安全点主动式中断设置一个中断标志各个线程运行到Safe Point的时候主动轮询这个标志如果中断标志为真则将自己进行中断挂起安全区域(Safe Region)Safepoint机制保证了程序执行时在不太长的时间内就会遇到可进入GC的SafePoint。但是程序不执行的时候呢例如线程处于Sleep状态或Blocked状态这时候线程无法响应JVM的中断请求“走”到安全点去中断挂起JVM也不太可能等待线程被唤醒。对于这种情况就需要安全区域(Safe Refion)来解决安全区域是指在一段代码片段中对象的引用的关系不会发生变化在这个区域中的任何位置开始GC都是安全的我们也可以把Safe Region看做是被扩展了的Safe Point实际执行时1.当线程运行到Safe Region的代码时首先标识已经进入了Safe Region,如果这段时间内发生GCJVM会忽略标识为Safe Region状态的线程2.当线程即将离开Safe Region时会检查JVM是否已经完成GC如果完成了则继续运行否则线程必须等待直到收到可以安全离开Safe Region的信号为止 JAVA中集中不同引用 我们希望能描述这一类对象当内存空间还足够时则能保留在内存中如果内存空间在进行垃圾收集后还是很紧张则可以抛弃这些对象JDK1.2版本之后Java对引用的概念进行了扩充将引用分为强引用(Strong Reference)软引用(Soft Reference)弱引用(Weak Reference)虚引用(Phantom Reference)4种这4种引用强度依次逐渐减弱除了强引用外其他3种引用均可以在java.lang.ref包中找到他们的身影如下图显示了3种引用类型对应的类开发人员可以在应用程序中直接使用它们 Reference子类只有终结器引用时包内可见的其他3种引用类型均为pulic,可以在应用程序中直接使用强引用(StrongReference)最传统的引用的定义是指在程序代码之中普遍存在的引用赋值即类似Object obj new Object()这种引用关系无论任何情况下只要强引用关系还存在垃圾收集器就永远不会回收掉被引用的对象软引用(SoftReference)在系统将要发生内存溢出之前将会吧这些对象列入回收范围之中进行第二次回收如果这次回收后还没有足够的内存才会抛出内存溢出异常弱引用(WeakReference)被弱引用关联的对象只能生存到下一次垃圾收集之前当垃圾收集器工作时无论内存空间是否足够都会回收掉被弱引用关联的对象虚引用(PhantomReference)一个对象是否有虚引用的存在完全不会对其生存时间构成影响也无法通过虚引用来获得一个对象的实例为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知 强引用不回收 在Java程序中最常见的引用类型是强引用也就是普通对象引用即默认的引用类型当在Java语言中使用new操作符创建一个新的对象并将其赋值给一个变量的时候这个变量就成为指向该对象的一个强引用强引用的对象是可触及的垃圾收集器就永远不会回收掉被引用的对象对于一个普通的对象如果没有其他的引用关系只要超过了引用的作用域或者显示地将相应强引用赋值为null就是可以当做垃圾被收集了当然具体的回收时机还是地看垃圾收集策略相对的软引用弱引用和虚引用的对象是软可触及的弱可触及的和虚可触及的在一定条件下都是可以被回收的所以强引用时造成Java内存泄露的主要原因之一 特点强引用可以直接访问目标对象强引用所指向的对象在任何时候都不会被系统回收虚拟机宁愿抛出OOM异常也不会回收强引用所指向对象强引用可能导致内存泄露(其他引用不会导致) 软引用(内存不足即回收) 软引用时用来描述一些还有用但非必须的对象只被软引用关联着的对象在系统将要发生内存溢出的异常前会把这些对象列进回收范围之中进行第二次回收如果这次回收还没有足够的内存才会抛出内存异常软引用通常用来实现内存敏感的缓存比如高速缓存就有用到软引用如果还有空闲内存就可以暂时保存缓存当内存不足时清理掉这样就保证了使用缓存的同时不会耗尽内存垃圾回收器在某个时刻决定回收软可达的对象的时候会清理软引用并可选地把引用存放到一个引用队列(Reference Queue)类似弱引用只不过Java虚拟机尽量让软引用的存活时间长一些迫不得已才清理总结当内存足够不会回收软引用的可达对象当内存不够会回收软引用对象 弱引用(一发现即回收) 弱引用也是用来描述哪些非必须对象只被弱引用关联的对象只能生存到下一次垃圾收集发生为止在系统GC时只要发现弱引用不管系统堆空间使用是否充足都会回收掉只被弱引用关联的对象但是由于垃圾回收器的线程通常优先级很低因此并不一定能很快地发现持有弱引用的对象在这种情况下弱引用对象可以存在较长的时间弱引用和软引用一样在构造弱引用时也可以指定一个引用队列当弱引用对象被回收时就会加入指定的引用队列通过这个队列可以跟踪对象的回收情况软引用弱引用都非常适合来保存那些可有可无的缓存数据如果这么做当系统内存不足时这些缓存数据会被回收不会导致内存溢出而到内存资源充足时这些缓存数据又可有存在相当长的时间从而起到加速系统的作用 Entry是weakReference类型的 虚引用(对象回收跟踪) 也称为幽林引用或者幻影引用是所有引用类型中最弱的一个一个对象是否有虚引用的存在完全不会决定对象的生命周期如果一个对象仅持有虚引用那么它和没有引用几乎是一样的随时都可能被垃圾回收他不能单独使用也无法通过虚引用来获取被引用的对象当试图通过虚引用的get()方法取得对象时总是null为一个对象设置虚引用关联的唯一目的在于跟踪垃圾回收的过程比如能在这个对象被收集器回收时收到一个系统通知虚引用必须和引用队列一起使用虚引用在创建时必须提供一个引用队列作为参数当垃圾回收准备回收一个对象时如果发现它还有虚引用就会在回收对象后将这个虚引用加入引用队列以通知应用程序对象的回收情况在JDK1.2版之后提供了PhantomReference类来实现虚引用 终结器引用 FinalReference它用以实现对象的finalize()方法也可以成为终结器引用无需手动编码其内部配合引用队列使用3.在GC时终结器引用入队由Finalizer线程通过终结器引用找到被引用对象并调用它的finalize()方法第二次GC时才能回收被引用对象 垃圾回收器 GC分类与性能指标 按线程数分可以分为串行垃圾回收器和并行垃圾回收器串行回收指的是在同一时间段内只允许有一个CPU用于执行垃圾回收操作此时工作线程被暂停直至垃圾收集工作结束在诸如单CPU处理器或者较小的应用内存等硬件平台不是特别优越的场合串行回收器的性能表现可以超过并行回收器和并发回收器所以串行回收默认被应用在客户端的client模式下的JVM中在并发能力比较强的CPU上并行回收器产生的停顿时间要短于串行回收器和串行回收相反并行收集可以运用多个CPU同时执行垃圾回收因此提升了应用的吞吐量不过并行回收仍然与串行回收一样采用独占式使用Stop-the-world机制按照工作模式分可以分为并发式垃圾回收器和独占式垃圾回收器并发式垃圾回收器与应用程序线程交替工作以尽可能减少引用程序的停顿时间独占式垃圾回收器(Stop the world)一旦运行就停止应用程序中的所有用户线程知道垃圾回收过程完全结束按碎片处理方式分可分为压缩式垃圾回收器和非压缩式垃圾回收器压缩式垃圾回收器会在回收完成后对存活对象进行压缩整理消除回收后的碎片再分配对象空间使用指针碰撞非压缩式的垃圾回收器不进行这步操作再分配对象空间使用空闲列表按工作的内存区间分又可分为年轻代垃圾回收器和老年代垃圾回收器 评估GC的性能指标 吞吐量运行用户代码的时间占总运行时间的比例 总运行时间程序的运行时间内存回收时间 垃圾收集开销吞吐量的补数垃圾收集所用时间与总运行时间的比例暂停时间执行垃圾收集时程序的工作线程被暂停的时间收集频率相对于应用程序的执行收集操作发生的频率内存占用Java堆区所占的内存大小快速一个对象诞生到被回收所经历的时间主要的是吞吐量和暂停时间 吞吐量与暂停时间 吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值即吞吐量运行用户代码时间/(运行用户代码时间垃圾收集时间)暂停时间是指一个时间段内应用程序线程暂停让GC线程执行的状态暂停时间优先意味着尽可能让单次STW的时间最短 高吞吐量较好因为这会让应用程序的最终用户感觉只有应用程序线程在做生产性工作直觉上吞吐量越高程序运行越快低暂停时间(低延迟)较好因为从最终用户的角度来看不管事GC还是其他原因导致一个应用被挂起始终是不好的标准在最大吞吐量优先的情况下降低停顿时间 历史 7款经典收集器与垃圾分代之间的关系 CMS并发收集如果用户线程速度大于垃圾回收速度可会会回收失败需要使用Serial Old GC配合回收(后备方案)两个收集器间有连线表明他们可以搭配使用其中Serial Old作为CMS出现Concurrent Mode Failure失败的后备预案(红色虚线)由于维护和兼容性测试的成本在JDK 8 时将SerialCMSParNewSerial Old这两个组合声明为废弃,并在JDK 9中完全取消了这些组合的支持(绿色虚线)JDK 14中弃用Parallel Scanvenge和SerialOld GC组合(青色虚线)JDK 14中删除CMS垃圾回收器为什么要有很多收集器因为Java的使用场景很多需要针对不同的场景提供不同的垃圾收集器提高垃圾收集的性能 ###如何查看默认的垃圾回收器 -XXPrintCommandLineFlage:查看命令行相关参数(包含使用的垃圾收集器)使用命令行指令jinfo -flag 相关垃圾回收器参数 进程 ID Serial回收器串行回收 Serial收集器是最基本历史最悠久的垃圾收集器了JDK1.3之前回收新生代唯一的选择Serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器Serial收集器采用复制算法串行回收和Stoptheworld机制的方式执行内存回收除了年轻代之外Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。Serial Old收集器同样也采用了串行回收和Stop the World机制只不过内存回收算法使用的是标记-压缩算法Serial Old是运行在Client模式下默认的老年代的垃圾回收器Serial Old在Server模式下主要有两个用途1.与新生代Parallel Scanvenge配合使用2.作为老年代CMS收集器的后备垃圾收集方案 优势简单而高效(与其他收集器的单线程比)对于限定单个CPU的环境来说Serial收集器由于没有线程交互的开销专心做垃圾收集自然可以获得最高的单线程收集效率在用户的桌面应用场景中可用内存一般不大(几十MB至一两百MB)可以在较短时间内完成垃圾收集只要不频繁发送使用串行回收器可以接收在HotSpot虚拟机中使用-XXUseSerialGC参数可以指定年代和老年代都使用串行收集器等价于新生代用Serial GC且老年代用Serial Old GC 了解即可限定单核CPU在使用现在一般都不是单核 ParNew回收器并行回收 如果说Serial GC是年轻代中的单线程垃圾收集器那么ParNew收集器则是Serial收集器的多线程版本ParNew收集器除了采用并行回收的方式执行内存回收外两款垃圾收集器之间几乎没有任何区别ParNew收集器在年轻代中同样也是采用复制算法Stop-the-World机制ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器 由于ParNew收集器是基于并行回收的那么是否可以断定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效ParNew收集器运行在多CPU的环境下由于可以充分利用多CPU多核心等物理硬件资源优势可以更快速地完成垃圾收集提升程序的吞吐量但是在单个CPU的环境下ParNew收集器不比Serial收集器更高效虽然Serial收集器是基于串行回收但是由于CPU不需要频繁地做任务切换因此可以有效避免多线程交互过程中产生的一些额外开销因为除Serial外目前只有ParNew GC能与CMS收集器配合工作在程序中开发人员可以通过选项-XXUseParNewGC 手动指定使用ParNew收集器执行内存回收任务它表示年轻代使用并行收集器不影响老年代-XXParallelGCThreads 限制线程数量默认开启和CPU数据相同的线程数 Parallel回收器吞吐量优先 HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外Parallel Scavenge收集器同样也采用了复制算法并行回收和Stop the World机制那么Parallel收集器的出现是否多此一举和ParNew收集器不同Parallel Scavenge收集器的目标是达到一个可控制的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器自适应调节策略也是Parallel Scavenge与ParNew一个重要区别高吞吐量则可以高效率地利用CPU时间尽快完成程序的运算任务主要适合在后天运算而不需要太多交互(低延迟)的任务因此常见在服务器环境中使用例如批量处理订单处理工资支付等Paralel收集器在JDK1.6时提供了用户执行老年代垃圾收集的Paralel Old收集器用来代替老年代的Serial Old收集器Paralel Old收集器采用了标记-压缩算法但同样也是基于并行回收和Stop-the-World机制在程序吞吐量优先的应用场景中Parallel 收集器和Parallel Old收集器的组合在Server模式下的内存回收性能很不错在Java8中默认是此垃圾收集器参数配置-XXUseParallelGC 手动指定年轻代使用Paralel并行收集器执行内存回收任务-XXUseParalelOldGC 手动指定老年代都是使用并行回收收集器 分别适用于新生代和老年代默认是jdk8是开启的上面两个参数默认开启一个另一个也会被开启(互相激活) -XX:ParalerGCThreads 设置年轻代并行收集器的线程数。一般地最好与CPU数量相等以避免过多的线程数影响垃圾收集性能 在默认情况下当CPU数量小于8个ParallelGCThread的值等于CPU数量当CPU数量大于8个ParalelGCThreads的值等于3{[5*CPU_count]/8} -XXMaxGCPauseMillis 设置垃圾收集器最大停顿时间(即STW的时间单位是毫秒) 为了尽可能地把停顿时间控制在MaxGCPauseMills以内收集器在工作时会调整Java堆大小或者其他一些参数 对于用户来讲停顿时间越短体验越好但是在服务器端我们注重高并发整体的吞吐量所以服务端适合Parallel进行控制 该参数使用需谨慎 -XXGCTimeRatio 垃圾收集时间占总时间的比例(i/(N1))。用于衡量吞吐量的大小取值范围(0,100)默认值99也就是垃圾回收时间不超过1%与前一个-XXMaxGCPauseMillis参数有一定矛盾性暂停时间越长Radio参数就越容易超过设定的比例-XXUseAdaptiveSizePolicy 设置Parallel Scanvenge收集器具有自适应调节策略 在这种模式下年轻代的大小Eden和Survivor的比列晋升老年代的对象年龄等参数会被自动调整已达到在堆大小吞吐量和停顿时间之间的平衡点 在手动调优比较困难的场合可以直接使用这种自适应的方式仅指定虚拟机的最大堆目标的吞吐量(GCTimeRatioo)和停顿时间(MaxGCPauseMills),让虚拟机自己完成调优工作 表示使用-表示不使用 CMS回收器低延迟 在JDK1.5时期HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器CMS(Concurrent-Mark-Sweep)收集器这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器它第一次实现了让垃圾收集线程与用户线程同时工作CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间停顿时间越短(低延迟)就越适合与用户交互的程序良好的响应速度能提高用户体验目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上这类应用尤其重视服务的响应速度希望系统停顿时间最短以给用户带来较好的体验CMS收集器就非常符合这类应用的需求CMS的垃圾收集算法采用标记-清除算法并且也会Stop-the-world不幸的是CMS作为老年代的收集器却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作所以在JDK1.5中使用CMS来收集老年代的时候新生代只能选择ParNew或者Serial收集器中的一个在G1出现之前CMS使用还是非常广泛的 CMS整个过程比之前的收集器要复杂整个过程分为4个主要阶段即初始标记阶段并发标记阶段重新标记阶段和并发清除阶段初始阶段(initial-Mark)阶段在这个阶段中程序中所有的工作线程都将会因为Stop-the-World机制而出现短暂的暂停这个阶段的主要任务仅仅只是标记出GCRoots能直接关联的对象一旦标记完成之后就会恢复之前被暂停的所有应用线程由于直接关联对象比较小所以这里的速度非常快并发标记(Concurrent-Mark)阶段从GC Roots的直接关联对象开始遍历整个对象图的过程这个过程耗时较长但是不需要停顿用户线程可以与垃圾收集线程一起并发运行重新标记(Remark)阶段由于在并发标记阶段中程序的工作线程会和垃圾收集线程同时运行或者交叉运行因此为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录这个阶段的停顿时间通常会比初始标记阶段稍长一些但也远比并发标记阶段的时间短并发清除(Concurrent-Sweep)阶段此阶段清除删除掉标记阶段判断的已经死亡的对象释放内存空间由于不需要移动存活对象所以这个阶段也是可以与用户线程同时并发的尽管CMS收集器采用的是并发回收(非独占式)但是在其初始化标记和再次标记这两个阶段中仍然需要执行Stop-the-World机制暂停程序中的工作线程不过暂停时间并不会太长因此可以说明目前所有的垃圾收集器都做不到完全不需要Stop-the-World,只是尽可能地缩短暂停时间由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作所以整体的回收时低停顿的另外由于在垃圾收集阶段用户线程没有中断所以在CMS回收过程中还应该确保应用程序用户线程有足够的内存可用因CMS收集器不能像其他收集器那样等到老年代机会完全被填满再进行收集而是当堆内存使用率达到某一阈值时便开始进行回收以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行要死CMS“运行期间预留的内存无法满足程序需要就会出现一次Concurrent Mode Failure失败这时虚拟机将启动后备预案临时启用Serial Old收集器来重新进行老年代的垃圾收集这样就停顿时间就很长了CMS收集器的垃圾收集算法采用的是标记-清除算法这意味着每次执行完内存回收后由于被执行的内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块不可避免地将产生一些内存碎片那么CMS在为新对象分配内存空间时将无法使用指针碰撞技术而只能够选择空闲列表执行内存分配为什么不使用Mark-Compact算法因为当并发清除时用Compact整理内存的话原来的用户线程使用的内存没法用要保证用户线程能继续执行前提的它运行的资源不受影响Mark-Compact更适合STW场景使用CMS的优点 低延迟并发收集 缺点 1.会产生内存碎片导致并发清理收用户线程可用的空间不足在无法分配大对象的情况下不得不提前触发Full GC2.CMS收集器对CPU资源非常敏感在并发阶段它虽然不会导致用户停顿但是会因为占用了一部分线程而导致应用程序变慢总吞吐量会降低3.CMS收集器无法处理浮动垃圾可能回车Concurrent Mode Failure失败而导致另一次Full GC的产生在并发标记阶段由于程序的工作线程和垃圾收集线程是同步运行或者交叉运行的那么在并发标记阶段如果产生新的垃圾对象CMS将无法对这些垃圾对象进行标记最终会导致这些新产生的垃圾对象没有被及时回收从而只能在下一次执行GC时释放这些之前未被回收的内存空间 参数设置-XXUseConcMarkSweepGC 手动指定使用CMS收集器执行内存任务开启该参数后会自动将-XXUseParNewGC打开即ParNew(Young区用)CMS(Old区)Serial Old备用-XXCMSlnitiatingOccupanyFraction 设置堆内存使用率的阈值一旦达到阈值便开始进行回收JDK 5及以前版本的默认值是68即当老年代的空间使用率达到68%时会执行一次CMS回收JDK 6及以上版本默认值为92%如果内存增长缓存可以设置一个稍大的值大的阈值可以有效降低CMS的触发频率减少老年代的回收的次数可以较为明细地改善应用程序性能反之如果应用程序内存使用率增长的很快则应该降低这个阈值以避免频繁触发老年代串行收集器因此通过该选项可以有效降低Full GC的执行次数 -XXUseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理以此避免内存碎片的产生不过由于内存压缩整理过程无法并发执行所带来的问题就是停顿时间变得更长了-XXCMSFullGCsBeforeCompaction 设置在执行多少次FullGC后对内存空间进行压缩整理-XX:ParallelCMSThreads 设置CMS的线程数量CMS 默认启动的线程数是(ParallelGCThreads 3)/4ParallelGCThreads是年轻代并行收集器的线程数当CPU资源比较紧张时收到CMS收集器线程的影响应用程序的性能垃圾回收阶段可能会非常糟糕 总结 想要最小化使用内存和并行开销Serial GC想要最大化应用程序的吞吐量Paralel GC最小化GC的中断或挺短时间CMS GCJDK 9时CMS被标记为Deprecate如果JDK9及以上版本虚拟机使用参数 -XXUseConcMarkSweepGC来开启CMS收集器时会受到警告信息JDK14删除了CMS垃圾收集器如果在JDK 14中使用-XXUseConcMarkSweepGC来开启CMS收集器JVM不会报错只是给出一个warning信息但是不会exit,JVM会自动回退以默认GC方式启动JVM G1回收器区域化分代式 Garbage First(G1)延迟可控的情况下获得尽可能高的吞吐量G1是一个并行回收器它把堆内存分割为很多不相关的区域(Region)(物理上不连续的)使用不同的Region来表示Eden,幸存者0区幸存者1区老年代等G1 GC有计划的避免在整个Java堆中进行全区域的垃圾收集G1跟踪各个Region里面的垃圾堆积的价值的大小(回收所获得的空间大小以及回收所需时间的经验值)在后台维护一个优先列表每次根据运行的收集时间优先回收价值最大的Region由于这种方式的侧重点在于回收垃圾最大量的区间(Region),所以我们给G1一个名字垃圾优先(Garbage First)G1是一款面向服务端应用的垃圾收集器主要针对配备多核CPU及大容量内存的机器以极高概率满足GC停顿时间的同时还兼具高吞吐量的性能特征在JDK1.7版本正式启用移除了Experimental的标识是JDK 9以后默认垃圾回收器取代了CMS回收器以及ParallelParallel Old组合。被Oracle官方称为全功能的垃圾收集器与此同时CMS已经在JDK9 中被标记为废弃(deprecated),在JDK 8中还不是默认的垃圾回收器需要使用-XXUseG1GC来启用 G1垃圾回收器的优势与不足 与其他GC收集器相比G1使用了全新的分区算法其特点如下所示并行与并发并行性G1在回收期间可以有多个GC线程同时工作有效利用多核计算能力此时用户线程STW并发性G1拥有与应用程序交替执行的能力部分工作可以和应用程序同时执行因此一般来说不会在整个回收阶段发生完全阻塞应用程序的情况分代收集从分代上看G1依然属于分代垃圾回收器它会分区年轻代和老年代年轻代依然有Eden区和Survivor区但从堆的结构上看它不要求整个Eden区年轻代或者老年代都是连续的也不再坚持固定大小和固定数量将堆空间分为若干个区域(Region)这些区域中包含了逻辑上的年轻代和老年代和之前的各类回收器不同它同时兼顾年轻代和老年代对比其他回收器或者工作在年轻代或者工作在老年代 空间整合CMS标记-清除算法内存碎片。若干次GC后进行一次碎片整理G1将内存划分为一个个的region,内存的回收时以region作为基本单位的。Region之间是复制算法但整体上实际可以看作是标记-压缩(Mark-Compact)算法两种算法都可以避免内存碎片这种特性有利于程序长时间运行分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC尤其是当Java堆非常大的时候G1的优势更加明细可预测的停顿时间模型(即软实时soft real-time)这是G1相对于CMS的另一大优势G1除了追求低停顿外还能建立可预测的停顿时间模型能让使用者明确指定在一个长度为M毫秒的时间片段内消耗在垃圾收集上的时间不得超过N毫秒由于分区的原因G1可以只选取部分区域进行内存回收这样缩小了回收的范围因此对于全局停顿情况的发生也能得到较好的控制G1跟踪各个Region里面的垃圾堆积的价值的大小(回收所获得的空间大小以及回收所需时间的经验值)在后台维护一个优先列表每次根据允许的收集时间优先回收价值最大的Region保证了G1收集器在有限2的时间内可以获取尽可能高的收集效率相比于CMS GC,G1未必能做到CMS在最好情况下的延时停顿但是最差情况要好很多缺点相比较于CMSG1还不具备全方位压倒性优势比如在用户程序运行过程中G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(OverLoad)都要比CMS要高从经验上来说在小内存应用上CMS的表现大概率会由于G1,而G1在大内存应用上则发挥其优势平衡点在6-8GB之间 G1的参数设置 -XXUseG1GC 手动指定使用G1收集器执行内存回收任务-XXG1HeapRegionSize 设置每个Region的大小。值是2的幂范围是1MB到32MB之间目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000-XXMaxGCPauseMillis 设置期望达到的最大GC停顿时间指标(JVM会尽力实现但不保证达到)默认值是200ms-XXParallelGCThread 设置STW时GC线程数的值。最多设置为8-XXConcGCThreads 设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParalelGCThreads)的1/4左右-XXInitiatingHeapOccupancyPercent 设置触发并发GC周期的Java堆占用率阈值。超过此值就触发GC默认值是45G1的设计原则就是简化JVM性能调优开发人员只需要简单的三步即可完成调优第一步开启G1垃圾收集器第二步设置堆的最大内存第三步设置最大的停顿时间G1中提供了三种垃圾回收模式YoungGC,Mixed GC 和Full GC,在不同的条件被触发 G1回收器的适用场景 面向服务端的应用针对具有大内存多处理器的机器(在普通大小的堆里表现并不突出)最主要的应用是需要低GC延迟并具有大堆的应用程序提供解决方案如在堆大小约6GB或更大时可预测的暂停时间可低于0.5秒(G1通过每次只清理一部分而不是全部的Region的增量式清理来保证每次GC停顿的时间不会过长)用来替换掉JDK1.5中的CMS收集器以下情况使用G1可能比CMS好1.超过50%的Java堆被活动数据占用2.对象分配频率或年代提示频率变化很大3.GC停顿时间过长(长于0.5至1秒)HotSpot垃圾收集器里。除了G1以外其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作而G1 GC可以采用应用线程承担后台的GC工作即当JVM的GC线程处理速度慢系统会调用应用程序线程帮助加速垃圾回收过程。 region的适用介绍 分区Region化整为零使用G1收集器时它将整个Java堆划分为约2048个大小相同的独立Region块每个Region块根据堆空间的实际大小而定整体被控制在1MB到32MB之间且为2的N次幂即1MB2MB4MB8MB16MB32MB可以通过-XXG1HeapRegionSize设定。所有的Region大小相同且在JVM生命周期内不会被改变虽然还保留有新生代和老年代的概念但新生代和老年代不再是物理隔离的了它们都是一部分Region(不需要连续)的集合通过Region的动态分配方式实现逻辑上的连续 一个Region有可能属于EdenSurvivor或者Old/Tenured 内存区域。但是一个region只可能属于一个角色。图中的E表示该region属于Eden内存区域s表示属于Survivor内存区域o表示属于Old内存区域图中空白表示未使用的内存空间G1垃圾收集器还增加了一种新的内存区域叫做Humongous内存区域如图中的H块主要用于存储大对象如果超过1.5个region就放到H设置H的原因对于堆中的大对象默认直接会被分配到老年代但是如果它是一个短期存在的大对象就会对垃圾收集器造成负面影响为了解决这个问题G1划分了一个Humongous区它用来专门存放大对象。如果一个H区装不下一个大对象那么G1会寻找连续的H区来存储为了能找到连续的H区有时候不得不启动Full GCG1的大多数行为都把H区作为老年代的一部分来看待 G1垃圾回收器的主要回收环节 G1 GC的垃圾回收过程主要包括如下三个环节年轻代(Young GC)老年代并发标记过程(Concurrent Marking)混合回收(Mixed GC)(如果需要单线程独占式高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制即强力回收) 顺时针young gc - young gc concurrent mark -Mixed GC顺序进行垃圾回收应用程序分配内存当年轻代的Eden区用尽时开始年轻代回收过程G1年轻代收集阶段是一个并行的独占式收集器。在年轻代回收期G1 GC暂停所有应用程序线程启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到Surivivor区间或者老年区间也有可能是两个区间都会涉及当堆内存使用达到一定值(默认45%)时开始老年代并发标记过程标记完成马上开始混合回收过程对于一个混合回收期G1 GC从老年代区间移动存活对象到空闲区间这些空闲区间也就成为了老年代的一部分。和年轻代不同老年代的G1回收器和其他GC不同G1的老年代回收期不需要整个老年代被回收一次只需要扫描/回收一小部分老年代的Region就可以了。同时这个老年代Region是和年轻代一起被回收的举个例子一个Web服务器Java进程最大堆内存为4G每分钟响应1500个请求每45秒钟会新分配大约2G的内存G1会每45秒钟进行一次年轻代回收每31个小时整个堆的使用率会达到45%会开始老年代并发标记过程标记完成后开始四到五次的混合回收 记忆集与写屏障 Remembered Set 记忆集一个对象被不同区域引用的问题一个Region不可能是孤立的一个Region中的对象可能被其他任意Region中对象引用判断对象存活时是否需要扫描整个Java堆才能保存准确在其其得分代收集器也存在这样的问题(G1更突出)回收新生代也不得不同时扫描老年代这样的话会降低Minor GC的效率解决方法无论G1还是其他分代收集器JVM都是使用Remembered Set来避免全局扫描每个Region都有一个对应的Remembered Set每次Reference类型数据写操作时都会产生一个Write Brrier暂时中断操作然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的Region(其他收集器检查老年代对象是否引用了新生代对象)如果不同通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中当进行垃圾收集时在GC根节点的枚举范围加入Remembered Set就可以保证不进行全局扫描也不会有遗漏G1比其他垃圾回收器多占用10%到20%的空间用于记忆集 G1垃圾回收过程的详细说明 G1垃圾回收的优化建议 垃圾回收器总结 GC日志分析 垃圾回收器的新发展 附录
1.字节码文件反编译内容
// 字节码文件反编译
F:\git\myself\firefish-mall\firefish-game\target\classes\com\wd\chatroom\clientjavap -v ChatClient.class
Classfile /F:/git/myself/firefish-mall/firefish-game/target/classes/com/wd/chatroom/client/ChatClient.classLast modified 2024-5-10; size 1850 bytesMD5 checksum 86e83c0304e366ab162244f345048b70Compiled from ChatClient.java
public class com.wd.chatroom.client.ChatClientminor version: 0major version: 52flags: ACC_PUBLIC, ACC_SUPER
Constant pool:#1 Methodref #29.#63 // java/lang/Object.init:()V#2 Class #64 // java/net/Socket#3 Class #65 // com/wd/chatroom/client/ChatClient#4 String #66 // 127.0.0.1#5 Methodref #2.#67 // java/net/Socket.init:(Ljava/lang/String;I)V#6 Class #68 // java/io/BufferedReader#7 Class #69 // java/io/InputStreamReader#8 Methodref #2.#70 // java/net/Socket.getInputStream:()Ljava/io/InputStream;#9 Methodref #7.#71 // java/io/InputStreamReader.init:(Ljava/io/InputStream;)V#10 Methodref #6.#72 // java/io/BufferedReader.init:(Ljava/io/Reader;)V#11 Class #73 // java/io/PrintWriter#12 Methodref #2.#74 // java/net/Socket.getOutputStream:()Ljava/io/OutputStream;#13 Methodref #11.#75 // java/io/PrintWriter.init:(Ljava/io/OutputStream;Z)V#14 Fieldref #76.#77 // java/lang/System.in:Ljava/io/InputStream;#15 Fieldref #76.#78 // java/lang/System.out:Ljava/io/PrintStream;#16 String #79 // #17 Methodref #80.#81 // java/io/PrintStream.println:(Ljava/lang/String;)V#18 Methodref #6.#82 // java/io/BufferedReader.readLine:()Ljava/lang/String;#19 String #83 // quit#20 Methodref #58.#84 // java/lang/String.equals:(Ljava/lang/Object;)Z#21 Methodref #11.#81 // java/io/PrintWriter.println:(Ljava/lang/String;)V#22 Class #85 // java/lang/StringBuilder#23 Methodref #22.#63 // java/lang/StringBuilder.init:()V#24 String #86 // Server:#25 Methodref #22.#87 // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;#26 Methodref #22.#88 // java/lang/StringBuilder.toString:()Ljava/lang/String;#27 Methodref #2.#89 // java/net/Socket.close:()V#28 Methodref #76.#90 // java/lang/System.exit:(I)V#29 Class #91 // java/lang/Object#30 Utf8 SERVER_IP#31 Utf8 Ljava/lang/String;#32 Utf8 ConstantValue#33 Utf8 SERVER_PORT#34 Utf8 I#35 Integer 1234#36 Utf8 init#37 Utf8 ()V#38 Utf8 Code#39 Utf8 LineNumberTable#40 Utf8 LocalVariableTable#41 Utf8 this#42 Utf8 Lcom/wd/chatroom/client/ChatClient;#43 Utf8 main#44 Utf8 ([Ljava/lang/String;)V#45 Utf8 line#46 Utf8 response#47 Utf8 args#48 Utf8 [Ljava/lang/String;#49 Utf8 socket#50 Utf8 Ljava/net/Socket;#51 Utf8 input#52 Utf8 Ljava/io/BufferedReader;#53 Utf8 out#54 Utf8 Ljava/io/PrintWriter;#55 Utf8 keyboard#56 Utf8 StackMapTable#57 Class #48 // [Ljava/lang/String;#58 Class #92 // java/lang/String#59 Utf8 Exceptions#60 Class #93 // java/io/IOException#61 Utf8 SourceFile#62 Utf8 ChatClient.java#63 NameAndType #36:#37 // init:()V#64 Utf8 java/net/Socket#65 Utf8 com/wd/chatroom/client/ChatClient#66 Utf8 127.0.0.1#67 NameAndType #36:#94 // init:(Ljava/lang/String;I)V#68 Utf8 java/io/BufferedReader#69 Utf8 java/io/InputStreamReader#70 NameAndType #95:#96 // getInputStream:()Ljava/io/InputStream;#71 NameAndType #36:#97 // init:(Ljava/io/InputStream;)V#72 NameAndType #36:#98 // init:(Ljava/io/Reader;)V#73 Utf8 java/io/PrintWriter#74 NameAndType #99:#100 // getOutputStream:()Ljava/io/OutputStream;#75 NameAndType #36:#101 // init:(Ljava/io/OutputStream;Z)V#76 Class #102 // java/lang/System#77 NameAndType #103:#104 // in:Ljava/io/InputStream;#78 NameAndType #53:#105 // out:Ljava/io/PrintStream;#79 Utf8 #80 Class #106 // java/io/PrintStream#81 NameAndType #107:#108 // println:(Ljava/lang/String;)V#82 NameAndType #109:#110 // readLine:()Ljava/lang/String;#83 Utf8 quit#84 NameAndType #111:#112 // equals:(Ljava/lang/Object;)Z#85 Utf8 java/lang/StringBuilder#86 Utf8 Server:#87 NameAndType #113:#114 // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;#88 NameAndType #115:#110 // toString:()Ljava/lang/String;#89 NameAndType #116:#37 // close:()V#90 NameAndType #117:#118 // exit:(I)V#91 Utf8 java/lang/Object#92 Utf8 java/lang/String#93 Utf8 java/io/IOException#94 Utf8 (Ljava/lang/String;I)V#95 Utf8 getInputStream#96 Utf8 ()Ljava/io/InputStream;#97 Utf8 (Ljava/io/InputStream;)V#98 Utf8 (Ljava/io/Reader;)V#99 Utf8 getOutputStream#100 Utf8 ()Ljava/io/OutputStream;#101 Utf8 (Ljava/io/OutputStream;Z)V#102 Utf8 java/lang/System#103 Utf8 in#104 Utf8 Ljava/io/InputStream;#105 Utf8 Ljava/io/PrintStream;#106 Utf8 java/io/PrintStream#107 Utf8 println#108 Utf8 (Ljava/lang/String;)V#109 Utf8 readLine#110 Utf8 ()Ljava/lang/String;#111 Utf8 equals#112 Utf8 (Ljava/lang/Object;)Z#113 Utf8 append#114 Utf8 (Ljava/lang/String;)Ljava/lang/StringBuilder;#115 Utf8 toString#116 Utf8 close#117 Utf8 exit#118 Utf8 (I)V
{public com.wd.chatroom.client.ChatClient();descriptor: ()Vflags: ACC_PUBLICCode:stack1, locals1, args_size10: aload_01: invokespecial #1 // Method java/lang/Object.init:()V4: returnLineNumberTable:line 6: 0LocalVariableTable:Start Length Slot Name Signature0 5 0 this Lcom/wd/chatroom/client/ChatClient;public static void main(java.lang.String[]) throws java.io.IOException;descriptor: ([Ljava/lang/String;)Vflags: ACC_PUBLIC, ACC_STATICCode:stack5, locals7, args_size10: new #2 // class java/net/Socket3: dup4: ldc #4 // String 127.0.0.16: sipush 12349: invokespecial #5 // Method java/net/Socket.init:(Ljava/lang/String;I)V12: astore_113: new #6 // class java/io/BufferedReader16: dup17: new #7 // class java/io/InputStreamReader20: dup21: aload_122: invokevirtual #8 // Method java/net/Socket.getInputStream:()Ljava/io/InputStream;25: invokespecial #9 // Method java/io/InputStreamReader.init:(Ljava/io/InputStream;)V28: invokespecial #10 // Method java/io/BufferedReader.init:(Ljava/io/Reader;)V31: astore_232: new #11 // class java/io/PrintWriter35: dup36: aload_137: invokevirtual #12 // Method java/net/Socket.getOutputStream:()Ljava/io/OutputStream;40: iconst_141: invokespecial #13 // Method java/io/PrintWriter.init:(Ljava/io/OutputStream;Z)V44: astore_345: new #6 // class java/io/BufferedReader48: dup49: new #7 // class java/io/InputStreamReader52: dup53: getstatic #14 // Field java/lang/System.in:Ljava/io/InputStream;56: invokespecial #9 // Method java/io/InputStreamReader.init:(Ljava/io/InputStream;)V59: invokespecial #10 // Method java/io/BufferedReader.init:(Ljava/io/Reader;)V62: astore 464: getstatic #15 // Field java/lang/System.out:Ljava/io/PrintStream;67: ldc #16 // String 69: invokevirtual #17 // Method java/io/PrintStream.println:(Ljava/lang/String;)V72: aload 474: invokevirtual #18 // Method java/io/BufferedReader.readLine:()Ljava/lang/String;77: astore 579: aload 581: ldc #19 // String quit83: invokevirtual #20 // Method java/lang/String.equals:(Ljava/lang/Object;)Z86: ifeq 9289: goto 13392: aload_393: aload 595: invokevirtual #21 // Method java/io/PrintWriter.println:(Ljava/lang/String;)V98: aload_299: invokevirtual #18 // Method java/io/BufferedReader.readLine:()Ljava/lang/String;102: astore 6104: getstatic #15 // Field java/lang/System.out:Ljava/io/PrintStream;107: new #22 // class java/lang/StringBuilder110: dup111: invokespecial #23 // Method java/lang/StringBuilder.init:()V114: ldc #24 // String Server:116: invokevirtual #25 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;119: aload 6121: invokevirtual #25 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;124: invokevirtual #26 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;127: invokevirtual #17 // Method java/io/PrintStream.println:(Ljava/lang/String;)V130: goto 64133: aload_1134: invokevirtual #27 // Method java/net/Socket.close:()V137: iconst_0138: invokestatic #28 // Method java/lang/System.exit:(I)V141: returnLineNumberTable:line 11: 0line 12: 13line 13: 32line 14: 45line 17: 64line 18: 72line 19: 79line 20: 92line 21: 98line 22: 104line 23: 130line 25: 133line 26: 137line 27: 141LocalVariableTable:Start Length Slot Name Signature79 51 5 line Ljava/lang/String;104 26 6 response Ljava/lang/String;0 142 0 args [Ljava/lang/String;13 129 1 socket Ljava/net/Socket;32 110 2 input Ljava/io/BufferedReader;45 97 3 out Ljava/io/PrintWriter;64 78 4 keyboard Ljava/io/BufferedReader;StackMapTable: number_of_entries 3frame_type 255 /* full_frame */offset_delta 64locals [ class [Ljava/lang/String;, class java/net/Socket, class java/io/BufferedReader, class java/io/PrintWriter, class java/io/BufferedReader ]stack []frame_type 252 /* append */offset_delta 27locals [ class java/lang/String ]frame_type 250 /* chop */offset_delta 40Exceptions:throws java.io.IOException
}
SourceFile: ChatClient.java 2.常用调优工具 1.JDK命令行 1.jsp2.jinfo3.jstat4.javap5.jmap 2.EclipseMemory Analyzer Tool3.Jconsole4.VisualVM5.Jprofiler6.Java Flight RecorderJMC7.GCViewer8.GC Easy 1.javap 1.作用反汇编一个或多个类文件参考地址 // 多个类文件之间用逗号分割
javap [选项] classfile...
javap [选项] classfile... 指定文件路径 文章转载自： http://www.morning.szzxqc.com.gov.cn.szzxqc.com http://www.morning.jpjpb.cn.gov.cn.jpjpb.cn http://www.morning.jrkzk.cn.gov.cn.jrkzk.cn http://www.morning.hfbtt.cn.gov.cn.hfbtt.cn http://www.morning.rbcw.cn.gov.cn.rbcw.cn http://www.morning.drspc.cn.gov.cn.drspc.cn http://www.morning.nktgj.cn.gov.cn.nktgj.cn http://www.morning.rcntx.cn.gov.cn.rcntx.cn http://www.morning.wzyfk.cn.gov.cn.wzyfk.cn http://www.morning.zmbzl.cn.gov.cn.zmbzl.cn http://www.morning.gqflj.cn.gov.cn.gqflj.cn http://www.morning.rhpgk.cn.gov.cn.rhpgk.cn http://www.morning.qtltg.cn.gov.cn.qtltg.cn http://www.morning.rmyt.cn.gov.cn.rmyt.cn http://www.morning.mjats.com.gov.cn.mjats.com http://www.morning.tqbw.cn.gov.cn.tqbw.cn http://www.morning.zlnf.cn.gov.cn.zlnf.cn http://www.morning.ltkms.cn.gov.cn.ltkms.cn http://www.morning.xcdph.cn.gov.cn.xcdph.cn http://www.morning.nqmhf.cn.gov.cn.nqmhf.cn http://www.morning.snnb.cn.gov.cn.snnb.cn http://www.morning.gyfhk.cn.gov.cn.gyfhk.cn http://www.morning.shxrn.cn.gov.cn.shxrn.cn http://www.morning.jgnst.cn.gov.cn.jgnst.cn http://www.morning.frnjm.cn.gov.cn.frnjm.cn http://www.morning.ldqrd.cn.gov.cn.ldqrd.cn http://www.morning.dzdtj.cn.gov.cn.dzdtj.cn http://www.morning.pjtnk.cn.gov.cn.pjtnk.cn http://www.morning.pznhn.cn.gov.cn.pznhn.cn http://www.morning.zsyrk.cn.gov.cn.zsyrk.cn http://www.morning.wjhpg.cn.gov.cn.wjhpg.cn http://www.morning.nmrtb.cn.gov.cn.nmrtb.cn http://www.morning.rkjb.cn.gov.cn.rkjb.cn http://www.morning.kfwqd.cn.gov.cn.kfwqd.cn http://www.morning.zyrp.cn.gov.cn.zyrp.cn http://www.morning.dmjhp.cn.gov.cn.dmjhp.cn http://www.morning.wmhqd.cn.gov.cn.wmhqd.cn http://www.morning.xtrnx.cn.gov.cn.xtrnx.cn http://www.morning.bpzw.cn.gov.cn.bpzw.cn http://www.morning.bpp999.com.gov.cn.bpp999.com http://www.morning.tnbas.com.gov.cn.tnbas.com http://www.morning.ckctj.cn.gov.cn.ckctj.cn http://www.morning.bwznl.cn.gov.cn.bwznl.cn http://www.morning.ksjmt.cn.gov.cn.ksjmt.cn http://www.morning.ngcsh.cn.gov.cn.ngcsh.cn http://www.morning.kxbry.cn.gov.cn.kxbry.cn http://www.morning.lmnbp.cn.gov.cn.lmnbp.cn http://www.morning.xesrd.com.gov.cn.xesrd.com http://www.morning.fewhope.com.gov.cn.fewhope.com http://www.morning.yjtnc.cn.gov.cn.yjtnc.cn http://www.morning.bsxws.cn.gov.cn.bsxws.cn http://www.morning.gtqws.cn.gov.cn.gtqws.cn http://www.morning.bhpsz.cn.gov.cn.bhpsz.cn http://www.morning.pggkr.cn.gov.cn.pggkr.cn http://www.morning.jyfrz.cn.gov.cn.jyfrz.cn http://www.morning.bmgdl.cn.gov.cn.bmgdl.cn http://www.morning.xknsn.cn.gov.cn.xknsn.cn http://www.morning.rcyrm.cn.gov.cn.rcyrm.cn http://www.morning.geledi.com.gov.cn.geledi.com http://www.morning.huihuangwh.cn.gov.cn.huihuangwh.cn http://www.morning.khfk.cn.gov.cn.khfk.cn http://www.morning.smpb.cn.gov.cn.smpb.cn http://www.morning.mzskr.cn.gov.cn.mzskr.cn http://www.morning.trrhj.cn.gov.cn.trrhj.cn http://www.morning.banzou2034.cn.gov.cn.banzou2034.cn http://www.morning.xctdn.cn.gov.cn.xctdn.cn http://www.morning.rjrz.cn.gov.cn.rjrz.cn http://www.morning.mmzfl.cn.gov.cn.mmzfl.cn http://www.morning.fprll.cn.gov.cn.fprll.cn http://www.morning.nbnpb.cn.gov.cn.nbnpb.cn http://www.morning.fbjnr.cn.gov.cn.fbjnr.cn http://www.morning.ghpld.cn.gov.cn.ghpld.cn http://www.morning.rsxw.cn.gov.cn.rsxw.cn http://www.morning.xtdms.com.gov.cn.xtdms.com http://www.morning.kxrld.cn.gov.cn.kxrld.cn http://www.morning.dbsch.cn.gov.cn.dbsch.cn http://www.morning.bwkhp.cn.gov.cn.bwkhp.cn http://www.morning.hrpbq.cn.gov.cn.hrpbq.cn http://www.morning.dhckp.cn.gov.cn.dhckp.cn http://www.morning.jpgfx.cn.gov.cn.jpgfx.cn
