一个构造函数抛出异常引发的“餐具”

阅读更多

                                 一个构造函数抛出异常引发的“餐具”
                                                                                                                                                       --20141009
        公司基于IBM MQ开发了企业级综合服务管理平台(ESB),同时将用户、客户、机构等等基础信息管理功能分离出来提供基本的数据服务,而其他系统则通过综合服务管理平台进行服务访问。我方恰好设计、并开发了其中的用户信息管理系统。该系统需要管理企业范围内的所有用户信息、机构信息、系统信息、功能信息、权限信息,并提供各种用户认证服务。其中一个较为关键的功能是,我们需要将各业务系统相关的用户、机构以及功能权信息实时同步到各业务系统,并且保证同步功能的高效、稳定与可靠。
        数据信息实时同步功能,依托企业级综合服务管理平台,并且采用异步消息通信的方式,从系统Server端将变化的信息同步到各业务系统的Client端,Server端在我方部署,Client端在各业务系统部署。我方将Client端开发完成,然后通知所有需要使用我方信息的系统下载并安装Client端。Client端一旦启动,通常不会停止。除非:(1)人为的将Client端关闭;(2)Client端进程宕掉。
        近期,项目组收到业务系统发来的问题求助:该业务系统在部署Client端之后,过了一段时间之后,Client端的进程宕了。在Client端的启动目录下,产生了一批javacore和heapdump文件。希望项目组能够协助分析、并解决该问题。
        由于整个企业范围内大约有上百个Client端安装,绝大多数Client端都是没有出现这样的问题的。由此初步判定,此案例只是个例,如果是个例,那么问题通常该业务系统的环境存在些许关系。

第一步,对javacore文件进行分析
        由于javacore分析工具jca有些异样,我们只好使用Editplus将javacore打开,看看其中的内容究竟是怎么回事。
        文件一开始便告诉我们:java.lang.OutOfMemoryError “java heap space received”。即,本次导致进程宕掉的主要原因,是JVM的堆空间出现了内存溢出。在Javacore后面的线程堆栈输出方面,可以看到大量的线程都处于等待状态。
        既然是堆空间溢出,那么我们有必要分析下heapdump文件,看看是什么对象占用了大量的数据空间。

第二步,对heapdump文件进行分析
        由于heapdump文件是二进制文件,并且文件大小比较庞大,不可能像javacore那样使用编辑工具软件便可以进行分析,而是需要使用专门的分析软件,例如IBM Heap Analyzer分析工具。
        将heapdump文件导入到IBM Heap Analyzer工具后,可以看到:在发生内存溢出的时候,Client端JVM进程中存在大量的java对象。通过分析工具左下方Subponena Leak Suspects可以看到:
(1) WMQFFSTInfo对象竟然占用了97%的堆内存空间。
(2) WMQFFSTInfo中存在一个Map对象,包含7900个HashMap$Entry对象,每个Entry对象的大小为113K左右。
(3) 每个HashMap$Entry对象都涉及到WMQMessageConsumer对象。
于是,我们基本上可以判定,是WMQFFSTInfo类中的Map对象占用内存过多,而导致内存溢出。
        疑点1:是不是JVM分配的堆内存空间太小呢?因为Client端的java启动命令参数是由项目组设定,但是各业务系统依然可以打开startup.sh启动脚本,更改JVM分配空间大小。经过该业务系统人员提供的启动命令,可以看到java的启动参数:
java –Xms256 –Xmx1024 ………
此启动参数与其他能够正常运行的JVM启动参数是一致的。可以排除因为指定的JVM堆内存空间太小,而导致内存溢出的情况。
        疑点2:是不是因为同步到达的数据过多而导致的呢?从Server端将数据同步到Client端,其底层数据通信中间件使用的是IBM MQ,由于Client端从未成功连接到MQ队列上,不可能有数据从MQ取出来放入Client端的Java进程中。
        上面的疑点都排除了。那会是什么原因呢?
        当然,有读者或许会问,Client端在宕机前输出的日志信息,有没有?日志信息中,有没有什么异常输出?日志信息里边有没有什么值得分析的线索?的确,异常日志输出对于问题诊断是非常关键的,然而Client端的开发人员并没有正确地将异常堆栈跟踪信息输出到日志文件中,而是简单地将某个环节的操作结果打印到日志文件中,导致问题诊断难度加大。我们先来分析下问题所涉及的两个关键类的相关代码。

