商品接口运行状况
商品接口是印尼平台的基础服务，运行期间大对象不多，查询接口大多也有分页数量的限制。大boss也为关键接口设定了削峰计划——tp99不超过200ms。大多数情况下系统满足该要求，但是偶尔会有超过200ms的情况，一部分是由于查询数据量过大数据库响应和数据组装耗时所致，而另一部分则和jvm有关。
通过观测发现，jvm进行一次young gc耗时在100ms以上，full gc耗时更是达到了1s左右，大概一天一次，部分超过200ms的调用恰恰就在gc的节点上。
调优之前的策略
调优之前使用部署系统默认的垃圾收集策略，即parallel Scanvenge，堆空间2g，出现的问题是：
- 永久代初始内存64M设置过小
- Minor gc时间过长，平均一次超过100ms
- 垃圾收集的并行线程数43个，服务器是2核，线程数偏多
4 一次full gc耗时1s左右
使用g1进行调优
直接给出最后的调优参数
-xmx2560m
-xmn2560m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:InitiatingHeapOccupancyPercent=60
-XX:ParallelGCThreads=4
-XX:ConcGCThreads=4
-XX:G1ReservePercent=10
-XX:G1MixedGCCountTarget=4
-XX:PermSize=128m
-XX:+UnlockExperimentalVMOptions
-XX:G1NewSizePercent=15
-XX:+PrintAdaptiveSizePolicy
-XX:G1HeapWastePercent=5
调整点如下：
- 内存最大4g，刚开始给了堆3g，后面发现会出现内存使用率达到99%的情况，因此改为2560m。事实上使用g1官方推荐至少6g，这里条件限制没有办法，可不可以使用cms呢，当然是可以的。
- 停顿目标为100ms，这是和老大商议的结果，设置过低可能造成g1很频繁的young gc。
- 启动并发阶段的阈值为60%，刚开始设定为85%，偏高了，存在并发失败导致full gc的可能。
- 并行收集线程数为4，两核cpu，这个值可以了
- 并发收集线程数为4，根据mix gc的耗时可动态调整，数量不宜过多。
- mix gc的次数设置为4，通过几次dump发现老年代里面的垃圾大部分在g1的清理阶段回收了，少部分在mix gc阶段回收。
- 打印自适应调整的日志，很重要！可以看到调整的原因，对于排查问题很有用
- 启用实验参数，设置最低新生代比例为15%，未设置时发现g1在老年代中对象越来越多时会压榨年轻代，造成年轻代过小从而young gc频率很高；设置可浪费老年代比例5%，超过5%才进行mix gc；保留内存10%，这个是为了避免对象晋升时的to-space overflow的问题
调优之后的效果：
- young gc平均耗时不到50ms（包括mix gc）
- 未出现full gc
- 一次并发阶段周期为一天
观察dump文件发现存在大量的char数组，并且这些数组内容一模一样，大小1.15m。g1本身存在一个很大的弊端，即如果一个对象大小超过一个分区的一半则直接进入老年代，对于不到4g的堆空间，默认一个分区大小是1m。这里可以选择将分区大小调整为4m，但是更少的分区数会使得g1的自适应调整能力变弱，还是去代码中寻找。（注：这里还有一种策略是在jdk1.8的情况下使用实验参数设置每次young gc时尝试去回收老年代中的大对象，项目jdk1.7不适用）
通过查看数组中的字符内容定位到这些数组是由于一个五分钟的定时任务从数据库查询出商品基本属性过后会将属性json化后全部存入redis，json是字符串，字符串内部是char数组，问题找到了。解决方案也很简单，总共3000多条数据，每次1000条数据存入redis，确保一次存入生产的字符串小于0.5m。经过这一次调整，一次并发阶段周期大概是5-6天。
