jvm垃圾收集器和吞吐量响应时间

G1详解：转载：https://www.jianshu.com/p/35805f809a21

转载：https://blog.csdn.net/coderlius/article/details/79272773
吞吐量和响应时间：https://blog.csdn.net/cyywxy/article/details/81201588
高吞吐量和暂停时间是矛盾的。为了提高吞吐量，就要尽量减少GC的发生，但是GC发生的次数少了，每次要回收的对象就会多，那暂停时间就会长。
具体场景：https://www.cnblogs.com/yeyang/p/9131141.html
响应时间
响应时间指的是应用对请求的响应时间，如：

一个桌面应用对时间的响应时间
网站返回一个页面的时间
数据库查询结果返回时间
对于专注于最小响应时间的应用，长时间停顿是无法接受的。

吞吐量
吞吐量专注于应用在一段时间的的最大工作量。如：

给定时间内完成的事物数
每小时批处理程序能够完成的任务
每小时数据库可以完成的查询操作数
较长停顿时间在此情况下是可以接受的。比起低响应时间，吞吐量优先应用更看重一段时间内的表现。

在不面向用户的应用程序中，可能并不关注停顿时间，而是关注总体的执行效率，这时GC的吞吐量可以理解为回收一定内存所需的时间。

Parallel Scavenge更注重吞吐量，用在新生代；CMS更注重响应速度，希望停顿时间最短，但可以次数稍微多一点，用在老年代。所以这两个不可以一起使用

CMS:https://blog.csdn.net/wfh6732/article/details/57490195
.CMS缺点
CMS回收器采用的基础算法是Mark-Sweep。所有CMS不会整理、压缩堆空间。这样就会有一个问题：经过CMS收集的堆会产生空间碎片。 CMS不对堆空间整理压缩节约了垃圾回收的停顿时间，但也带来的堆空间的浪费。为了解决堆空间浪费问题，CMS回收器不再采用简单的指针指向一块可用堆空 间来为下次对象分配使用。而是把一些未分配的空间汇总成一个列表，当JVM分配对象空间的时候，会搜索这个列表找到足够大的空间来hold住这个对象。
需要更多的CPU资源。从上面的图可以看到，为了让应用程序不停顿，CMS线程和应用程序线程并发执行，这样就需要有更多的CPU，单纯靠线程切 换是不靠谱的。并且，重新标记阶段，为空保证STW快速完成，也要用到更多的甚至所有的CPU资源。当然，多核多CPU也是未来的趋势！
CMS的另一个缺点是它需要更大的堆空间。因为CMS标记阶段应用程序的线程还是在执行的，那么就会有堆空间继续分配的情况，为了保证在CMS回 收完堆之前还有空间分配给正在运行的应用程序，必须预留一部分空间。也就是说，CMS不会在老年代满的时候才开始收集。相反，它会尝试更早的开始收集，已 避免上面提到的情况：在回收完成之前，堆没有足够空间分配！默认当老年代使用68%的时候，CMS就开始行动了。 – XX:CMSInitiatingOccupancyFraction =n 来设置这个阀值。
总得来说，CMS回收器减少了回收的停顿时间，但是降低了堆空间的利用率。

内存分配比例：http://engineering.xueqiu.com/blog/2015/06/25/jvm-gc-tuning/
该给Java进程配置多大的堆？
换个方式问这个问题： 大堆、小堆对Java进程会有怎样的影响？

对Java程序而言，堆大小最大的影响的在于垃圾回收STW的时间。因此，对在意吞吐量而不在意响应时间的应用，堆可以设置的很大。
而对于响应时间要求比较高的应用，堆大小则需要仔细考虑。设小了，会导致频繁gc，gc效率太低；设大了，则STW的时间太长，无法满足时延要求。

G1的优先回收价值最大的区域是指判断哪些region几乎是空的，优先把这些给回收了。G1会建立推测模型来判断每次回收哪些区域，回收时会把该区域对存活对象赋值到一个空的region中以此来解决内存碎片的问题。