在论坛中看了一篇关于JVM GC的问题。
描述;逻辑挺简单的,只是调用量和数据量都非常大,因此会产生非常多的对象,尤其是minor GC这一块,基本上是很难优化了。
第一 JAVA做的东西不一定会比C++的性能来的差 没有必要考虑放弃JAVA
第二 创建的对象太多不发生内存溢出已经是很庆幸的一件事情了.
关于GC,浅谈以下几点.
第一 不要奢望JVM在你调用GC后马上就会回收.
第二 数据库很强大但也不要经常出现 SELECT * FROM TABLE的情况.
第三 一次创建太多对象应该考虑是否有必要创建这么多对象,能否分次分批进行处理.JSP分页是一个古老的技术,只是用的多了也就忘了.
第四 WEBSPHERE在高负载的情况下并非完全是在跑你的业务,它也会记载一大堆让你头疼的日志文件比如CORE和DUMP.
第五 以上是我人员由于编程习惯和客观原因照常GC的原因.
第六 参数的设置 比如Heap的设置,要根据实际情况进行不是越大就越好的.
最后我觉得GC的问题不是内存和JVM的问题,而是CPU使用一直偏高,业务逻辑处理方式的问题.CPU在等待数据库返回结果空转期间,这时候CPU的使用是非常高的. 分批次的处理还是有好处的.
JAVA不会很慢,性能也是不賴的.
描述;逻辑挺简单的,只是调用量和数据量都非常大,因此会产生非常多的对象,尤其是minor GC这一块,基本上是很难优化了。
第一 JAVA做的东西不一定会比C++的性能来的差 没有必要考虑放弃JAVA
第二 创建的对象太多不发生内存溢出已经是很庆幸的一件事情了.
关于GC,浅谈以下几点.
第一 不要奢望JVM在你调用GC后马上就会回收.
第二 数据库很强大但也不要经常出现 SELECT * FROM TABLE的情况.
第三 一次创建太多对象应该考虑是否有必要创建这么多对象,能否分次分批进行处理.JSP分页是一个古老的技术,只是用的多了也就忘了.
第四 WEBSPHERE在高负载的情况下并非完全是在跑你的业务,它也会记载一大堆让你头疼的日志文件比如CORE和DUMP.
第五 以上是我人员由于编程习惯和客观原因照常GC的原因.
第六 参数的设置 比如Heap的设置,要根据实际情况进行不是越大就越好的.
最后我觉得GC的问题不是内存和JVM的问题,而是CPU使用一直偏高,业务逻辑处理方式的问题.CPU在等待数据库返回结果空转期间,这时候CPU的使用是非常高的. 分批次的处理还是有好处的.
JAVA不会很慢,性能也是不賴的.