第三步,分析WMQFFSTInfo和WMQMessageConsumer
        由于MQ使用的是IBM的WebSphere MQ,属于商业版本,相关的接口jar包的代码并未开源,我们只能通过反编译工具对IBM MQ的jar包进行反编译,然后分析其中的java代码实现。
        对于WMQFFSTInfo类,我们发现其存在4个属性,其中,每个属性都有对应的add和remove方法,值得注意的是,这4个属性是静态属性,如果不调用相关属性对应的remove方法,则4个Map属性中引用的对象不会被JVM GC回收。

public class WMQFFSTInfo{
……….
static Map connection;
static Map session;
static Map consumer;
static Map producer;
………..

Public static void addConsumer(WMQMessageConsumer consumer){
……….
key=func(consumer);
consumer.put(key,consumer);
………
}

Public static removeConsumer(WMQMessageConsumer consumer){
……………
key=func(consumer);
consumer.remove(key);
……….
}
……….
}

 

       下面我们来看看WMQMessageConsumer类:
       (1) 有两个构造函数,这两个构造函数中,首先对对象属性进行this.prop=prop式的赋值,然后调用WMQFFSTInfo的addConsumer方法:WMQFFSTInfo. addConsumer(this);

public WMQMessageConsumer(WMQDestination destination, WMQSession session, String selector, boolean nolocal, JmsPropertyContext jmsProps)
    throws JMSException
  {
    super(jmsProps);
    this.destination = destination;
    this.session = session;
    this.selector = selector;
    this.nolocal = nolocal;

    WMQFFSTInfo.addConsumer(this);

    checkDestinationValidForNPHigh();
    this.syncShadow = new WMQSyncConsumerShadow(this, session, destination, selector, nolocal, this.subscriptionName);
    this.currentShadow = this.syncShadow;
    this.currentShadow.initialize();
  }

 
       (2) 存在close方法,在close方法中会调用WMQFFSTInfo. removeConsumer(this);即只有consumer对象成功调用了close方法,才会从WMQFFSTInfo中移除该consumer对象。
单纯从上面的类和方法中,我们并不能得出任何结论。

第四步,分析Client端输出的日志
       从Client端输出的日志中,发现在出现JVM宕掉之前,日志中大量输出JMSException,其主要内容是说:XXXX MQ队列没有找到。
       后来与Client端开发人员交流,得知,如果Client端在建立MQ连接后,若创建MessageConsumer失败,则会每个5秒钟,再次重复创建MessageConsumer。并且,MessageConsumer的创建次数并没有上限限制。
       结合前面分析的结果,在加上Client软件运行良好的系统并没有出现此问题,我们初步估计问题原因如下:Client端每隔5秒钟创建了一个MessageConsumer对象,并且将此对象放入了WMQFFSTInfo中,等到真正需要去连接MQ队列时,却由于MQ队列信息不正确而抛出了异常,导致系统根本没有时机去调用MessageConsumer的close方法释放已经放入WMQFFSTInfo的对象,在创建7900多个MessageConsumer之后,WMQFFSTInfo成功地消耗掉了JVM进程中所有的堆空间,而且还无法进行垃圾回收,最终导致JVM堆内存溢出,进而引发JVM进程宕机。

       下面我们来上述分析中存在的两个疑点:
       (1)MessageConsumer对象何时去连接MQ队列?
       (2)为什么连接MQ队列抛异常时,会导致MessageConsumer对象没有调用close方法?

 


第五步,问题的真正原因
       根据上面的分析,我们基本上对问题的发生原因有一个方向判定,但是所有的问题的真正原因还需要通过软件代码来证实,比如,本案例的Bug产生原因是,MQ队列(queue)无法正常连接,系统抛出JMSException之后,并没有将WMQFFSTInfo中的废弃WMQMessageConsumer对象移除,导致内存泄漏。
按照正常情况,如果调用了WMQMessageConsumer的close方法,则系统必然会从WMQFFSTInfo中将consumer移除。我们进而需要分析Spring框架下,DefaultMessageListenerContainer的代码中,是否支持在异常发生的情况下,会调用consumer的close方法。
       通过反编译工具,反编译spring子项目jms的jar包,找到DefaultMessageListenerContainer的内部运行线程,可以看到线程方法中代码片段如下:

