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

检查代码，控制对象的生成吧，还有就是在应用程序的jvm里面做大缓存不是一个好主意

不同应用行为不一，比较明确能适用于你的项目的几点：

1. 如果你是用Java 6以前的JDK，而且用了CMS，那么MaxTenuringThreshold这个值会被忽略，意味着只要对象经历了一次minor gc后如果还存活的话，就会被移到old generation.SurvivorRatio这个值会被设成1024，这个值代表Eden space/Survivor space的比率，这代表着CMS希望能够尽早的把对象promote到old generation.所以对于CMS策略，你的new generation不应该设的太大，合适就够。你根据你自己的应用allocation的频率和逻辑来确定多大的new generation是合适的。

2. 采用CMS的话，new generation默认就是用的是ParNew，多线程并行收集。但是这个并不意味着没有stop-the-world，ParNew中间会有一次短暂的stop-the-world. CMS会有两次短暂的stop-the-world。

3. 采用了CMS以后，理想情况是不再出现Full GC。你可以调整一下CMS的参数，哪几个我忘了～～～印象比较深的一个是可以调整CMS开始的时间，比如整个Heap用了60%就开始CMS了，还是整个Heap用了70%才开始CMS；还有几个可以调整freelist的大小啥的～～～

 

 

1、直观感觉设计上会有问题，怎么会有 3G 缓存，不太了解业务
2、如果使用 IBM JVM (JDK1.5)以上，有几个参数可以调整，利用空闲的CPU做GC，不过具体参数忘记了

如果你是个C++ Master，可以考虑使用C＋＋，否则不要谈在这样的应用中用C＋＋
C＋＋用得不好会带来更多你意想不到的问题。

我看是设计上的问题，让jvm做缓存本来就不是什么好主意，除非jvm设计的足够聪明，知道这些对象不需要gc，但是他是不知道的（我的认识范围内是这样的，也许有人知道有更好的方式控制gc），这个是c++中自己申请自己释放的处理方式，在jvm处理不合适。sun的jvm中的许多-XX的选项是没有官方的严格的承诺保证绝对的稳定的，不同的版本有不同的变化，要想了解的足够仔细，要不自己看jvm的源代码，或者购买服务。对于普通的程序员来说，你只能是调整设计，优化。

对于一个工具不擅长做的事情，一定要使用这个工具去做的话，需要很高的水平的，工具永远解决不了设计和人的问题，而且为什么要让采用这种方式呢？

jvm不太需要程序员关心内容的回收，但是不表示，内存回收按照你想像的方式来运行的

我觉得：即使换到c++上还是有问题的，复杂的问题本来就应该有复杂的解决方法，对一般的人来说，很难把一个复杂的问题简单化，这个是需要水平的，和设计能力有关，当然选择工具也是设计能力的一部分

我也觉得这是jvm的致命问题，如果用于实时处理，那要死人的。
听说java7里面gc会有所改善。

.net不知道怎么处理这个问题的。

一个jvm的heap肯定不能开到5g，最多1.Xg

如果确实有很多东西要放在内存里，就需要用分布式内存Cache的方案

我也很奇怪一个jvm的heap怎么可以开到5g，请楼主解释下吧。

内存池。。。应该可以搞定的。。。