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

java的缓存瞒烂的，占用gc。不过，比如使用ehcache,可以让缓存写到文件系统上（再指定到内存模拟的设备上），但这样增加序列化的cpu消耗，如果这样的方式ok，就继续young跟old都用UsePara...。Concurrent方式低暂停，但也增多了开销。

  我觉得他这个是设计问题， 为什么要cache 3g的数据， 这个本身就值得思考。 另外， 尽管GC参数能调整一些问题， 但是， 都无法解决这么庞大的FULL GC问题。
  我一直都不赞成使用JAVA作大规模的数据CACHE， 这个会导致严重的GC问题， 以前我们的系统就是把好几百M的文件读到系统里， 这个很容易造成系统的不稳定， 有时候会造成严重的JVM CRASH， 可能新版本的JVM会好点。
  我建议你把系统的CACHE的数据MODEL说出来， 大家给你参考下， 光是靠JVM的调整， 我直接可以告诉你， JVM是作不到完美的。 我们作多很多测试， 在以后大量对象的规模下，  FULL GC无法达到一个令人满意的停顿平滑。

你可以加我MSN SDH5724＠163。COM  我帮你看看， 我也在调整我们应用的GC参数。 今天计算了下， GC 用了5％的CPU时间， 有点恐怖的。

一般的JVM最多就支持到2GB内存吧。换一个专门针对管理高内存的jvm试试

Java有RTS（Real Time System）规范，要做实时系统还是用这个做比较靠谱
我们的认证系统是纯C开发的，8台16CPU、32G内存的机器分两组集群，每台缓存超过10G内存，虽然不会有任何停顿，
但是内存泄漏同样是个梦魇，每年都在查内存泄漏，几乎成了无法避免的任务了

对于很多高性能的互联网系统来说，别说3G，300G的cache都是很有可能的。大量cache，大量对象已经是不可避免的了，在这个前提下再看看怎样调GC，或者现在的JVM根本无法满足此种应用的需要？现在我正在苦恼着这个事情。如果实在不能满足，以后此类应用就只能交由C/C++开发了，因为觉得这样还不应该到服务器的瓶颈所在。对于几百M的文件读进系统，基本上是不太可能造成系统不稳定的，那简直和吃生菜差不多。

就是因为当初怕内存泄漏这个梦魇，才避开C，选择用JAVA来开发此类系统，简洁轻便，开发也非常快。可惜JVM的GC已经成为生命不能承受之重，唉。

http://javolution.org/doc/Man33955.pdf 这个文章里提到并行GC，大概可以把暂停控制在毫秒级，这个应该可以接受吧。另外javolution重写了jdk的部分基础类，支持多处理器。

个人建议,转C#.一方面GC性能可能会提高一些,另一方面C#整合native 代码更方便一些.实在山穷水尽的时候这也是唯一的办法.至于stop-whole-world的原因可以看这里,这是一个几乎无法解决的问题.当然据说MS那里有更好的方案
http://www.iteye.com/post/479478

大部分的互联网应用cache并不是放在JVM中的，而是利用第3方cache server，比如memcached。
你可以试试看将程序中的cache机制改写到第3方的cache server试试看。

我觉得把数据Cache到内存里,唯一的用处就是利用数组来实现内存的随机高速访问.这点对运算密集型的应用来说至关重要,如果是这样的情况memcache这样通过Hash表实现的cache不光是线性查找还有网络传输的消耗，当然可以考虑在程序里再做二级cache.但是一来复杂度高二来取决于cache传输和运算两边的速度,如果运算远快于传输那么我估计二级cache也不会小到哪里去.