public void run() { 
synchronized (DefaultMessageListenerContainer.this.lifecycleMonitor) {
       ………………..
      }
      catch (Throwable ex)
      {
        clearResources();
        ………………
      }
      finally
      {
        ………………..
        synchronized (DefaultMessageListenerContainer.this.lifecycleMonitor) {
          if ((!DefaultMessageListenerContainer.this.shouldRescheduleInvoker(this.idleTaskExecutionCount)) || (!DefaultMessageListenerContainer.this.rescheduleTaskIfNecessary(this)))
          {
            ………………..
            clearResources();
          }
………..
      }
    }


    private void clearResources() {
     …………….
      JmsUtils.closeMessageConsumer(this.consumer);
      JmsUtils.closeSession(this.session);
……………
      this.consumer = null;
      this.session = null;
    }

 
       由此判断,当consumer抛出异常时,Spring-JMS框架肯定会执行consumer的close()方法。
       然而,事实是,Client端进程抛出JMSException时,根本就没有调用close()方法。即,似乎是在告诉我们,是在创建consumer对象的时候抛出的异常,而不是在创建成功之后,抛出的异常,所以,Spring-JMS根本无法调用consumer的close方法【因为consumer是null】。
       我们将WMQMessageConsumer的构造函数再次拿出来详细分析:

public WMQMessageConsumer(WMQDestination destination, WMQSession session, String selector, boolean nolocal, JmsPropertyContext jmsProps)
    throws JMSException
  {
    super(jmsProps);
    this.destination = destination;
    this.session = session;
    this.selector = selector;
    this.nolocal = nolocal;

    WMQFFSTInfo.addConsumer(this);

    checkDestinationValidForNPHigh();
    this.syncShadow = new WMQSyncConsumerShadow(this, session, destination, selector, nolocal, this.subscriptionName);
    this.currentShadow = this.syncShadow;
    this.currentShadow.initialize();
  }

 
       WMQMessageConsumer的构造函数抛出了一个JMSException,并且是在WMQFFSTInfo.addConsumer(this);之后抛出。通过代码查证,new WMQSyncConsumerShadow()构造函数中,会通过JMSSession连接MQ的本地消息队列,而在没有成功连接的情况下,会抛出JMSException。由此,是WMQMessageConsumer构造函数中抛出了异常,导致了WMQFFSTInfo中的consumer对象没有释放,进而发生了内存泄漏。由此,问题不难从根本上解决之。
       正常情况下,在WMQMessageConsumer的构造函数中,需将抛出JMSException的Java代码用try-catch代码块封装,并且在出现异常时,在catch代码块中显示调用WMQFFSTInfo.removeConsumer(this)方法。至于为什么IBM的工程师们,不按常规的办法做,而是使用了会产生内存泄漏的解决办法,我们无法得知其中缘由。这一缺陷IBM MQ7.5版本中依然存在。【请IBM给解释】

第六步,模拟验证
       首先我们写一套类似的代码,用于重现问题。
WMQFFSTInfo.java

public class WMQFFSTInfo {
private final static Map consumer;
static {
consumer = new HashMap();
}

public static void addConsumer(WMQMessageConsumer consumer) {
WMQFFSTInfo.consumer.put(consumer.hashCode(), consumer);
}

public static void remove(WMQMessageConsumer consumer) {
WMQFFSTInfo.consumer.remove(consumer.hashCode());
}

public static Map getConsumer() {
return WMQFFSTInfo.consumer;
}
}

 

WMQMessageConsumer.java

public class WMQMessageConsumer {
	private String name;
	private String code;
	private JMSException e;

	public WMQMessageConsumer(String name, String code) {
		super();
		this.name = name;
		this.code = code;
		WMQFFSTInfo.addConsumer(this);
	}

	public WMQMessageConsumer(String name, String code,JMSException e) throws JMSException {
		super();
		this.name = name;
		this.code = code;
		this.e = e;
		WMQFFSTInfo.addConsumer(this);
		throw e;
	}

	public WMQMessageConsumer(String name, String code,JMSException e,boolean flag) throws JMSException {
		super();
		this.name = name;
		this.code = code;
		this.e = e;
		WMQFFSTInfo.addConsumer(this);
		try {
			throw e;
		} catch (Exception e1) {
			WMQFFSTInfo.remove(this);
			throw e;
		}
	}
	
	public void close(){
		WMQFFSTInfo.remove(this);
	}
	
	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getCode() {
		return code;
	}

	public void setCode(String code) {
		this.code = code;
	}

}

 

DefaultMessageListenerContainer.java

public class DefaultMessageListenerContainer {
public static void main(String[] args) {
main1();
main3();
main2();
}

public static void main1(){
WMQMessageConsumer consumer = null;
try {
consumer = new WMQMessageConsumer("对象成功构造不会发生异常的测试","TEST_01");
} catch (Throwable e) {
e.printStackTrace(); 
} finally{
if(consumer != null)consumer.close();
}

System.out.println("对象成功构造时,WMQFFSTInfo中consumer个数为:"+WMQFFSTInfo.getConsumer().size());
}

public static void main2(){
WMQMessageConsumer consumer = null;
try {
consumer = new WMQMessageConsumer("对象构造发生异常并抛出时的测试","TEST_02",new JMSException("模拟consumer构造函数发生了异常"));
} catch (Throwable e) {
e.printStackTrace(); 
} finally{
if(consumer != null)consumer.close();
}

System.out.println("对象构造发生异常并抛出时,WMQFFSTInfo中consumer个数为:"+WMQFFSTInfo.getConsumer().size());
}

public static void main3(){
WMQMessageConsumer consumer = null;
try {
consumer = new WMQMessageConsumer("对象构造发生异常并抛出,并且在捕获异常后去除Consumer的测试","TEST_03",new JMSException("模拟consumer构造函数发生了异常"),true);
} catch (Throwable e) {
e.printStackTrace(); 
} finally{
if(consumer != null)consumer.close();
}

System.out.println("对象构造发生异常时去除Consumer,WMQFFSTInfo中consumer个数为:"+WMQFFSTInfo.getConsumer().size());
}
}

 

测试结果显示如下:

TEST_01的输出结果:
对象成功构造时,WMQFFSTInfo中consumer个数为:0

TEST_02的输出结果:
javax.jms.JMSException: 模拟consumer构造函数发生了异常
at com.klie.emic.base.constructor.DefaultMessageListenerContainer.main2(DefaultMessageListenerContainer.java:28)
at com.klie.emic.base.constructor.DefaultMessageListenerContainer.main(DefaultMessageListenerContainer.java:7)
对象构造发生异常并抛出时,WMQFFSTInfo中consumer个数为:1

TEST_03 的输出结果:    
javax.jms.JMSException: 模拟consumer构造函数发生了异常
at com.klie.emic.base.constructor.DefaultMessageListenerContainer.main3(DefaultMessageListenerContainer.java:15)
at com.klie.emic.base.constructor.DefaultMessageListenerContainer.main(DefaultMessageListenerContainer.java:9)
对象构造发生异常时去除Consumer,WMQFFSTInfo中consumer个数为:0

 

为什么DefaultMessageListenerContainer中存在consumer的close方法调用,但是对象没有从WMQFFSTInfo中被移除?
       TEST_02的输出结果是特别有意思的,该结果说明虽然构造函数中抛出了JMSException,但是WMQMessageConsumer对象是已经生成了。由于构造函数抛出了异常,所以构造函数这个方法并没有正确结束,没有正确地返回对象引用。故而,在使用consumer = new WMQMessageConsumer(……)时,引用对象consumer并没有被正确赋值,或者更准确地说,是consumer引用的赋值操作根本就没有被执行。所以,虽然示例中,DefaultMessageListenerContainer 的main方法将consumer.close方法写入了finally代码块,但是由于consumer没有赋值,还是null,所以close方法没有执行,或者就算是执行,也会抛出NullPointerException。

后记
        事后,Client端开发人员通过更改异常日志信息输出,并且根据本文的分析结论,对问题进行重现并输出异常堆栈跟踪信息,结果如下:
[img]
一个构造函数抛出异常引发的“餐具”_第1张图片
 [/img]
       从异常堆栈信息,可以明显地看到是何处抛出了异常。同时,本文的分析结论,也得到了客观的证实。

问题如何解决?
       最好的办法是,将问题类反编译出来,对问题代码进行完善,并将编译后的结果放入jar包中,重启下Client端,并且保证Client端所连MQ是无误的、是经过其他工具测试,能够收发消息的。

       疑问1:是否可以通过升级JAR包解决?
       ANS:不可以,因为最新V7.5版本的IBM MQ.jar所提供的JMS实现,依然存在此问题。

       疑问2:是否JMSConnection连接时,IP或端口配置出错,也会内存泄漏?
       ANS:不会,因为IBM的JMSMessageConnection中,构造函数对IP和端口的连接抛异常的情况进行了try-catch处理。

       疑问3:是否队列管理器配置出错,会出现内存泄漏?
       ANS:估计会,因为此处的情况与连接QUEUE的处理代码是一样的,出现异常时直接抛出,而并没有catch异常,并remove掉Connection对象。

       疑问4:为什么IBM的JMS实现,有时候会对异常try-catch避免内存泄漏,有时候又不会呢?
       ANS:无可奉告,呵呵。

       本文到此结束,谢谢观看。

 

 

  • 一个构造函数抛出异常引发的“餐具”_第2张图片
  • 大小: 320.3 KB
  • WMQMessageConsumer构造函数抛JMSException导致的WMQFFSTInfo内存泄漏.rar (1012.7 KB)
  • 下载次数: 1
  • 查看图片附件

你可能感兴趣的:(WMQ,JMS,构造函数,内存泄漏,spring)