gc

标记清除是JVM用于垃圾回收的基本算法 标记清除算法中，引用会从每个线程栈的桢指向程序的堆 从栈开始，循着指针找到所有可能的引用，然后再循着这些引用递归下去。 当递归完成，就找到了所有活对象，其它都是垃圾。 运行时环境本身也有一个“分配清单（allocation list）”，上面列出了指向每个对象的指针 该列表由垃圾回收器负责维护，并帮助垃圾回收器进行垃圾清理。 因此，运行时环境总是可以找出由它创建但尚未回收的对象。 G1 垃圾回收器针对大内存多核 CPU 的环境，目的在于减少 Full GC 带来的暂停次数，增加吞吐量。 从长远来看，G1 会代替 Concurrent Mark-Sweep Collector（CMS）。 G1 在堆上分配一系列相同大小的连续区域，然后在回收时先扫描所有的区域，按照每块区域内存活对象的大小进行排序，优先处理存活对象小的区域，即垃圾对象最多的区域，这也是 Garbage First 这个名称的由来。 G1 把要收集的区域内的存活对象合并并且复制到其他区域，从而避免了 CMS 遇到的内存碎片问题。 此外，G1 采用了一个可预测暂停时间模型来达到软实时的要求。 参考文献: 可视化Java垃圾回收: http://www.infoq.com/cn/articles/Visualizing-Java-Garbage-Collection

GC分类 针对HotSpot VM的实现，它里面的GC其实准确分类只有两大种： Partial GC：并不收集整个GC堆的模式 Young GC：只收集young gen的GC Old GC：只收集old gen的GC。只有CMS的concurrent collection是这个模式 Mixed GC：收集整个young gen以及部分old gen的GC。只有G1有这个模式 Full GC：收集整个堆，包括young gen、old gen、perm gen（如果存在的话）等所有部分的模式。 说明 Major GC通常是跟full GC是等价的，收集整个GC堆。但因为HotSpot VM发展了这么多年，外界对各种名词的解读已经完全混乱了，当有人说“major GC”的时候一定要问清楚他想要指的是上面的full GC还是old gen。 最简单的分代式GC策略，按HotSpot VM的serial GC的实现来看，触发条件是： young GC：当young gen中的eden区分配满的时候触发。注意young GC中有部分存活对象会晋升到old gen，所以young GC后old gen的占用量通常会有所升高。 full GC：当准备要触发一次young GC时，如果发现统计数据说之前young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young

Erlang中每个进程都有独立的堆内存，默认的大小是233个words（可配置），并以 Fibonacci序列的顺序增长（233对应fib(11)）。不过，当堆内存增大到一定程序时，增长速度减缓，比如内存大于fib(35)=14M的时候，堆内存开始不以Fibonacci序列增长（具体参见[$R15B_OTP_SRC/erts/emulator/beam/erl_gc.c --> erts_init_gc]里的说明）。一般情况下，进程所用到的数据都放在各自的堆内存中。 Erlang的GC机制跟其它语言（比如Java）相比，很重要的一点是，它的GC是以进程为单位进行的（一般情况下，GC搜索的根对象主要包括进程栈以及进程信箱中的对象）。Erlang系统中，GC进行时，会挂起整个系统（当前结点上的所以调度队列），也就是说它的GC也是“stop the world”。但是，就算一个系统中有大量进程，总共占用几个G的内存，它的GC的延迟也会很低，这是因为每个进程可能只使用很小的内存（比如20K），在这么小的内存上进行GC所花费的时间很小，基本可以忽略不计。 在Erlang中可以通过spawn_opt来指定初始堆内存大小，如果这个数值足够大（需要诊断后确定），那么就可以完全避免GC。进程在销毁时，统一收回其所拥有的所有堆内存，而不需要进行GC，因为堆内存是每个进程私有的。 Erlang中

RGW S3 GC类的主要功能是提供垃圾收集器的功能。用于异步删除对象。 一、RGW S3 GC核心类关系图 二、RGW S3 GC核心数据类关系图 三、RGW S3 GC主要处理函数解析。 1、RGWGC初始化操作。 RGWGC::initialize() |__设置cct和store类对象 |__从配置文件中得到gc最大对象个数，即：rgw_gc_max_objs |__根据gc最大对象个数生成obj_names数组且初始化该数组的内容为gc.0-rgw_gc_max_objs 2、RGWGC终止操作。 RGWGC::finalize() |__删除obj_names数组 3、添加chain。 RGWGC::add_chain() |__cls_rgw_gc_set_entry() |__rgw_cls_gc_set_entry() |__gc_update_entry() |__gc_omap_get() |__cls_cxx_map_get_val() 以名字为key，得到Ceph集群中已经保存的cls_rgw_gc_obj_info信息(CEPH_OSD_OP_OMAPGETVALSBYKEYS) |__get_time_key() 得到time key |__gc_omap_remove() |__cls_cxx_map_remove_key() 删除指定time

