经过前两次的性能优化之后，系统性能已经得到了很大提升，不存在登陆页面打不开的情况。
又经过一段时间的观察，发现系统有如下两个比较明显的问题：
1、登进系统之后点菜单，能明显感觉到系统有停顿
2、个别实例偶尔会宕掉
当时拿到这两个问题的时候，比较没有头绪，尤其是第一个问题，不知道从哪里下手。所以，挑了一个感觉比较好定位的问题2入手。
查看了实例的日志文件，发现已经有一段时间没有往文件里面写入日志了。说明这个应用已经停止服务了。既然停止服务，当时推测认为要么实例进程已经停掉了，要么虚拟机进程宕掉了，即内存溢出了。
用ps -exf|grep 服务关键字 命令查了一下服务进程，发现进程还在，基本排除第一种推测。
然后针对第二种推测，使用jstat -gcutil pid 1000 1000 观测了一段时间的垃圾回收情况，发现老年代的内存使用率一直是100%。
看到这种结果，已经可以明确确定是虚拟机内存溢出了。这也就证明第二种推测是正确的。
正在得意的时候，发现另一个惊喜：那就是fullGC的次数比minorGC的次数要多的多，有经验的同学都知道，老年代的fullGC策略执行的时候，jvm是停止用户线程的响应的。说白了就是fullGC的时候，jvm是不会处理请求的。而这里的fullGC几乎占用了全部GC的时间，说明在很大的一段时间内，jvm不提供对外服务。
看来病灶我们已经找到，接下里就要对症下药了。
从jstat监控结果来看，每进行一次minorGC，就会进行一次fullGC，也即是说新生代的内存空间小。因为新生代分为三个区域：eden区，程序new出来的对象都是放到这里的。
s1区，当minorGC的时候，eden区会将没有被回收的数据放到s1
s2区，当minorGC的时候，s1区会将没有被回收的数据放到s2
由于我们没有设置新生代的大小，也没有设置幸存区和eden区的比率，所以新生代的内存空间很小。这样每次minorGC的时候，由于没有足够的内存来存储存活下来的对象，那么只能把数据对象放到老年代。这样相当于程序new出来的对象经新生代转调一下直接进入了老年代，那么照此发展下去，老年代很快就会内存不足，没有足够空间容纳对象的时候，就会触发fullGC。
所以我们要调大新生代的空间，这样保证有足够空间来存放程序new出来的对象，并保证在经过多次minorGC之后，只有很好一部分对象能存活下来。这也正是我们系统的特点，会生成很多生命周期较短的对象，它们可能在一次minorGC不会被回收，但是在多个minorGC之后一定会被回收。所以我们要新生代，有足够的空间让对象自生自灭，不要存活到老年代。
调整新生代的jvm参数
-Xmn1024m
-XX:survivorRatio=2
相关参数的含义，不在这里解释，不明白的大家百度一下。
经过这三仗打下来，我们的系统运行基本稳定，没有再出现性能问题。
只要我们有问题终究会被定位并且解决的信念，那么我们战无不胜，以此和大家共勉，谢谢~~