2011年11月08日 20:32 "@billows"的内容
YGC : 1151
在将近 3个小时内 monitor gc 1151次,是否频繁?
虽然 YGCT 只有 8.462 S ...
3小时内年轻代收集YGC还属于频繁,先增大内存。
JVM微调目标是降低GC发生频率,降低延迟,然后再提高JVM大小以提高吞吐量,不过内存越大,需要类似碎片整理等压缩,响应时间会长,这也是一个响应时间延迟和吞吐量的平衡。
[该贴被banq于2011-11-27 16:39修改过]
在将近 3个小时内 monitor gc 1151次,是否频繁?
虽然 YGCT 只有 8.462 S ...
3小时内年轻代收集YGC还属于频繁,先增大内存。
JVM微调目标是降低GC发生频率,降低延迟,然后再提高JVM大小以提高吞吐量,不过内存越大,需要类似碎片整理等压缩,响应时间会长,这也是一个响应时间延迟和吞吐量的平衡。
[该贴被banq于2011-11-27 16:39修改过]
对于楼主这个问题,我发表点建议!在我们工作中经常也遇见,这类大量对象创建的问题,实际上也是跟你的数据模型有关,和状态有关!
大家都提到了 cache ,pool 技术,他们都有各自应用场景,如果你的数据是临时的,建议使用map过度做中间层,如果是要将数据保留一段时间给后续logic,dao 层使用的,用map就足够了。
什么场景下才用bean 才用对象? 当你的业务足够 OO的时候,大量的合建对象与分层是现象所有系统面临的一个问题。
jvm 优化在调整新生代与GC频率时,只可以解决部分问题,如果你真的是应对大访问量,做数据处理的话,建议单起一个应用做这层处理。
目前它是一个单独应用,没有大访问量,它只负责在一定时间去第三方系统通过接口获取数据,然后入库。