g1

以前收集器的特点 年轻代和老年代是各自独立且连续的内存块 年轻代收集必须使用单个eden+S0+S1进行复制算法 老年代收集扫描整个老年代区域 都是以尽可能少而快速地执行GC为设计原则 G1是什么 G1（Garbage-Frist）收集器，是一款面向 服务端 应用的收集器 从官网的描述中，我们知道G1是一种服务器端的垃圾收集器，应用在多处理器和大容量内存环境中，在提高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。另外，它还具有以下特性： 像CMS收集器一样，能与应用程序线程 并发执行 整理空闲空间更快 需要更多的时间来 预测GC停顿时间 不希望牺牲大量的吞吐性能 不需要更大的Java Heap G1收集器的设计目标是取代CMS收集器 ，它同CMS相比，在以下方面表现更出色： G1是一个有整理内存过程的垃圾收集器，不会产生很多内存碎片 G1的Stop-The-World(STW)更可控，G1在停顿时间上添加了预测机制，用户可以指定期望停顿时间。 CMS垃圾集器虽然减少了暂停应用程序的运行时间，但是它还是存在着内存碎片问题。于是，为了去除内存碎片问题，同时又保留CMS垃圾收集器低暂停时间的优点， JAVA7发布了一个新的垃圾收集器-G1垃圾收集器 。 G1是在2012年才在jdk1.7u4中可用。oracle官方计划在 jdk9中将G1变成默认的垃圾收集器以替代CMS

垃圾回收器分类： 回收示意图 serial/serial old回收器搭配使用 paraNew和 serial Old搭配 标记 整理 parallel scavenge： 可控的吞吐量 停顿时间越短适合与用户交互的程序，响应速度能够提升用户的体验，吞吐量能够能高效率的利用cpu的时间。 在Server模式下，ParNew收集器是一个非常重要的收集器，因为除Serial外，目前只有它能与CMS收集器配合工作； cms垃圾收集器 特点： 1 采用标记-清除 没有压缩算法 产生垃圾碎片 （设置参数多次不压缩的GC后来一次压缩的） 2 产生浮动垃圾（Concurrent Mode Fail）: 由于并发标记过程中用户线程运行产生的垃圾，所以CMS回收器会在OLD区域未填满时就进行垃圾回收 ，有一个 百分比 -XX:CMSInitiatingOccupancyFraction来设置这个比例。 如果产生的浮动垃圾太多了，预留的内存无法满足，就会临时使用SerialOld收集器，就是说这个比例设置的太大了的话，就可能会导致serial oLD回收，停顿时间变大。 G1垃圾回收器 官方文档： https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage

前言 基于标记 - 整理算法，作用与年轻代老年代的垃圾回收器。适用场景：要求尽可能可控 GC 停顿时间；内存占用较大的应用。可以用 -XX:+UseG1GC 使用 G1 收集器，jdk9 默认使用 G1 收集器。 流程 1、初始标记（Initial Marking） 停顿线程，但耗时很短 2、并发标记（Concurrent Marking） 从 GC Root 开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。 3、最终标记（Final Marking） 修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录 4、筛选回收（Live Data Counting and Evacuation） 这里有一个预估，对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划，与用户程序一起并发执行，暂停用户线程， 内存模型 在 G1 之前的其他收集器进行收集的范围都是整个新生代或者老年代，而 G1 不再是这样。使用 G1 收集器时，Java 堆的内存布局就与其他收集器有很大差别，它将，虽然还保留有新生代和老年代的概念，但 去掉了新生代或者老年代的物理划分 整个 Java 堆划分为多个大小相等的独立区域（Region），新生代和老年代是一部分 Region （不需要连续）的集合。 Region

什么是G1 Garbage-First收集器是一个并行、并发和增量压缩低停顿的垃圾收集器。 G1的Java堆布局和HotSpot VM中其他垃圾收集器有着极大的不同，它将Java的堆分成相同的块(称为区域，Region)。 G1也是分代的，但整体上没有划分成新生代和老年代。相反，每代是一组(可能不连续)的Region，这使得它可以灵活地调整新生代。 为什么需要了解G1？ 因为G1是JDK 11默认的垃圾收集器，而JDK 11是目前Java最近的LTS。所以还是有必要了解一下G1。 延迟与吞吐量指标 在系统设计的过程必须考虑系统的响应能力(低延迟)与吞吐量两个指标。 低延迟：指系统从接受到请求到返回相应数据的速度，简单理解应用以多快的速度返回请求的数据，例如以多快的速度(ms)打开一个网页。对于面对响应能力的应用来说，长时间的停顿是不可接受的。 吞吐量：指系统在某个指定的时间范围内能够处理的最大工作量，比如每秒钟完成了多少次数据库删除或者查询。对于面对吞吐量的应用来讲，较长的停顿时间是能够接受的，高吞吐量应用关注的是系统处理能力 这两个指标往往是成对出现的，往往是为了满足一个而不得不牺牲另外一个。 G1特点 低延迟优先，即主要侧重于响应能力； 与CMS相同的地方在于，它们都属于并发收集器，在大部分的收集阶段都不需要挂起应用程序； 更精确的预测GC停顿时间，可以根据-XX

