JVM 参数学习--实际参数设置

对于JDK8。其中不准确或错误的的地方 请指出

1。 基本参数：
-Xms = 2048m 最小内存
-Xmx = 2048m 最大内存。如果不设置，空间不足的时候，会一直扩大，影响服务器性能。开始不懂没有设置也会被鄙视！
设置为一样 避免垃圾回收进行重新分配内存（话是这么说）
-Xmn = 1024m 年轻代。 大小设置 如果希望对象快速进入年老代可以 设小一些。

ps：年轻代分两部分 eden区、survivor区。
所有 新创建的对象 第一个进入的就是 eden区。
YGC回收活下来的 （YoungGC）
进入 survivor的 “to”区 （survivor有from区与to区，to区都是空的！为什么？待会儿说）。
每个对象都会记录 经过几次gc 存活下来。

eden → survivor“to”。

YGC针对的是年轻代 所以survivor 也会被回收。然后to区是空的。瞎吗上面不是到to区了吗！
从survivor“from”活下的也进入survivor的“to”区（刚刚说有记录经过多少次YGC活下来，是的，活到一定次数（这个次数你可以自己设置）就进入年老代了不去to区了）。 等等 to 区有了 ， 你骗人啊！不是说空的吗！
啥！啥！啥！以下语速加快200个百分点
YGC完成清空eden区survivor“from”区。
survivor“to”区 改名字变成 “from”。“from”区不是刚刚被清空了吗，改名叫做“to”区
→_→ 你看看，是不是 “to”区 是空的吧！ 曾经拥有。。。 Who care？ 哈哈哈。
转移的时候to空间不够的话 活下来的会直接进入 年老代 （怪只怪to区太小，后来者居上！直接退休（总会被回收的，不怕年老代也会GC哦））

还有年老代，元空间（原先是永久代，不仅仅是改名字哦）

Young（eden|survivor（from|to））|Old|MetaSpace
差不多这个样子。

回来继续说参数！

-XX:NewRatio=4 这个是 年老代空间与年轻代空间的比例 old/young = 4
（上面已经设置了年轻代的大小 这个可以不用设置啦）
-XX:SurvivorRatio=4 这个是 eden 与 survivor 空间比例 eden/survivor = 4 （ps survivor 有两个！）
这个是调优的一个重要参数！因为我说过to区是空的！就是说to区一直都是空置的 不得不浪费。
长这个样子 EEEE SS 看懂了吗 = = ok 就这样。 5的话就是这样 EEEEE SS

-XX:MaxTenuringThreshold = 7 第8次没死 就可以去年老区养老啦。每个对象被YGC的次数都会记下来超过这个阈值就会进入年老区 就是前面说的 survivor “from”正常进入 old

这个设置 默认是15 ? 自己随便设置一下吧 挺重要的。 这个时候就要考虑自己应用YGC活下的对象需要进入年老区的一般需要经历多少次的GC 。慢慢调。

-XX：+UseCompressedOops 使用（+开启 -关闭） 貌似默认开启 所以 不设置呗。
干嘛用的， 64位机子压缩数据长度的? 自己看哈。
参考 http://www.cnblogs.com/magialmoon/p/3757767.html

2。垃圾回收配置

先看看有哪些垃圾回收器。 选好策略很重要要
①Serial GC（-XX:+UseSerialGC）：Serial GC使用简单的标记、清除、压缩方法对年轻代和年老代进行垃圾回收。
试用： 各种低配 jvm
②Parallel GC（-XX:+UseParallelGC）：进化版Serial GC。 多线程回收年轻代，单线程回收年老代。
③Parallel Old GC（-XX:+UseParallelOldGC): 进化版Parallel GC。 想想就知道干了啥吧。 年老代也多线程了。
④CMS GC（-XX:+UseConcMarkSweepGC)：这个是并发短暂停顿的多线程回收。针对年老代的回收。这个除了标记是独占系统资源其他动作都是与应用并发进行的！66的。 Parallel Old GC这个是所有动作独占系统资源的，回收年老代的时候，应用不能动哦。（新JVM中 -XX:+UseParNewGC 启用这个CMS是 这个也会启动，所以 年轻代的回收 就会变成 并行的！ 感觉像是Parallel Old GC在老年代改了一下。）
PS：用这个的话 -XX:NewRatio这个配置是不会生效的 但是 直接设置年轻代 Xmn这个还是可以的。
⑤G1 GC ：区别 堆结构不要求连续！ 就是那里一块年轻代 这里一块年轻代 随便放！
切块很多部分小 Y、O，每次一小部分进行回收。
参考：
http://ifeve.com/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3g1%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86%E5%99%A8/
据说：（我不负责的，我并没有测试过）吞吐相对 CMS GC差！虽然延时好一丢丢。

我用的是CMS 以此来举例。

-XX+UseCMSCompactAtFullCollection 加吧，可以压缩碎片。CMS不会移动内存，容易产生碎片（内存利用率低，容易触发FULLGC，这里说一下GC 还是只有两个 jasta 可以看见 YGC ，FGC 。 CMS 有的时候会引起较多的FULLGC = = 但是相对其他的回收器而言即使次数多但是时间短！）这个会在FULLGC 之后进行 碎片整理，以提高内存利用率 。
可以通过 -XX：CMSFullGCsBeforeCompaction=2 设置fullgc几次 后进行压缩碎片

-XX：CMSInitiatingOccupancyFraction=68 默认的是68 如果年老区数据稳定，可以通过增加这个值减少CMS 启动的次数。
搭配-XX:+UseCMSInitiatingOccupancyOnly 每次都是用这个配置进行CMS回收 不加的话后面的数值就都是 HotSpot VM 算出来的 你的68也就是 第一次生效而已。
调优手段之一
这个值其实 看CMS gc 是不是频繁，而且空间是否可用。其实我不想设置，自己算嘛。而且各个参数的配置的不合理会导致 promotion failed！这个是啥？ 百度！

-XX：+DisableExplicitGC 拒绝手动GC 关闭 System.gc();

-XX:+HeapDumpOnOutOfMemoryError OOM的时候生成dump 快照文件

* -XX:+UseParNewGC* 年轻代并行回收 不想开启的话 可以 -XX:-UseParNewGC

-XX:+UseFastAccessorMethods 原始类型的快速优化。 偶尔会进行推荐。JDK 7 之后默认false。
why？ 参考：http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005057.html

-XX:+ExplicitGCInvokesConcurrent 添加后 CMS GC开始会触发FULLGC 。
CMS GC 耗时其实更多 所以 QPS 要求高的 不要频繁CMS GC

以上供参考。欢迎指出其中的不足。