1.启动参数：
-Xmx8g -Xms8g -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=30 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=2 -XX:+PrintGCDetails -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintHeapAtGC -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=52001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=xx.xx.xx.xx
参数含义见：jvm-G1
2.运行5天+
3.刚启动时监控：
平均在50ms
4.5天后监控：
平均在150ms，还在上涨
5.问题已经很明显了
就是随着使用的时长延续，导致yonggc tp拉高，我的应用是每天拉高10~20ms左右，这个对于提供webServcie服务也是不能接受的。
5.1只能了解下G1的工作原理
G1本质上也有分代回收，只不过从内存划分上和cms等回收方式有了很大的不同
cms等回收器，内存分配，还是eden区---Survivor--old
cms回收器，内存回收算法，复制算法+标记整理+标记清除
g1回收器，内存分配，将整个堆空间，全部打散分成 X mb的空间，X是可以设定的-XX:G1HeapRegionSize=Xm X是2的n次幂，2~32m（我的机器设置的16m，分块数=8*1024/16=512块）。
区域：Eden区 Survivor区 Old区 Humongous区。 这里Humongous区是巨大的空间，也就是连续的region组成的。如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。
g1回收器，内存回收算法，复制算法+
g1-yonggc:
阶段1：根扫描静态和本地对象被扫描
阶段2：更新RS处理dirty card队列更新RS
阶段3：处理RS检测从年轻代指向年老代的对象
阶段4：对象拷贝拷贝存活的对象到survivor/old区域
阶段5：处理引用队列软引用，弱引用，虚引用处理
g1-mixgc:
初始标记（initial mark，STW）在此阶段，G1 GC 对根进行标记。
根区域扫描（root region scan）G1 GC 在初始标记的存活区扫描对老年代的引用，并标记被引用的对象。该阶段与应用程序（非 STW）同时运行，并且只有完成该阶段后，才能开始下一次 STW 年轻代垃圾回收。
并发标记（Concurrent Marking）G1 GC 在整个堆中查找可访问的（存活的）对象。该阶段与应用程序同时运行，可以被 STW 年轻代垃圾回收中断
最终标记（Remark，STW）该阶段是 STW 回收，帮助完成标记周期。G1 GC 清空 SATB 缓冲区，跟踪未被访问的存活对象，并执行引用处理。
清除垃圾（Cleanup，STW）在这个最后阶段，G1 GC 执行统计和 RSet 净化的 STW 操作。在统计期间，G1 GC 会识别完全空闲的区域和可供进行混合垃圾回收的区域。清理阶段在将空白区域重置并返回到空闲列表时为部分并发。
以上是原理，我的问题和cms的Stringtable问题，可能相似，发生一次mix gc 是不是会清理掉，yonggc清理不掉的垃圾呢？
那怎们设置呢？还记得-XX:InitiatingHeapOccupancyPercent参数吗？就是干这个用的，我能接受的yonggc tp对应的当时场景的old heap是1g左右，那么-XX:InitiatingHeapOccupancyPercent=1g/8g 大概等于12% 那这个值就改成12试试~
持续观察，未完待续~~~
02-05监控图有点奇怪：
02-07监控越来越恶略：