jvm基础： https://www.cnblogs.com/clamp7724/p/11750764.html 调优这方面- -其实除了架构师基本用不到，知道基本原理和简单的调优就可以了。。。 调优一般是调优 方法区 和 堆 方法区： 存放方法的信息（变量，常量，类信息，运行时常量池等） 堆（GC发生在这里）： 存放对象实例 1.堆 1.1 新生代区 1.1.1 伊甸区 （西方神话人类起源地-。-） 1.1.2 survivor from （幸存者from区） 1.1.3 survivor to （幸存者to区） 1.2 老年代区 内存比例： 新生代：老年代 = 1 : 2 伊甸区：survivor from ：survivor to = 8:1:1 GC机制： （survivor from 和 survivor to 直接写成from 和 to） 1. 一个对象实例A被声明后进入堆的新生代伊甸区 2. 根据GC策略（比如GC发现没有指向A的变量了，或者伊甸区满了等），A进入from区 3. from满了以后，触发Miner GC（轻GC），把from区的一部分幸存者数据放到 to区，2区互换（A还是在from区，只不过是之前的to区），清的to区（之前的老from区，没被复制到to区的都被清空了= =）。新来的开始进入新from区。 4. 新from区满了以后，重复以上步骤

简介 通过压力测试查看xwiki的gc情况，统计分析gc日志，在不改变总内存使用的情况下做出合理调整，通过压力测试聚合报告对比调优效果。 步骤 运行程序，增加打印GC日志的参数； 使用badboy + jmeter对web程序的单个页面（首页）进行压力测试，压力测试参数为10线程，每线程执行100次测试； 使用jstatd + jvisualVM实时查看或gcviewer分析GC日志； 根据分析结果，调整JVM参数； 分析结果达到预期，结束，否则继续执行1～4。 工具 Badboy - 录制jmeter脚本 Jmeter - 压力测试 Jstatd - 提供远程使用jvisualVM实时看gc情况服务 jvisualVM - 查看gc情况 Gcviewer - 分析GC日志 测试环境 虚拟机 CPU 8核，内存 8G 操作系统 CentOS6.5 JDK: 1.7 第一轮：使用默认参数 运行web JVM参数 -Xmx512m -XX:MaxPermSize=196m -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:$LOGSDIR/xwiki.gc -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M -XX:

JAVA运行时内存区域 程序计数器 一块很小的内存空间 当前线程所执行的字节码的行号指示器 当前线程私有 不会出现OutOfMemoryError情况 java虚拟机栈 通常存放基本数据类型，对象引用（一个指向对象起始地址的引用指针或一个代表对象的句柄），reeturnAddress类型（指向一条字节码指令的地址） 线程私有，生命周期与线程相同 java方法执行的内存模型，每个方法执行的同时都会创建一个栈帧，存储局部变量表(基本类型、对象引用)、操作数栈、动态链接、方法出口等信息 StackOverflowError异常：当线程请求的栈深度大于虚拟机所允许的深度 OutOfMemoryError异常：如果栈的扩展时无法申请到足够的内存 本地方法栈 与虚拟机栈相似，主要为虚拟机使用到的Native方法服务，在HotSpot虚拟机中直接把本地方法栈与虚拟机栈二合一 和虚拟机栈一样可能抛出StackOverflowError和OutOfMemoryError异常。 Java堆(Java Heap) java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此区域的唯一目的就是存储对象实例。java堆是垃圾收集器管理的主要区域。java堆还可以细分为：新生代与老年代。再细一点有Eden空间、Form Survivor空间、To Survivor空间等。 可以通过-Xmx和

垃圾回收（Garbage Collection， GC）主要需要考虑的问题： 哪些内存需要回收？ 什么时候回收？ 如何回收？ 哪些内存需要回收 虚拟机栈、本地方法栈、程序计数器由于是线程独有，且栈帧的内存大小在类结构确定时已经相对确定所以不需要考虑回收问题，方法结束或线程结束自然回收。需要回收的是Java堆以及方法区 什么时候回收以及如何回收 在一个对象不可能再被任何途径使用时回收； 微软的COM（Component Object Model）技术、使用ActionScript3的FlashPlayer、Python语言和Squirrel使用了引用计数算法进行内存管理，而主流商业语言（Java、C#、Lisp等）主流实现算法都是可达性分析算法。 引用计数算法（Reference Counting）：给对象添加一个引用计数器，当有一个地方引用它时，计数器加1，引用失效计数器减1，当计数器为0时，表示此对象不再被引用，可以回收；缺点：无法解决对象相互循环引用问题 可达性分析算法（Reachability Analysis）：通过一系列称为“GC Roots”的对象作为起始点，从这个点开始向下搜索，所走的路径称为引用链（Reference Chain），当一个对象没有任何引用链也GC Roots相连时，将对对象进行第一次标记并通过该对象的分析（1.是否重写了finalize()方法，2

Full GC、Minor GC和Major GC的区别 Minor GC：发生在新生代的垃圾收集动作，因为JAVA对象大部分都具备朝生夕灭的特效，所以Minor GC会比较频繁且回收速度比较快 Major GC/Full GC 指发生在老年代的垃圾回收动作，出现Major经常会出现一次Minor GC，Major GC的速度一般会比Minor GC 慢10倍 来源： https://www.cnblogs.com/jakaBlog/p/11767894.html

-verbose:gc -XX:+PrintGCDetails 文章来源: java GC 运行参数设置