1、CMS收集器 CMS收集器是一种以获取最短回收停顿时间为目标的收集器。基于“标记-清除”算法实现，它的运作过程如下： 1）初始标记 2）并发标记 3）重新标记 4）并发清除 初始标记、从新标记这两个步骤仍然需要“stop the world”，初始标记仅仅只是标记一下GC Roots能直接关联到的对象，熟读很快，并发标记阶段就是进行GC Roots Tracing，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生表动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长点，但远比并发标记的时间短。 CMS是一款优秀的收集器，主要优点：并发收集、低停顿。 缺点： 1）CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。 2）CMS收集器无法处理浮动垃圾，可能会出现“Concurrent Mode Failure（并发模式故障）”失败而导致Full GC产生。 浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就会有新的垃圾不断产生，这部分垃圾出现的标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC中再清理。这些垃圾就是“浮动垃圾”。 3）CMS是一款“标记--清除”算法实现的收集器，容易出现大量空间碎片。当空间碎片过多

1.CMS收集器 Concurrent Mark Sweep CMS收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的相应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。 CMS是基于标记-清除 算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤， 初始标记：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快， 并发标记阶段：进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。 2.G1收集器 是当今收集器技术发展的最前沿成果之一，G1是一款面向服务端应用的垃圾收集器。具有以下特点： 并行和并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短停顿时间，部分其他收集器原本需要停顿java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。 分代收集

简称 STW —— Stop the World，暂停所有在执行的线程 简史 2004年Sun实验室第一次发表G1论文 JDK6U14中第一次作为实验选项引入 JDK7中开始作为替换CMS的方案 JDK9中成为默认的垃圾回收器 JDK10优化，将其fullGC改为并行： JEP307 JDK11引入了更新的ZGC，可能会成为G1的潜在替代者 G1特有数据结构和算法 Region 堆仍然有新生代(eden、survivor)、老年代的划分，但是不再要求它们是内存连续的。每个区都由多个Region组成。 部分老年代Region存储Humongous对象(即下图的H)，这种对象大小大于等于Region的一半。 ( 图片来源-Java Hotspot G1 GC的一些关键技术 ) SATB算法 全称Snapshot-At-The-Beginning，起始时活对象的快照。在理解SATB前需要先了解以下知识。 三色标记法 CMS和G1的算法都是通过对gc root 进行遍历，并进行三色标记。标记规则为 黑色(black): 节点被遍历完成，而且子节点都遍历完成。 灰色(gray): 当前正在遍历的节点，而且子节点（即对象的域）还没有遍历。遍历完所有子节点后，将成为黑色 白色(white): 还没有遍历到的节点，即灰色节点的子节点。扫描结束仍是白色时会被回收。 并发扫描时

最近ES集群数据节点经常出现jvm占用过高，频繁GC导致ES集群卡死，很长时间才恢复。在网上看到用G1垃圾回收可以改善这一情况，但都是老版本的ES，我们现在使用的版本是5.5.2，所以想问问各位5.5.2版本的ES能不能改用G1垃圾回收，另外要怎么改为G1，因为以前的版本都是在elasticsearch.in.sh文件中改JAVA_OPTS的配置，但在5.5.2版本中已找不到这个配置，好像在jvm.options文件中，但是不知道具体怎么改。求救~~ ############### 我们线上的集群从5.3.2 - 6.2.4都有用G1的，没有什么问题。 修改jvm.options文件，将下面几行: -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly 更改为 -XX:+UseG1GC -XX:MaxGCPauseMillis=50 即可。 其中 -XX:MaxGCPauseMillis是控制预期的最高GC时长，默认值为200ms，如果线上业务特性对于GC停顿非常敏感，可以适当设置低一些。但是 这个值如果设置过小，可能会带来比较高的cpu消耗。 G1对于集群正常运作的情况下减轻G1停顿对服务时延的影响还是很有效的

Python程序中的协程操作-greenlet模块 一、安装模块 安装：` pip3 install greenlet 二、greenlet实现状态切换 from greenlet import greenlet def eat(name): print('%s eat 1' %name) g2.switch('nick') print('%s eat 2' %name) g2.switch() def play(name): print('%s play 1' %name) g1.switch() print('%s play 2' %name) g1=greenlet(eat) g2=greenlet(play) g1.switch('nick')#可以在第一次switch时传入参数，以后都不需要 单纯的切换（在没有io的情况下或者没有重复开辟内存空间的操作），反而会降低程序的执行速度。 三、效率对比 #顺序执行 import time def f1(): res=1 for i in range(100000000): res+=i def f2(): res=1 for i in range(100000000): res*=i start=time.time() f1() f2() stop=time.time() print('run time is %s' %

java启动参数内可以指定gc的方式，实际情况中参数比较多，摘出部分参数看一下 A: -XX:+UseG1GC -XX:MaxGCPauseMillis=200 B: -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly 上述两个情况分别简称为A，B。 对于B使用的gc方法是CMS，对于A使用的G1。 注意1：内存结构 需要注意一下，对于CMS的内存结构是这样的 但是对于G1，内存划分不是整块整块的，而是把整个内存一整块堆切分成2000个小region，然后年轻代和年老代混排，对于G1，幸存者区域只有一个，所以在执行"jstat -gc"的时候，会看到S0总是空的。【参考资料2,3】 注意2 jstat -gc <pid>输出的信息单位是KB不是字节 注意3 gc触发的条件 gc条件比较多，说一下常见的条件 对于CMS，伊甸园区满了就会GC 对于G1，伊甸园区满了就会GC，另外还有一个参数控制，当整个堆内存达到一定比例就会GC，InitiatingHeapOccupancyPercent。 注意4 G1 gc的模式 G1中提供了三种模式垃圾回收模式，young gc、mixed gc 和 full gc