解决方案 »

  1.   


    这是jconsole里打出来的内容。
    老年代已经非常满了,好像没有进行回收似的
    那个PS MarkSweep的用时也有点长
    我的JVM参数是这样的
    set JAVA_OPTS=-server -Xms150m -Xmx200m -XX:-UseParallelOldGC
    不知道老年代的状态和最后一个有没有什么关系
    之前用-XX:+UseParNewGC也是上面那种图形走势
      

  2.   

    多半是内存泄露,  内存满的时候分析下dump文件, 查看占用内存的对象.  差不多能找出出问题的地方.
      

  3.   

    多谢回复!-XX:+HeapDumpOnOutOfMemoryError的参数我加上了
    文件我也通过vistualvm分析了,
    看样子也没有什么特别大和特别多的比较诡异的内存占用啊这是按大小排序的实例信息,
    请教一下有什么是比较特别的吗?
    再次感谢
      

  4.   


    不懂你的业务。但从常识来猜测,你贴出部分最可疑的部分是 ActiveMQConnection,你8700多个实例,一般Connection的个数应该是有限的吧。具体什么问题,估计你还得往下看,看看你自己的业务部分,哪个类的用的内容多。
      

  5.   

    然后你顶部,MQ部分用的内存也很多,这个是最可疑的部分了。有bug?还是你MQ Server不够快,堆积了?
      

  6.   

    嗯,多谢楼上的回复。
    这个是有点多。
    但是:1、没错打开以后,都显式的关闭了。而且是在finally里。
    2、这个需求是每几秒钟看看有没有消息过来,打开的这个connection就是为了看看有没有的。
    这个是跑了一晚上的结果,8k多次也正常。不过这个思路也许对,
    我去看看有什么方法能像用数据库连接池一样去开这个connection。多谢多谢
      

  7.   


    你可以继续研究内存dump,这种连接没有回收总归是有对像引用在才会发生这种事的。jdk里还有个东西叫jhat。如果你的问题很容易重现的话,建议跑个个把小时就收集内存,这时东西还比较少,比较容易查内存问题。另外,一个晚上跑8K次不是问题,但是8K个对像应该是跑完一次收集一次,如果你是几分钟 一次的话,按你的这个垃圾收集间隔来看,正常应该是只有几个而已。
      

  8.   

    2个timer分别是5秒和7秒执行一次,
    你说的没错,应该不会剩余那么多的连接,
    我再仔细看看程序。大谢
      

  9.   

    多谢你的提醒,果然是这些conn的问题。
    原因是我怕程序没关闭,缓存起来一起关掉,
    结果每次关闭的时候反而忘了从这些缓存里去掉。总之是一个特别低级的错误。哈哈谢谢了!结贴