JVM的GC-生命不能承受之重

严重怀疑是设计上的问题，但是楼主并没有详细说明应用的情况，希望楼主能更详细说下，另外应该避免生成大量对象，调用量大和数据量大并不能成为大量生成对象的理由。

如果是设计问题的话，在jvm上打转转就没有意义了。

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

你可以看看JROCKIT， 不过， 不知道要不要钱。。。。

首先服务器的环境是多cpu的，而能够利用多cpu的有效方式应该是多进程。不过似乎linux环境下java的多线程仍然类似于多进程？不清楚。 不过还是认为启动多个jvm，进行集群，这样利用cpu的效率会最高。

jvm 维护 3G 的 cache 太沉重了，建议使用另外一个东西负责 cache，例如memcacheserver 之类的东西，cache 应该是一个仓库，让jvm背着一个这么大的仓库做运动，才是jvm不能承受之重呀。

你火星来的啊。。。。。哈哈

采用独立于应用的cache方案.

你应该只是不能容忍那个停顿，但把负荷从5000降到4000不知可不可以接受。
搞个计数器，每xxx次调用强制gc一次，强制分摊gc开销到xxx次操作里头。
jrocket好像就有个强制提高gc频率的参数。
还有就是，真的需要生成那么多临时对象吗？

程序设计的问题，调JVM的参数是没用的。
与其在这里质疑和抱怨JVM，不如看看如何修改架构的。最初提出这样做的人就应该拖出去打。

完全是程序设计问题。java里面不要cache太多东西，否则gc很慢。假如1000个对象，就需要不断的检查1000个对象的引用关系才能gc。