吞吐量：对于一些对时延不敏感的应用比如一些后台计算应用来说，吞吐量是关注的重点，它们不关注每次 GC 停顿的时间，只关注总的停顿时间少，吞吐量高。
举个例子：
方案一：每次 GC 停顿 100 ms，每秒停顿 5 次。
方案二：每次 GC 停顿 200 ms，每秒停顿 2 次。
两个方案相对而言第一个时延低，第二个吞吐高，基本上两者不可兼得。
所以调优时候需要明确应用的目标。
GC 如何调优这个问题在面试中很容易问到，抓住核心回答。
现在都是分代 GC，调优的思路就是尽量让对象在新生代就被回收，防止过多的对象晋升到老年代，减少大对象的分配。
需要平衡分代的大小、垃圾回收的次数和停顿时间。
需要对 GC 进行完整的监控，监控各年代占用大小、YGC 触发频率、Full GC 触发频率，对象分配速率等等。
然后根据实际情况进行调优。
比如进行了莫名其妙的 Full GC，有可能是某个第三方库调了 System.gc。
Full GC 频繁可能是 CMS GC 触发内存阈值过低，导致对象分配不过来。
还有对象年龄晋升的阈值、survivor 过小等等，具体情况还是得具体分析，反正核心是不变的。
最后其实还有关于 ZGC 的内容没有分析，别急， ZGC 的文章已经写了一半了，之后会发。
有关 GC 的问题在面试中还是很常见的，其实来来回回就那么几样东西，记得我提到的抓住核心即可。
当然如果你有实际调优经历那更可，所以要抓住工作中的机会，如果发生异常情况请积极参与，然后勤加思考，这可都是实打实的实战经历。
当然如果你想知道更多的 GC 细节那就看源码吧，源码之中无秘密。
个人能力有限，如果有纰漏的地方请抓紧联系我，也欢迎私信联系我
巨人的肩膀https://segmentfault.com/a/1190000021394215?utm_source=tag-newest
https://blogs.oracle.com/jonthecollector/our-collectors
https://www.iteye.com/blog/user/rednaxelafx R大的博客
https://www.jianshu.com/u/90ab66c248e6 占小狼的博客
我是 yes，从一点点到亿点点，我们下篇见。
