在之前已经详细对CMS垃圾回收器进行了学习，今天准备要学习另一个全新的垃圾收集器---G1（Garbage First Collector 垃圾优先的收集器），说是一种全新的，其实G1垃圾收集器已经出现了N多年了，只是从发展到成熟是需要经历一定的过程，oracle官方计划在jdk9中将G1变成默认的垃圾收集器，以替代CMS， 可见G1肯定有它独特的地方，它跟我们之前所学的各种垃圾底层是完全不一样的，比如最明显的不同是以前的分代收集方式是将堆划分为新生代、老年代两个区域，而新生代又划分为Eden和两个Survivor，也就是从物理的结构就明确的做了区域划分，但是！！！G1它依据的物理形态跟我们之前所接触的垃圾收集器完全不一样了，也就是明显会感觉到G1里面的堆内存没有明显的区域划分的，也就是这一块区域是新生代，那一块区域就是老年代了，所以接下来也是从理论开始学习，之后再用实践来论证理论：
吞吐量：
- 吞吐量关注的是，在一个指定的时间内，最大化一个应用的工作量。
- 如下方式来衡量一个系统吞吐量的好坏：
1、在一个小时内同一个事务（或者任务、请求）完成的次数（tps，实际中还会经常见qps，每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准）。
2、数据库一小时可以完成多少次查询。 - 对于关注吞吐量的系统，卡顿是可以接受的，因为这个系统关注长时间的大量任务的执行能力，单次快速的响应并不值得考虑。
响应能力：
- 响应能力指一个程序或者系统对请求是否能够及时响应，比如：
1、一个桌面UI能多快地响应一个事件。
2、一个网站能够多快返回一个页面请求。
3、数据库能够多快返回查询的数据。 - 对于这类对响应能力敏感的场景，长时间的停顿是无法接受的。
以上是用来评价一个系统的两个很重要的指标，介绍这两个指标的原因是因为G1就是用来解决这样的问题而应运而生的。
G1 Garbage Collector：
- g1收集器是一个面向服务端的垃圾收集器，适用于多核处理器、大内存容量的服务端系统。
- 它满足短时间gc停顿的同时达到一个较高的吞吐量。
- JDK7以上版本适用【通过配置JVM的参数来指定既可】。
以上可以看到G1在吞吐量和响应能力上都进行了兼顾。
G1收集器的设计目标：
- 与应用线程同时工作，几乎【注意措辞】不需要stop the world(与CMS类似)；
- 整理剩余空间，不产生内存碎片（CMS只能在Full GC时，用stop the world整理内存碎片）。
- GC停顿更加可控；【对于CMS来说如果出现了Full GC时，则会对新生代和老年代的堆内存进行完整的整理，停顿时间就不可控了】
- 不牺牲系统的吞吐量；
- gc不要求额外的内存空间（CMS需要预留空间存储浮动垃圾【这个在学习CMS中已经阐述过了，其实就是CMS回收的过程跟用户线程是并发进行的，所在在标记或者清除的同时对象的引用还会被改变，使得原来对象本来不是垃圾，当CMS清理时该对象已经变成了垃圾了，但是CMS认为它还不是垃圾，所以该对象的清除工作就会放到下一次了，所以将这种对象则称之为浮动垃圾】）