如何建立一个手机网站,网站备案要网站做才可以使用吗,ensp企业网络拓扑图,网站的实用性G1(Garbage First)收集器 (标记-整理算法)#xff1a; Java堆并行收集器#xff0c;G1收集器是JDK1.7提供的一个新收集器#xff0c;G1收集器基于“标记-整理”算法实现#xff0c;也就是说不会产生内存碎片。此外#xff0c;G1收集器不同于之前的收集器的一个重要特点是 Java堆并行收集器G1收集器是JDK1.7提供的一个新收集器G1收集器基于“标记-整理”算法实现也就是说不会产生内存碎片。此外G1收集器不同于之前的收集器的一个重要特点是G1回收的范围是整个Java堆(包括新生代老年代)而其他收集器回收的范围仅限于新生代或老年代。 -XX:UseG1GC -Xmx32g -XX:MaxGCPauseMillis200
其中-XX:UseG1GC用于开启 G1 垃圾收集器-Xmx32g用于设置堆内存的最大内存为 32G-XX:MaxGCPauseMillis200用于设置 GC 的最大暂停时间为 200ms。如果我们需要调优在内存大小一定的情况下我们只需要修改最大暂停时间即可。 关键字
LAB
由于分区的思想每个线程均可以认领某个分区用于线程本地的内存分配而不需要顾及分区是否连续。因此每个应用线程和GC线程都会独立的使用分区进而减少同步时间提升GC效率这个分区称为本地分配缓冲区(Lab)。 TLAB
应用线程可以独占一个本地缓冲区(TLAB)来创建的对象而大部分都会落入Eden区域(巨型对象或分配失败除外)因此TLAB的分区属于Eden空间 GCLAB
每次垃圾收集时每个GC线程同样可以独占一个本地缓冲区(GCLAB)用来转移对象每次回收会将对象复制到Suvivor空间或老年代空间 PLAB
对于从Eden/Survivor空间晋升(Promotion)到Survivor/老年代空间的对象同样有GC独占的本地缓冲区进行操作该部分称为晋升本地缓冲区(PLAB)。 G1堆内存结构 堆内存中一个区域 (Region) 的大小可以通过 -XX:G1HeapRegionSize 参数指定大小区间最小 1M 、最大 32M 总之是 2 的幂次方。 默认是将堆内存按照 2048 份均分。 每个 Region 被标记了 E、S、O 和 H这些区域在逻辑上被映射为 EdenSurvivor 和老年代。 存活的对象从一个区域转移即复制或移动到另一个区域。区域被设计为并行收集垃圾可能会暂停所有应用线程。 此外还有第四种类型被称为巨型区域Humongous Region。 G1中的region的大小由参数G1HeapRegionSize定义如果没有定义就由xms/2048计算region大小如果小于1就取1如果大于32就取32如果是其他值就取2,4,8,16相近的数值总之是2的n次方。 G1中的region的数量不一定是2048如果内存小于2G每个region最小为1M那么数量就小于2048比如内存超过64g每个region最大为32M那么数量也就超过2048例如128g那么region数量就为4096个。 巨形对象Humongous Region
存储超过 50% 标准 region 大小的对象称为巨型对象(Humongous Object)。当线程为巨型分配空间时不能简单在TLAB进行分配因为巨型对象的移动成本很高而且有可能一个分区不能容纳巨型对象。因此巨型对象会直接在老年代分配所占用的连续空间称为巨型分区(Humongous Region)。G1内部做了一个优化一旦发现没有引用指向巨型对象则可直接在年轻代收集周期中被回收。 巨型对象会独占一个、或多个连续分区其中第一个分区被标记为开始巨型(StartsHumongous)相邻连续分区被标记为连续巨型(ContinuesHumongous)。由于无法享受Lab带来的优化并且确定一片连续的内存空间需要扫描整堆因此确定巨型对象开始位置的成本非常高如果可以应用程序应避免生成巨型对象。 如果一个 H 区装不下一个巨型对象那么 G1 会寻找连续的 H 分区来存储。为了能找到连续的 H 区有时候不得不启动 Full GC 。 Remember Set
在串行和并行收集器中GC时是通过整堆扫描来确定对象是否处于可达路径中。然而G1为了避免STW式的整堆扫描为每个分区各自分配了一个 RSetRemembered Set它内部类似于一个反向指针记录了其它 Region 对当前 Region 的引用情况这样就带来一个极大的好处回收某个Region时不需要执行全堆扫描只需扫描它的 RSet 就可以找到外部引用来确定引用本分区内的对象是否存活进而确定本分区内的对象存活情况而这些引用就是 initial mark 的根之一。 事实上并非所有的引用都需要记录在RSet中如果引用源是本分区的对象那么就不需要记录在 RSet 中同时 G1 每次 GC 时所有的新生代都会被扫描因此引用源是年轻代的对象也不需要在RSet中记录所以最终只需要记录老年代到新生代之间的引用即可。 RSet 的写屏障
写屏障是指每次 Reference 引用类型在执行写操作时都会产生 Write Barrier 写屏障暂时中断操作并额外执行一些动作。 对写屏障来说过滤掉不必要的写操作是十分有必要的因为写栅栏的指令开销是十分昂贵的这样既能加快赋值器的速度也能减轻回收器的负担。G1 收集器的写屏障是跟 RSet 相辅相成的产生写屏障时会检查要写入的引用指向的对象是否和该 Reference 类型数据在不同的 Region如果不同才通过 CardTable 把相关引用信息记录到引用指向对象的所在 Region 对应的 RSet 中通过过滤就能使 RSet 大大减少。 1写前栅栏即将执行一段赋值语句时等式左侧对象将修改引用到另一个对象那么等式左侧对象原先引用的对象所在分区将因此丧失一个引用那么JVM就需要在赋值语句生效之前记录丧失引用的对象。但JVM并不会立即维护RSet而是通过批量处理在将来RSet更新 2写后栅栏当执行一段赋值语句后等式右侧对象获取了左侧对象的引用那么等式右侧对象所在分区的RSet也应该得到更新。同样为了降低开销写后栅栏发生后RSet也不会立即更新同样只是记录此次更新日志在将来批量处理
G1垃圾回收器进行垃圾回收时在GC根节点枚举范围加入RSet就可以保证不进行全局扫描也不会有遗漏。另外JVM使用的其余的分代的垃圾回收器也都有写屏障举例来说每次将一个老年代对象的引用修改为指向年轻代对象都会被写屏障捕获并记录下来因此在年轻代回收的时候就可以避免扫描整个老年代来查找根。 G1的垃圾回收器的写屏障使用一种两级的log buffer结构 global set of filled buffer所有线程共享的一个全局的存放填满了的log buffer的集合
thread log buffer每个线程自己的log buffer。所有的线程都会把写屏障的记录先放进去自己的log buffer中装满了之后就会把log buffer放到 global set of filled buffer中而后再申请一个log buffer
