JVM的GC

我们有一个要求非常高性能的应用，其实也是部署在一台普通的PE2850上面。4CPU，内存8G，JVM的heap开了5G，其中新生代为1.5G。在高峰期每秒超过5000次调用，约3秒就需要minor GC一次，每次停顿约0.3秒。隔十分钟左右就要Full GC一次，需要停顿约10秒。有点受不了。这样相当于每隔3秒应用就要停顿0.3秒，每隔10分钟就要停顿10秒。也改成CMS试过，Full GC的停顿会减少，但minor GC照样。这样的效果，对于一些高性能的应用来算，GC可能真是无法承受之重

引用

1、GC这么频繁也很有可能是代码质量问题。我们前段时间一个服务用Java写的，刚上线也是GC极其频繁，2分钟就Full GC一次，每次FullGC要2-3秒，后来进行了代码优化，把频繁申请释放的资源进行了缓存，负载立刻降低，2个多小时才Full GC一次，每次FullGC只要0.3秒。

2、你的Heap开得太大了，GC无可避免的要很慢，Heap建议最大就2GB，不要再大了。

3、如果你内存和CPU资源比较空闲，更好的办法是启动多个JVM进程做个垂直群集。这样每个JVM进程的负载会被分散，Heap也不用开的那么大了，GC也仅仅打断当前进程，而其他进程照样正常处理请求。所以说鸡蛋不必都放在一个篮子里面。

引用

1、heap肯定大了，调小
2、肯定要采用cms
3、适当增大新生代的比例
4、设置XX:MaxTenuringThreshold，这个参数用来设置新生代对象撑过多少轮minor gc才进入年老代，默认是0，也就是说直接进入年老大，触发full gc的频率大大增加。

引用

full gc 肯定要stop-the-whole-world的，它要遍历整个对象网络这是所有有垃圾收集器的语言无法避免的问题。minor GC也是stop-the-whole-world

引用

因为minor gc一般是用copying collector，对象会被移动，基本上必须stop world
而full gc一般是mark sweep collector，这个不移动对象，可以并行的