`
kwenge
  • 浏览: 2472 次
  • 性别: Icon_minigender_1
  • 来自: 成都
社区版块
存档分类
最新评论

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

WMQ JMS构造函数内存泄漏WMQMessageConsumerspring 
阅读更多

                                 一个构造函数抛出异常引发的“餐具”
                                                                                                                                                       --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<Integer, WMQMessageConsumer> consumer;
static {
consumer = new HashMap<Integer, WMQMessageConsumer>();
}

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<Integer, WMQMessageConsumer> 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]

 [/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：无可奉告，呵呵。

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

 

 

  • 大小: 320.3 KB
分享到：
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Magicbox
Global site tag (gtag.js) - Google Analytics