JVM与GC

每一个开上爱车的人都曾有一个慢慢攒钱的过程。 每一次查看进度都是一次小小的激励。微信扫码开始你的购车之路~一.JVM结构图2 jvm(jdk1.7)JVM包含两个子系统和两个组件两个子系统为Class loader(类装载器)、Execution engine(执行引擎)两个组件为Runtime data area(运行时数据区)、Native Interface(本地接口)。1Class loader(类装载)根据给定的全限定名类名(如java.lang.Object)来装载class文件到Runtime data area中的method area。2Execution engine执行引擎执行classes中的指令,包括JIT即时编译器和GC垃圾回收器。3Native Interface(本地接口)与native libraries交互是其它编程语言交互的接口。4Runtime data area(运行时数据区域)这就是我们常说的JVM的内存。二.JVM内存图2 jvm内存(jdk1.7)图3 jvm内存(jdk1.8)根据 JVM 规范JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。对于方法区是jvm的一个标准不同的jvm实现的方式不同。 大多数用的JVM都是Sun公司的HotSpot。在HotSpot上不同的jdk版本不同实现的方式也不一样对于jdk1.8之前用永久代来实现方法区1.8及之后用元空间来实现方法区。线程共享堆、方法区对于栈虚拟机栈、本地方法栈、程序计数器每个线程都是私有的所以图2用同一种颜色标明白色共享橙色私有。1虚拟机栈线程栈用于存储局部变量表基本类型、引用类型的变量、方法中的形参、操作数栈、动态链接、方法出口等信息2 堆Heap堆中主要存放new出来的东西如数组和对象、成员变量全局变量对于jdk1.7来说字符串常量池 从永久代中移到了堆内存中属于堆内存的一部分。jdk1.8后移除了永久代新增了元空间对于字符串常量池未做改变。3方法区永久代元空间存储已被虚拟机加载的类的相关信息jdk1.8及以后方法区发生了大变1:移除了永久代持久代PermGen替换为元空间Metaspace2:永久代中的 class metadata 转移到了 native memory本地内存而不是虚拟机3:永久代中字符串常量池 转移到了 Java heap4:永久代参数 PermSize MaxPermSize - 元空间参数MetaspaceSize MaxMetaspaceSize所以对于jdk1.8字符串常量数据过多会报Java heap space4本地方法栈与虚拟机栈所发挥的作用是非常相似的其区别不过是虚拟机栈为虚拟机执行Java 方法也就是字节码服务而本地方法栈则是为虚拟机使用到的Native 方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定因此具体的虚拟机可以自由实现它。甚至有的虚拟机譬如Sun HotSpot 虚拟机直接就把本地方法栈和虚拟机栈合二为一。5程序计数器程序计数器是一块较小的内存空间可以看作是当前线程所执行的字节码的行号指示器。分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的在任何一个确定的时刻一个处理器对于多核处理器来说是一个内核只会执行一条线程中的指令。因此为了线程切换后能恢复到正确的执行位置每条线程都需要有一个独立的程序计数器各条线程之间的计数器互不影响独立存储我们称这类内存区域为“线程私有”的内存。三.堆栈的区别物理地址堆的物理地址分配对对象是不连续的。因此性能慢些。在GC的时候也要考虑到不连续的分配所以有各种算法。比如标记-消除复制标记-压缩分代即新生代使用复制算法老年代使用标记——压缩栈使用的是数据结构中的栈先进后出的原则物理地址分配是连续的。所以性能快。内存堆因为是不连续的所以分配的内存是在运行期确认的因此大小不固定。一般堆大小远远大于栈。栈是连续的所以分配的内存大小要在编译期就确认大小是固定的。存放的内容堆存放的是对象的实例和数组。因此该区更关注的是数据的存储栈存放局部变量操作数栈返回结果。该区更关注的是程序方法的执行。程序的可见度堆对于整个应用程序都是共享、可见的。栈只对于线程是可见的。所以也是线程私有。他的生命周期和线程相同。四.队列、栈区别队列和栈都是被用来预存储数据的。①操作的名称不同。队列的插入称为入队队列的删除称为出队。栈的插入称为进栈栈的删除称为出栈。②可操作的方式不同。队列是在队尾入队队头出队即两边都可操作。而栈的进栈和出栈都是在栈顶进行的无法对栈底直接进行操作。③操作的方法不同。队列是先进先出FIFO即队列的修改是依先进先出的原则进行的。新来的成员总是加入队尾不能从中间插入每次离开的成员总是队列头上不允许中途离队。而栈为后进先出LIFO,即每次删除出栈的总是当前栈中最新的元素即最后插入进栈的元素而最先插入的被放在栈的底部要到最后才能删除。五.垃圾回收算法标记-清除算法标记无用对象然后进行清除回收是一种常见的基础垃圾收集算法它将垃圾收集分为两个阶段①标记阶段标记出可以回收的对象。②清除阶段回收被标记的对象所占用的空间。标记-清除算法之所以是基础的是因为后面讲到的垃圾收集算法都是在此算法的基础上进行改进的。优点实现简单不需要对象进行移动。缺点标记、清除过程效率低产生大量不连续的内存碎片提高了垃圾回收的频率。标记-清除算法的执行的过程如下图所示复制算法为了解决标记-清除算法的效率不高的问题产生了复制算法。它把内存空间划为两个相等的区域每次只使用其中一个区域。垃圾收集时遍历当前使用的区域把存活对象复制到另外一个区域中最后将当前使用的区域的可回收的对象进行回收。优点按顺序分配内存即可实现简单、运行高效不用考虑内存碎片。缺点可用的内存大小缩小为原来的一半对象存活率高时会频繁进行复制。复制算法的执行过程如下图所示标记-整理算法在新生代中可以使用复制算法但是在老年代就不能选择复制算法了因为老年代的对象存活率会较高这样会有较多的复制操作导致效率变低。标记-清除算法可以应用在老年代中但是它效率不高在内存回收后容易产生大量内存碎片。因此就出现了一种标记-整理算法Mark-Compact算法与标记-整理算法不同的是在标记可回收的对象后将所有存活的对象压缩到内存的一端使他们紧凑的排列在一起然后对端边界以外的内存进行回收。回收后已用和未用的内存都各自一边。优点解决了标记-清理算法存在的内存碎片问题。缺点仍需要进行局部对象移动一定程度上降低了效率。标记-整理算法的执行过程如下图所示分代收集算法根据对象存活周期的不同将内存划分为几块一般是新生代和老年代新生代基本采用复制算法jdk1.8默认ParallelGC老年代基本采用标记整理算法jdk1.8默认ParallelOldGC加上-XX:PrintFlagsFinal参数启动看到如下参数true代表开启和使用D:\devSoftware\other\java\jdk1.8.0_161\bin\java.exe -Xmx5m -XX:PrintFlagsFinal -XX:PrintGCDetails -Didea.test.cyclic.buffer.size1048576 -javaagent:D:\devSoftware\ide\IntelliJ IDEA 2019.3.5\lib\idea_rt.jar64190:D:\devSoftware\ide\IntelliJ IDEA 2019.3.5\bin -Dfile.encodingUTF-8 -classpath C:\Users\Administrator\AppData\Local\Temp\classpath416242117.jar com.intellij.rt.junit.JUnitStarter -ideVersion5 -junit4 com.yonyou.btis.test.TTT,t[Global flags]bool UseParallelGC : true {product}bool UseParallelOldGC true {product}CMS默认是关闭的bool UseConcMarkSweepGC false {product}如果想开启CMS回收器加上-XX:UseConcMarkSweepGC完整的jdk1.8垃圾回收器的默认状态bool UseSerialGC false {product}bool UseParNewGC false {product}bool UseParallelGC : true {product}bool UseParallelOldGC true {product}bool UseG1GC false {product}当前商业虚拟机都采用分代收集的垃圾收集算法。分代收集算法顾名思义是根据对象的存活周期将内存划分为年轻代、老年代 如图所示六. JVM 垃圾回收器如果说垃圾收集算法是内存回收的方法论那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge回收老年代的收集器包括Serial Old、Parallel Old、CMS还有用于回收整个Java堆的G1收集器。不同收集器之间的连线表示它们可以搭配使用。根据jdk源码可看出一般是Serial对应Serial Old、ParNew对应CMS、Parallel Scavenge对应Parallel OldSerial收集器复制算法):新生代单线程收集器标记和清理都是单线程优点是简单高效ParNew收集器 (复制算法):新生代收并行集器实际上是Serial收集器的多线程版本在多核CPU环境下有着比Serial更好的表现Parallel Scavenge收集器 (复制算法):新生代并行收集器追求高吞吐量高效利用 CPU。吞吐量 用户线程时间/(用户线程时间GC线程时间)高吞吐量可以高效率的利用CPU时间尽快完成程序的运算任务适合后台应用等对交互相应要求不高的场景Serial Old收集器 (标记-整理算法)---jdk8已废除:老年代单线程收集器Serial收集器的老年代版本Parallel Old收集器 (标记-整理算法)老年代并行收集器吞吐量优先Parallel Scavenge收集器的老年代版本CMS(Concurrent Mark Sweep)收集器标记-清除算法老年代并发收集器以获取最短回收停顿时间为目标的收集器具有高并发、低停顿的特点追求最短GC回收停顿时间。G1(Garbage First)收集器 (标记-整理算法)Java堆并发收集器G1收集器是JDK1.7提供的一个新收集器JDK1.9已经设为默认的垃圾收集器。G1不区分物理上的新生代和老年代而是逻辑上区分新生代和老年代回收的范围是整个Java堆(包括新生代老年代)。G1把连续的 Java 堆划分为多个大小相等的独立区域region每个 region 都可以根据需要扮演新生代的 Eden 区Survivor 空间或者老年代空间可看做俄罗斯方块动态移动压缩空闲内存使之足够紧凑减少内存碎片的产生。region区域大小1-32M为2的幂最多2048个region区域可以通过参数-XX:G1HeapRegionSize设定。与CMS相比的特点1.标记整理不会出现内存碎片。2;用户可指定期望的stw时间可以通过参数-XX:MaxGCPauseMillisn设定。3.不区分物理上的内存逻辑上区分新生代和老年代。4.专用大对象region。回收过程YGC是否需要扫描整个老年代我们知道判断对象是否存活需要从GC ROOTS结点出发从GC ROOTS结点可达的对象就是存活的。在YGC时老年代中的对象是不回收的也就意味着GC ROOTS里面应包含了老年代中的对象(老对象的引用在栈中)。但扫描整个老年代会很耗费时间势必影响整个GC的性能。所以在CMS中使用了Card Table的结构里面记录了老年代对象到新生代引用。Card Table的结构是一个连续的byte[]数组扫描Card Table的时间比扫描整个老年代的代价要小很多G1也参照了这个思路不过采用了一种新的数据结构 Remembered Set 简称Rset。RSet记录了其他Region中的对象引用本Region中对象的关系属于points-into结构谁引用了我的对象。而Card Table则是一种points-out我引用了谁的对象的结构每个Card 覆盖一定范围的Heap一般为512Bytes。G1的RSet是在Card Table的基础上实现的每个Region会记录下别的Region有指向自己的指针并标记这些指针分别在哪些Card的范围内。 这个RSet其实是一个Hash TableKey是别的Region的起始地址Value是一个集合里面的元素是Card Table的Index。每个Region都有一个对应的Rset。在做YGC的时候只需要选定young generation region的RSet作为根集这些RSet记录了old-young的跨代引用避免了扫描整个old generation。 而mixed gc的时候old generation中记录了old-old的RSetyoung-old的引用由扫描全部young generation region得到这样也不用扫描全部old generation region。所以RSet的引入大大减少了GC的工作量。七.CMS 垃圾回收器CMS 是英文 Concurrent Mark-Sweep 的简称是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上这种垃圾回收器非常适合。在启动 JVM 的参数加上“-XX:UseConcMarkSweepGC”来指定使用 CMS 垃圾回收器。整个过程分为 4 个步骤包括1初始标记只标记根节点直接关联的引用对象需要暂停用户线程时间短2并发标记标记其他引用对象可以跟用户线程并发同时执行3重新标记暂停用户线程对并发标记期间新增加的引用关系变化再次标记时间短4并发清除跟用户线程并发进行。其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象速度很快并发标记阶段就是进行 GC Roots Tracing 的过程而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录这个阶段的停顿时间一般会比初始标记阶段稍长一些但远比并发标记的时间短。由于整个过程中耗时最长的并发标记和并发清除过程中收集器线程都可以与用户线程一起工作所以总体上来说CMS 收集器的内存回收过程是与用户线程一起并发地执行。CMS 收集器已经在很大程度上减少了用户线程的停顿时间CMS 使用的是标记-清除的算法实现的所以在 gc 的时候回产生大量的内存碎片当剩余内存不能满足程序运行要求时系统将会出现 Concurrent Mode Failure临时 CMS 会采用 Serial Old 回收器进行垃圾清除此时的性能将会被降低。分代垃圾回收器工作的流程分代回收器有两个分区老生代和新生代新生代默认的空间占比总空间的 1/3老生代的默认占比是 2/3。新生代使用的是复制算法新生代里有 3 个分区Eden、To Survivor、From Survivor它们的默认占比是 8:1:1它的执行流程如下①把 Eden From Survivor 存活的对象放入 To Survivor 区②清空 Eden 和 From Survivor 分区③ From Survivor 和 To Survivor 分区交换From Survivor 变 To SurvivorTo Survivor 变 From Survivor。每次在 From Survivor 到 To Survivor 移动时都存活的对象年龄就 1当年龄到达 15默认配置是 15时升级为老生代。大对象也会直接进入老生代。老生代当空间占用到达某个值之后就会触发全局垃圾收回一般使用标记整理的执行算法。以上这些循环往复就构成了整个分代垃圾回收的整体执行流程。八安全点1安全点Safe Point和安全区域Safe RegionJVM的GC不是在任何时刻都会发生的只有在特定的位置才能停顿下来stw开始GC 也就是安全点和安全区域。2. GC时线程的中断策略抢先式中断首先中断所有线程。如果还有线程不在安全点 就恢复线程 让线程跑到安全点。主动式中断一般是这种设置一个中断标志 各个线程运行到Safe Point的时候主动轮询这个标志如果中断标志为真 则将自己进行中断挂起。3.安全点Safe Point安全点的选择很重要 如果太少可能导致GC 等待的时间太长 如果太频繁可能导致运行时的性 能问题。一般选择如下位置作为安全点如循环的末尾方法临返回前调用方法之后抛异常的位置4.安全区域Safe Region安全区域Safe Region用来保证一些无法主动响应JVM中断请求的线程。例如线程处于Sleep状态或Blocked状态无法主动走到安全点去中断挂起JVM也不太可能等待线程被唤醒时再进行。JVM认为在安全区域代码片段中对象的引用关系不会发生变化都睡眠了肯定不会变化 在这个区域中的任何位置开始GC都是安全的。但是注意的是安全区域中的代码醒来的时候需要判断是否GC完毕如果此时还在GC中那么是无法醒来执行逻辑的必须等待GC后才能执行后面的逻辑。九.相关参数1.UseAdaptiveSizePolicyJDK 1.8 默认使用 UseParallelGC 垃圾回收器该垃圾回收器默认启动了 AdaptiveSizePolicy会根据GC的情况自动计算计算 Eden、From 和 To 区的大小bool UseAdaptiveSizePolicy true {product}开启-XX:UseAdaptiveSizePolicy关闭-XX:-UseAdaptiveSizePolicy注意事项1、在 JDK 1.8 中如果使用 CMS无论 UseAdaptiveSizePolicy 如何设置都会将 UseAdaptiveSizePolicy 设置为 false不过不同版本的JDK存在差异2、UseAdaptiveSizePolicy不要和SurvivorRatio参数显示设置搭配使用一起使用会导致参数失效3、由于AdaptiveSizePolicy会动态调整 Eden、Survivor 的大小有些情况存在Survivor 被自动调为很小比如十几MB甚至几MB的可能这个时候YGC回收掉 Eden区后还存活的对象进入Survivor 装不下就会直接晋升到老年代导致老年代占用空间逐渐增加从而触发FULL GC如果一次FULL GC的耗时很长比如到达几百毫秒那么在要求高响应的系统就是不可取的。2PrintCommandLineFlags查看jvm默认开启的参数-XX:PrintCommandLineFlags-XX:InitialHeapSize268435456-XX:MaxHeapSize4294967296-XX:PrintCommandLineFlags-XX:UseCompressedClassPointers-XX:UseCompressedOops-XX:UseParallelGCjava version 1.8.0_162Java(TM) SE Runtime Environment (build 1.8.0_162-b12)Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)jdk1.8默认的垃圾回收器是UseParallelGC以及默认的堆内存等3.Allocation Failure、System.gc()、Ergonomics触发垃圾回收的几种原因Allocation Failure的原因是年轻代中没有足够区域能够存放需要分配的数据而失败。Ergonomics是因为开启了UseAdaptiveSizePolicyjvm自己进行自适应调整引发的full gc。十.GCDetailsjdk1.8 增加启动参数-XX:PrintGCDetails参数说明DefNewDefault New GenerationSerialTenuredOldParNewParallel New GenerationPSYoungGenParallel ScavengeParOldGenParallel Old Generationjdk1.8默认开启Parallel Scavenge和Parallel Old垃圾收集器。所以打印的是PSYoungGen和ParOldGenMinor GC[GC (Allocation Failure) [PSYoungGen: 1004K-505K(1536K)] 1004K-730K(5632K), 0.0010488 secs] [Times: user0.00 sys0.00, real0.00 secs]1. GC (Allocation Failure) 发生了一次垃圾回收这是一次Minor GC 。括号里的内容是gc发生的原因这里的Allocation Failure的原因是年轻代中没有足够区域能够存放需要分配的数据而失败。2. PSYoungGen: 使用的垃圾收集器的名字PSYoungGen表示Parallel Scavenge。3. 1004K-505K(1536K)指的是垃圾收集前大小-垃圾收集后大小(年轻代edenfrom/to总大小)4.1004K-730K(5632K),指的是垃圾收集前后Java堆的大小总堆5632K堆大小包括新生代和年老代5. 0.0010488 secs整个GC过程持续时间Major GC[Full GC (Ergonomics) [PSYoungGen: 1536K-0K(1536K)] [ParOldGen: 4090K-3664K(4096K)] 5626K-3664K(5632K), [Metaspace: 5382K-5382K(1056768K)], 0.0327000 secs] [Times: user0.11 sys0.02, real0.03 secs]1. Full GC (Ergonomics) 发生了一次垃圾回收这是一次Major GC 。括号里的内容是gc发生的原因这里的Ergonomics原因是jvm自己进行自适应调整引发GC。2. 由于Major GC都是由Minor GC引起所以包含了Minor GC的信息3. ParOldGen: 使用的垃圾收集器的名字。PSYoungGen表示Parallel Old。3. 4090K-3664K(4096K)指的是垃圾收集前大小-垃圾收集后大小(老年代的大小)5.5626K-3664K(5632K), 和上面Minor GC类似只不过由1004K变为了5626K,因为包含了新生代6. 0.0327000 secs整个GC过程持续时间十一.内存分配对象优先在 Eden 区分配多数情况对象都在新生代 Eden 区分配。当 Eden 区分配没有足够的空间进行分配时虚拟机将会发起一次 Minor GC。如果本次 GC 后还是没有足够的空间则将启用分配担保机制在老年代中分配内存。这里我们提到 Minor GC如果你仔细观察过 GC 日常通常我们还能从日志中发现 Major GC/Full GC。Minor GC是指发生在新生代的 GC因为 Java 对象大多都是朝生夕死所有 Minor GC 非常频繁一般回收速度也非常快Major GC/Full GC是指发生在老年代的 GC出现了 Major GC 通常会伴随至少一次 Minor GC。Major GC 的速度通常会比 Minor GC 慢 10 倍以上。大对象直接进入老年代所谓大对象是指需要大量连续内存空间的对象频繁出现大对象是致命的会导致在内存还有不少空间的情况下提前触发 GC 以获取足够的连续空间来安置新对象。新生代使用的是复制算法来处理垃圾回收的如果大对象直接在新生代分配就会导致 Eden 区和两个 Survivor 区之间发生大量的内存复制。因此对于大对象都会直接在老年代进行分配。长期存活对象将进入老年代虚拟机采用分代收集的思想来管理内存那么内存回收时就必须判断哪些对象应该放在新生代哪些对象应该放在老年代。因此虚拟机给每个对象定义了一个对象年龄的计数器如果对象在 Eden 区出生并且能够被 Survivor 容纳将被移动到 Survivor 空间中这时设置对象年龄为 1。对象在 Survivor 区中每「熬过」一次 Minor GC 年龄就加 1当年龄达到一定程度默认 15 就会被晋升到老年代十二.类加载机制虚拟机把描述类的数据从Class文件加载到内存并对数据进行校验解析和初始化最终形成可以被虚拟机直接使用的java类型。1.JVM加载Class文件的原理机制Java中的所有类都需要由类加载器装载到JVM中才能运行。类加载器本身也是一个类而它的工作就是把class文件从硬盘读取到内存中。在写程序的时候我们几乎不需要关心类的加载因为这些都是隐式装载的除非我们有特殊的用法像是反射就需要显式的加载所需要的类。类装载方式有两种 ①隐式装载程序在运行过程中当碰到通过new 等方式生成对象时隐式调用类装载器加载对应的类到jvm中②显式装载通过class.forname()等方法显式加载需要的类Java类的加载是动态的它并不会一次性将所有类全部加载后再运行而是保证程序运行的基础类(像是基类)完全加载到jvm中至于其他类则在需要的时候才加载。这当然就是为了节省内存开销2.类加载器实现通过类的权限定名获取该类的二进制字节流的代码块叫做类加载器。主要有一下四种类加载器:①启动类加载器(Bootstrap ClassLoader)用来加载java核心类库无法被java程序直接引用。②扩展类加载器(extensions class loader)它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。③系统类加载器system class loader它根据 Java 应用的类路径CLASSPATH来加载 Java 类。一般来说Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它。④用户自定义类加载器通过继承 java.lang.ClassLoader类的方式实现。3.类装载的执行过程类装载分为以下 5 个步骤①加载根据查找路径找到相应的 class 文件然后导入②验证检查加载的 class 文件的正确性③准备给类中的静态变量分配内存空间④解析虚拟机将常量池中的符号引用替换成直接引用的过程。在编译的时候一个每个java类都会被编译成一个class文件但在编译的时候虚拟机并不知道所引用类的地址所以就用符号引用来代替而在解析阶段就是为了把这个符号引用转化成真正的地址的阶段。⑤初始化对静态变量和静态代码块执行初始化工作。4.双亲委派模型在介绍双亲委派模型之前先说下类加载器。对于任意一个类都需要由加载它的类加载器和这个类本身一同确立在 JVM 中的唯一性每一个类加载器都有一个独立的类名称空间。类加载器就是根据指定全限定名称将 class 文件加载到 JVM 内存然后再转化为 class 对象。双亲委派模型如果一个类加载器收到了类加载的请求它首先不会自己去加载这个类而是把这个请求委派给父类加载器去完成每一层的类加载器都是如此这样所有的加载请求都会被传送到顶层的启动类加载器中只有当父加载无法完成加载请求它的搜索范围中没找到所需的类时子加载器才会尝试去加载类。当一个类收到了类加载请求时不会自己先去加载这个类而是将其委派给父类由父类去加载如果此时父类不能加载反馈给子类由子类去完成类的加载。