住房和城乡规划建设局网站,深圳网页制作培训,资深网站,流线型的网站建设垃圾收集器浅析 主 JVM参数 3.1.1 标准参数 -version -help -server -cp3.1.2 -X参数 非标准参数#xff0c;也就是在JDK各个版本中可能会变动 -Xint 解释执行 -Xcomp 第一次使用就编译成本地代码 -Xmixed 混合模式#xff0c;JVM自己来决定3.1.3 -XX参数 使用得…垃圾收集器浅析 主 JVM参数 3.1.1 标准参数 -version -help -server -cp3.1.2 -X参数 非标准参数也就是在JDK各个版本中可能会变动 -Xint 解释执行 -Xcomp 第一次使用就编译成本地代码 -Xmixed 混合模式JVM自己来决定3.1.3 -XX参数 使用得最多的参数类型 非标准化参数相对不稳定主要用于JVM调优和Debug a.Boolean类型 格式-XX:[-]name 或-表示启用或者禁用name属性 比如-XX:UseConcMarkSweepGC 表示启用CMS类型的垃圾回收器-XX:UseG1GC 表示启用G1类型的垃圾回收器 b.非Boolean类型 格式-XXnamevalue表示name属性的值是value 比如-XX:MaxGCPauseMillis5003.1.4 其他参数 -Xms1000M等价于-XX:InitialHeapSize1000M -Xmx1000M等价于-XX:MaxHeapSize1000M -Xss100等价于-XX:ThreadStackSize100所以这块也相当于是-XX类型的参数 3.1.5 查看参数 java -XX:PrintFlagsFinal -version flags.txt ] 值得注意的是“表示默认值”:表示被用户或JVM修改后的值 要想查看某个进程具体参数的值可以使用jinfo这块后面聊 一般要设置参数可以先查看一下当前参数是什么然后进行修改 3.1.6 设置参数的常见方式 开发工具中设置比如IDEAeclipse运行jar包的时候:java -XX:UseG1GC xxx.jarweb容器比如tomcat可以在脚本中的进行设置通过jinfo实时调整某个java进程的参数(参数只有被标记为manageable的flags可以被实时修改) 3.1.7 实践和单位换算 1Byte(字节)8bit(位) 1KB1024Byte(字节) 1MB1024KB 1GB1024MB 1TB1024GB(1)设置堆内存大小和参数打印 -Xmx100M -Xms100M -XX:PrintFlagsFinal (2)查询PrintFlagsFinal的值 :true (3)查询堆内存大小MaxHeapSize : 104857600 (4)换算 104857600(Byte)/1024102400(KB) 102400(KB)/1024100(MB) (5)结论 104857600是字节单位3.1.8 常用参数含义 参数含义说明-XX:CICompilerCount3最大并行编译数如果设置大于1虽然编译速度会提高但是同样影响系统稳定性会增加JVM崩溃的可能-XX:InitialHeapSize100M初始化堆大小简写-Xms100M-XX:MaxHeapSize100M最大堆大小简写-Xms100M-XX:NewSize20M设置年轻代的大小-XX:MaxNewSize50M年轻代最大大小-XX:OldSize50M设置老年代大小-XX:MetaspaceSize50M设置方法区大小-XX:MaxMetaspaceSize50M方法区最大大小-XX:UseParallelGC使用UseParallelGC新生代吞吐量优先-XX:UseParallelOldGC使用UseParallelOldGC老年代吞吐量优先-XX:UseConcMarkSweepGC使用CMS老年代停顿时间优先-XX:UseG1GC使用G1GC新生代老年代停顿时间优先-XX:NewRatio新老生代的比值比如-XX:Ratio4则表示新生代:老年代1:4也就是新生代占整个堆内存的1/5-XX:SurvivorRatio两个S区和Eden区的比值比如-XX:SurvivorRatio8也就是(S0S1):Eden2:8也就是一个S占整个新生代的1/10-XX:HeapDumpOnOutOfMemoryError启动堆内存溢出打印当JVM堆内存发生溢出时也就是OOM自动生成dump文件-XX:HeapDumpPathheap.hprof指定堆内存溢出打印目录表示在当前目录生成一个heap.hprof文件-XX:PrintGCDetails -XX:PrintGCTimeStamps -XX:PrintGCDateStamps -Xloggc:g1-gc.log打印出GC日志可以使用不同的垃圾收集器对比查看GC情况-Xss128k设置每个线程的堆栈大小经验值是3000-5000最佳-XX:MaxTenuringThreshold6提升年老代的最大临界值默认值为 15-XX:InitiatingHeapOccupancyPercent启动并发GC周期时堆内存使用占比G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示”一直执行GC循环”. 默认值为 45.-XX:G1HeapWastePercent允许的浪费堆空间的占比默认是10%如果并发标记可回收的空间小于10%,则不会触发MixedGC。-XX:MaxGCPauseMillis200msG1最大停顿时间暂停时间不能太小太小的话就会导致出现G1跟不上垃圾产生的速度。最终退化成Full GC。所以对这个参数的调优是一个持续的过程逐步调整到最佳状态。-XX:ConcGCThreadsn并发垃圾收集器使用的线程数量默认值随JVM运行的平台不同而不同-XX:G1MixedGCLiveThresholdPercent65混合垃圾回收周期中要包括的旧区域设置占用率阈值默认占用率为 65%-XX:G1MixedGCCountTarget8设置标记周期完成后对存活数据上限为 G1MixedGCLIveThresholdPercent 的旧区域执行混合垃圾回收的目标次数默认8次混合垃圾回收混合回收的目标是要控制在此目标次数以内-XX:G1OldCSetRegionThresholdPercent1描述Mixed GC时Old Region被加入到CSet中默认情况下G1只把10%的Old Region加入到CSet中 垃圾收集器 如果说收集算法是内存回收的方法论那么垃圾收集器就是内存回收的具体实现。 2.5.5.1 Serial Serial收集器是最基本、发展历史最悠久的收集器曾经在JDK1.3.1之前是虚拟机新生代收集的唯一选择。 它是一种单线程收集器不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作更重要的是其在进行垃圾收集的时候需要暂停其他线程。 优点简单高效拥有很高的单线程收集效率 缺点收集过程需要暂停所有线程 算法复制算法 适用范围新生代 应用Client模式下的默认新生代收集器2.5.5.2 Serial Old Serial Old收集器是Serial收集器的老年代版本也是一个单线程收集器不同的是采用标记-整理算法运行过程和Serial收集器一样。 2.5.5.3 ParNew 可以把这个收集器理解为Serial收集器的多线程版本。 优点在多CPU时比Serial效率高。 缺点收集过程暂停所有应用程序线程单CPU时比Serial效率差。 算法复制算法 适用范围新生代 应用运行在Server模式下的虚拟机中首选的新生代收集器2.5.5.4 Parallel Scavenge Parallel Scavenge收集器是一个新生代收集器它也是使用复制算法的收集器又是并行的多线程收集器看上去和ParNew一样但是Parallel Scanvenge更关注系统的吞吐量。 吞吐量运行用户代码的时间/(运行用户代码的时间垃圾收集时间) 比如虚拟机总共运行了100分钟垃圾收集时间用了1分钟吞吐量(100-1)/10099%。 若吞吐量越大意味着垃圾收集的时间越短则用户代码可以充分利用CPU资源尽快完成程序的运算任务。 -XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间 -XX:GCRatio直接设置吞吐量的大小。2.5.5.5 Parallel Old Parallel Old收集器是Parallel Scavenge收集器的老年代版本使用多线程和标记-整理算法进行垃圾回收也是更加关注系统的吞吐量。 2.5.4.6 CMS 官网 https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间为目标的收集器。 采用的是标记-清除算法,整个过程分为4步 (1)初始标记 CMS initial mark 标记GC Roots直接关联对象不用Tracing速度很快 (2)并发标记 CMS concurrent mark 进行GC Roots Tracing (3)重新标记 CMS remark 修改并发标记因用户程序变动的内容 (4)并发清除 CMS concurrent sweep 清除不可达对象回收空间同时有新垃圾产生留着下次清理称为浮动垃圾由于整个过程中并发标记和并发清除收集器线程可以与用户线程一起工作所以总体上来说CMS收集器的内存回收过程是与用户线程一起并发地执行的。 优点并发收集、低停顿 缺点产生大量空间碎片、并发阶段会降低吞吐量2.5.5.7 G1(Garbage-First) 官网 https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection 使用G1收集器时Java堆的内存布局与就与其他收集器有很大差别它将整个Java堆划分为多个大小相等的独立区域Region虽然还保留有新生代和老年代的概念但新生代和老年代不再是物理隔离的了它们都是一部分Region不需要连续的集合。 每个Region大小都是一样的可以是1M到32M之间的数值但是必须保证是2的n次幂 如果对象太大一个Region放不下[超过Region大小的50%]那么就会直接放到H中 设置Region大小-XX:G1HeapRegionSizeM 所谓Garbage-Frist其实就是优先回收垃圾最多的Region区域 1分代收集仍然保留了分代的概念 2空间整合整体上属于“标记-整理”算法不会导致空间碎片 3可预测的停顿比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内消耗在垃圾收集上的时间不得超过N毫秒工作过程可以分为如下几步 初始标记Initial Marking 标记以下GC Roots能够关联的对象并且修改TAMS的值需要暂停用户线程 并发标记Concurrent Marking 从GC Roots进行可达性分析找出存活的对象与用户线程并发执行 最终标记Final Marking 修正在并发标记阶段因为用户程序的并发执行导致变动的数据需暂停用户线程 筛选回收Live Data Counting and Evacuation 对各个Region的回收价值和成本进行排序根据用户所期望的GC停顿时间制定回收计划[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-d0TpyGXY-1690955841044)(images/36.png)] 2.5.5.8 ZGC 官网 https://docs.oracle.com/en/java/javase/11/gctuning/z-garbage-collector1.html#GUID-A5A42691-095E-47BA-B6DC-FB4E5FAA43D0 JDK11新引入的ZGC收集器不管是物理上还是逻辑上ZGC中已经不存在新老年代的概念了 会分为一个个page当进行GC操作时会对page进行压缩因此没有碎片问题 只能在64位的linux上使用目前用得还比较少 1可以达到10ms以内的停顿时间要求 2支持TB级别的内存 3堆内存变大后停顿时间还是在10ms以内 2.5.5.9 垃圾收集器分类 串行收集器-Serial和Serial Old 只能有一个垃圾回收线程执行用户线程暂停。 适用于内存比较小的嵌入式设备。 并行收集器[吞吐量优先]-Parallel Scanvenge、Parallel Old 多条垃圾收集线程并行工作但此时用户线程仍然处于等待状态。 适用于科学计算、后台处理等若交互场景。 并发收集器[停顿时间优先]-CMS、G1 用户线程和垃圾收集线程同时执行(但并不一定是并行的可能是交替执行的)垃圾收集线程在执行的时候不会停顿用户线程的运行。 适用于相对时间有要求的场景比如Web。 2.5.5.10 常见问题 吞吐量和停顿时间 停顿时间-垃圾收集器 进行 垃圾回收终端应用执行响应的时间吞吐量-运行用户代码时间/(运行用户代码时间垃圾收集时间) 停顿时间越短就越适合需要和用户交互的程序良好的响应速度能提升用户体验 高吞吐量则可以高效地利用CPU时间尽快完成程序的运算任务主要适合在后台运算而不需要太多交互的任务。小结:这两个指标也是评价垃圾回收器好处的标准。 如何选择合适的垃圾收集器 https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref28 优先调整堆的大小让服务器自己来选择如果内存小于100M使用串行收集器如果是单核并且没有停顿时间要求使用串行或JVM自己选如果允许停顿时间超过1秒选择并行或JVM自己选如果响应时间最重要并且不能超过1秒使用并发收集器 对于G1收集 JDK 7开始使用JDK 8非常成熟JDK 9默认的垃圾收集器适用于新老生代。 是否使用G1收集器 150%以上的堆被存活对象占用 2对象分配和晋升的速度变化非常大 3垃圾回收时间比较长G1中的RSet 全称Remembered Set记录维护Region中对象的引用关系 试想在G1垃圾收集器进行新生代的垃圾收集时也就是Minor GC假如该对象被老年代的Region中所引用这时候新生代的该对象就不能被回收怎么记录呢 不妨这样用一个类似于hash的结构key记录region的地址value表示引用该对象的集合这样就能知道该对象被哪些老年代的对象所引用从而不能回收。如何开启需要的垃圾收集器 这里JVM参数信息的设置大家先不用关心后面会学习到。 1串行-XXUseSerialGC -XXUseSerialOldGC 2并行(吞吐量优先)-XXUseParallelGC-XXUseParallelOldGC 3并发收集器(响应时间优先)-XXUseConcMarkSweepGC-XXUseG1GC并发 垃圾收集线程 与业务线程一起执行的过程 叫并发 但是这个时候 硬件是单核的 并发不并行 并行 多个垃圾收集线程进行执行 STW 吞吐量 停顿时间 垃圾收集器的好坏的 如果停顿时间在可控制范围之内那么优先考虑吞吐量 如果吞吐量在极限情况下优先考虑停顿时间 0-0.5S 之上 设置一个0.5S左右的极限吞吐 优先设置最大吞吐 95% 尽可能降低停顿时间 1%的吞吐可以换来30% 98% 1S 97% 0.7S 怎么并发的 是不是完全并发 不能完全并发 减小停顿时间 并不是让停顿时间消失 垃圾收集线程 与业务线程 如何一起运行 该回收的没回收 不该回收的被回收了 产生垃圾 标记清除算法 我需要把耗时的步骤 全部并发 并且 把不耗时的步骤 STW 如果我们希望垃圾收集时间变短 我们应该怎么办 标记 找出所有的GC root 并且找出所有引用链上的存活对象 并且标记 清除 初始标记找出所有的GC root标记直接相关联的第一个对象 STW 并发标记找出所有的引用链上的剩余对象 耗时 并发执行 重新标记就是将第二步所产生的垃圾进行二次标记 不耗时 STW 并发清理清理所有垃圾 耗时 并发执行 G1 1.可以让你停顿时间变短 想多短就多短 1个小时 浏览器 2.某种程度上可以解决空间碎片的问题 Azure C4