g1

之前一篇 Blog 已经将GC的机制以及GC的算法讲了一下。 而这篇Blog主要是讨论这些GC的算法在JVM中的不同应用。 1. 串行收集器 串行收集器是 最古老，最稳定以及 效率高的收集器 可能会产生较长的停顿， 只使用一个线程去回收 -XX:+UseSerialGC 新生代、老年代使用串行回收 新生代复制算法 老年代标记-压缩 串行收集器的日志输出： 0.844: [GC 0.844: [DefNew: 17472K->2176K(19648K), 0.0188339 secs] 17472K->2375K(63360K), 0.0189186 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 8.259: [Full GC 8.259: [Tenured: 43711K->40302K(43712K), 0.2960477 secs] 63350K->40302K(63360K), [Perm : 17836K->17836K(32768K)], 0.2961554 secs] [Times: user=0.28 sys=0.02, real=0.30 secs] 2. 并行收集器 2.1 ParNew -XX:+UseParNewGC（new代表新生代，所以适用于新生代） 新生代并行 老年代串行

1.垃圾收集器 G1收集器 首先将Java堆空间划分为一些大小相等的区域（region），每个区域都是虚拟机中的一段连续内存空间。G1通过执行并发的全局标记来确定整个Java堆空间中存活的对象。标记阶段完成后，G1就知道哪些区域基本上是空闲的。在回收内存时优先回收这些区域，这样通常都会回收相当数量的内存。这就是为什么它叫做Garbage-First的原因。顾名思义G1关注某些区域的回收和整理，这些区域中的对象很有可能被完全回收。而且G1使用了一个暂停时间预测模型使得暂停时间控制在用户指定的暂停时间内，并根据用户指定的暂停时间来选择合适的区域回收内存。它与前面的CMS收集器相比有两个显著的改进：一是G1收集器是基于“标记-整理”算法实现的收集器，也就是说它不会产生空间碎片，这对于长时间运行的应用系统来说非常重要。二是它可以非常精确地控制停顿，既能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，具备了一些实时Java（RTSJ）的垃圾收集器的特征。 如果你的堆内存大于4G的话，那么G1会是要考虑使用的收集器。它是为了更好支持大于4G堆内存在JDK 7 u4引入的。G1收集器把堆分成多个区域，大小从1MB到32MB，并使用多个后台线程来扫描这些区域，优先会扫描最多垃圾的区域，这就是它名称的由来，垃圾优先Garbage First。

深入理解G1垃圾收集器 G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项；作为JVM GC算法的一次重大升级、DK7u后G1已相对稳定、且未来计划替代CMS、所以有必要深入了解下： 不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。每块区域既有可能属于O区、也有可能是Y区，且每类区域空间可以是不连续的（对比CMS的O区和Y区都必须是连续的）。这种将O区划分成多块的理念源于：当并发后台线程寻找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。这也是为什么G1命名为Garbage First的原因：第一时间处理垃圾最多的区块。 平时工作中大多数系统都使用CMS、即使静默升级到JDK7默认仍然采用CMS、那么G1相对于CMS的区别在： G1在压缩空间方面有优势 G1通过将内存空间分成区域（Region）的方式避免内存碎片问题 Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活 G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象 G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做 G1会在Young GC中使用

JVM ——垃圾收集器总结 垃圾收集器概览 收集算法是内存回收的方法论，垃圾收集据是内存回收的具体实现。 Java 虚拟机规范中对垃圾收集器应该如何实现没有规定，不同的厂商、不同版本的虚拟机所提供的垃圾收集器可能会有很大差别，一般都会提供参数供用户根据自己的所用特点和要求组合出各个年代所使用的收集器。下面是基于 JDK 1.7 Update 14 之后的 HotSpot 虚拟机垃圾收集器。如果两个收集器之间有连线就说明它们可以搭配使用。 直到现在还没有最好的收集器，更加设有万能的收集器，只是对具体应用选择最合适的收集器。 垃圾收集器概览图如下： Serial 收集器 Serial 收集器是最基本、历史最悠久的收集器，它是一个单线程的收集器，即它只会使用一个 CPU 或一条收集线程去完成垃圾收集工作，而且在进行垃圾收集时， 必须暂停其他所有的工作钱程，直到它收集结束，虽然它有很大缺点，但依然是虚拟机运行在 Client 模式下的默认新生代收集器。它也有着优于其他收集器的地方： 简单而高效。 Serial 收集器没有线程交互的开销， 专心做垃圾收集，可以获得很高的单线程收集效率。 运行示意图如下： ParNew 收集器 ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括 Serial 收集器可用的所有控制参数、、收集算法

G1是一款面向服务端的垃圾回收器，它是作用是替换到JDK1.5中发布的CMS收集器，与其他收集器相比，G1具有以下优点： 并行与并发 利用多核CPU来缩短Stop the world停顿的时间，G1收集器可以通过并发的方式让Java程序与GC并发执行。 分代收集 G1收集器任然保留分代收集的方式； G1收集器可以不需要其他收集器配合就能单独管理整个堆，它可以采用不同的方式处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象从而获得更好的收集效果。 空间整理 与GMS的“标记-清除”算法不同，G1收集器从整理上看是“标记-整理”算法实现的收集器，从局部看（两个Region之间）上看是基于“复制”算法实现的，从这两种算法来看那G1运行期间不会产生内存空间碎片，收集器能提供规整的可用空间，这种特性有利于程序长时间运行，分配大对象时不会因为无法分配到连续的内存空间而提前触发下一次GC。 可预测的停顿 G1相比于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型：能让使用者明确指出在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超过N毫秒。 G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，但是G1是将整个堆划分为多个大小相等的独立区域（region），虽然也保留了新生代和老年代的概念

CMS收集器 CMS(Concurrent Map Sweep)收集器是一种以最短回收停顿时间为目标的收集器，通常用于JavaWeb程序上，重视服务响应速度，希望系统时间停顿最短，而它是基于"标记-清除"算法。 整个过程分为四个步骤： 初始标记 只是标记一下GC Roots能直接关联到的对象，速度很快。 并发标记 是进行GC RootsTracing的过程 重新标记 修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。 并发清除 清除标记 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。 但是它也如下缺点： CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源） CMS收集器无法处理浮动垃圾。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉他们，只好留待下一次GC时再清理掉。 CMS收集器是基于”标记-清除“算法实现的收集器。收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦

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是一款“标记--清除”算法实现的收集器，容易出现大量空间碎片。当空间碎片过多

7-125 垃圾箱分布 (30分) 输入样例1： 4 3 11 5 1 2 2 1 4 2 1 G1 4 1 G2 3 2 3 2 2 G2 1 3 4 2 3 G3 2 4 G1 3 G2 G1 1 G3 G2 2 输出样例1： G1 2.0 3.3 输入样例2： 2 1 2 10 1 G1 9 2 G1 20 输出样例2： No Solution 思路 题目大意：求最短距离尽可能的大，而且总的距离尽可能小；相同的话再接着判断。。。 该题主要用dijkstra算法，可以计算出该垃圾桶离用户的最短距离和垃圾桶到所有用户的总距离。 具体解析见代码： # include <bits/stdc++.h> using namespace std ; int n , m , k , dmax , nm , sum , dmin , flag = 0 , flag2 = 0 , minn , cnt = 0 ; int d [ 1100 ] , cost [ 1100 ] [ 1100 ] , vis [ 1100 ] ; struct rubbish { int index , mind , sumd ; } r [ 12 ] ; int deal ( char * s ) { //对输入的数据进行处理，使得用户编号从1-n，垃圾桶编号从n+1至n+m; if ( isdigit ( s [

1. 使用jcmd 假设java进程id为 1000 # Linux jcmd 1000 PerfCounter.print | grep gc.collector.*name # Windows jcmd 1000 PerfCounter.print | findstr gc.collector.*name 以串行收集器(-XX:+UseSerialGC )为例，返回信息如下： sun . gc . collector . 0. name = "Copy" sun . gc . collector . 1. name = "MSC" 名称与收集器对照表 名称 收集器 作用区域 启用参数 Copy Serial Young -XX:+UseSerialGC MSC Serial Old Old -XX:+UseSerialGC PSScavenge Parallel Scavenge Young -XX:+UseParallelGC PSMarkSweep Parallel Scavenge Old -XX:+UseParallelGC -XX:-UseParallelOldGC PSParallelCompact Parallel Old Old -XX:+UseParallelGC PCopy ParNew Young -XX:+UseConcMarkSweepGC 或者

greenlet+switch机制来实现协程 greenlet用于创建协程，switch用于进行协程之间的切换某个协程在执行的过程中可以随时的被其他协程通过switch函数来打断，转而去执行其他协程，当前协程的中断现场会被保留，一旦中断的协程再次获得cpu的执行权首先会恢复现场然后从中断处继续执行 这种机制下的协程是同步，不能并发： from greenlet import greenlet from time import sleep def func1 ( ) : print ( "协程1" ) sleep ( 2 ) g2 . switch ( ) print ( "协程1恢复运行" ) def func2 ( ) : print ( "协程2" ) sleep ( 1 ) g3 . switch ( ) def func3 ( ) : print ( "协程3" ) sleep ( 1 ) g1 . switch ( ) if __name__ == '__main__' : # 使用greenlet来创建三个协程 g1 = greenlet ( func1 ) g2 = greenlet ( func2 ) g3 = greenlet ( func3 ) # print(g1) g1 . switch ( ) # 让协程g1取抢占cpu资源 ''' 协程1 协程2 协程3