JVM调优，S区太小导致FGC频繁 200
通过jmap -heap pid查看，发现其S区分别为0.25M和1.4375M（不同时间结果不同），而且该应用每次FGC均由YGC触发。我知道SurvivorRati的默认值为8，有什么办法调整控制其FGC 展开
JVM是最好的软件工程之一，它为Java提供了坚实的基础，许多流行语言如Kotlin、Scala、Clojure、Groovy都使用JVM作为运行基础。一个专业的Java工程师必须要了解并掌握JVM，接下来就给大家分享Java基础知识中JVM调优相关知识点。
杭州Java基础知识学习之JVM调优讲解
JVM常见的调优参数包括：
-Xmx：指定java程序的最大堆内存, 使用java -Xmx5000M -version判断当前系统能分配的最大堆内存；
-Xms：指定最小堆内存, 通常设置成跟最大堆内存一样，减少GC；
-Xmn：设置年轻代大小。整个堆大小=年轻代大小+年老代大小。所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8；
-Xss：指定线程的最大栈空间, 此参数决定了java函数调用的深度, 值越大调用深度越深, 若值太小则容易出栈溢出错误(StackOverflowError)；
-XX:PermSize：指定方法区(永久区)的初始值,默认是物理内存的1/64，在Java8永久区移除, 代之的是元数据区，由-XX:MetaspaceSize指定；
-XX:MaxPermSize：指定方法区的最大值, 默认是物理内存的1/4，在java8中由-XX:MaxMetaspaceSize指定元数据区的大小；
-XX:NewRatio=n：年老代与年轻代的比值，-XX:NewRatio=2, 表示年老代与年轻代的比值为2:1；
-XX:SurvivorRatio=n：Eden区与Survivor区的大小比值，-XX:SurvivorRatio=8表示Eden区与Survivor区的大小比值是8:1:1，因为Survivor区有两个(from, to)。
JVM实质上分为三大块，年轻代(YoungGen)，年老代(Old Memory)，及持久代(Perm，在Java8中被取消)。
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：并发垃圾收集信息、持久代并发收集次数、传统GC信息、花在年轻代和年老代回收上的时间比例。
减少年轻代和年老代花费的时间，一般会提高应用的效率。
吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩。
不是要手工控制，而是希望通过调整配置使其运作更优。
该应用现在S区的大小目前并未明确指定，按照默认值，其大小应为新生代的10%（默认比值为8）。可实际上远小于此值。导致的结果就是，每次YGC都必然触发FGC。而FGC会冻结heap，所以，希望通过扩大S区的方式，减少FGC，这对应用来说是非常有益的。
另，这句话to百度知道：本回答并未深入问题实质，所谓的“网友推荐”是指谁，请不吝指明！
