一个构造函数抛出异常引发的“餐具”
--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：无可奉告，呵呵。
本文到此结束，谢谢观看。