我已经构建了一个小型Java程序，它使用MQ客户端类与Websphere MQ服务器及其上的队列进行通信。我想要的是定期查询某个队列的大小，错误深度，例如每10秒钟一次。
我做了什么，示意性地：
qm = new MQQManager() q = qm.accessQueue() depth = q.getCurrentDepth() depth做一些事情）q.close() qm.close() 这就像一个魅力！
出于懒惰，我每次都编写代码来完成上述序列的所有6个步骤。所以我最后每10秒钟重复这个循环。在大约半小时内，监控服务器的人告诉我，我打开了153个实例。显然，只需在队列中执行close()和QM就不足以在我自己之后进行清理。
我要做明显的修复并坚持QM并排队等待程序的生命周期。但有人可以告诉我为什么我以前的方法是在泄漏资源，如果我选择沿着这条路走下去，我能做些什么呢？
更新（2017-01-25）
时间和接受
Roger提供了一些有关性能和未提交消息主题的精美代码和一些有用的解释。这很酷，但Eugene的答案恰好（并且最低限度）足以解决我的问题，而且他的速度要快一些。在我根据Eugene的建议将close()更改为disconnect()之后，我的小应用程序正在完全按照我的要求行事。我现在对于谁应该获得复选标记感到有些不知所措。我向你们两个道歉！
我完全得到了我想要的东西，我想我已经完成了这个问题但是我应该补充一点，我感谢Roger的深思熟虑的回答，为它提供给这个问题的任何未来其他读者的有用信息。 。希望其他人会倾听他的意见而不是跟随我。
性能
说实话，我不会对演出表示不满。服务器比它目前所做的要多得多，而我的监控客户端（这个问题的主题）在一台通常为空的开发机器上运行。我希望它会在一两天内达到目的，然后我就把它扔掉。与此同时，如果一个连接每10秒导致一个性能问题，他们应该负载平衡到Raspberry Pi或其他什么。
未提交的消息
我认为这也是一个非问题。发送应用程序在几毫秒内以小批量约1-5条消息排队并立即提交。接收应用程序（我编写的客户端，可能有问题）持续监听队列，单独接收和确认（提交）每条消息。所以我相当肯定永远不会有超过1条，可能还有5条未经确认的消息。与......的参数相比，这个数字是微不足道的。
我的实际问题，
涉及少数几百条消息，每天早上大约同一时间处理5到20分钟的处理延迟。我怀疑我的接收客户被一个＆＃34;挂着＆＃34;网络IO操作与MQS以外的其他操作。我想要探索的一个步骤是证明在MQS上确实存在等待消息的队列，并且它没有被拾取。我希望看到这个队列何时开始建立，它在那里停留多长时间以及一旦我的客户再次醒来它会多快消退。
这种连接每天有2,000到10,000条消息，下午和晚上对应于批处理过程的峰值，但延迟只发生在早上，通常实际上只有很小的量。我希望看到队列大小的日志，以便更好地了解正在发生的事情。作为下一步，我可能需要在我的接收客户端中做更多的工具。
环境
对于它的价值，服务器正在运行WSMQ 6，因此我的客户端使用阻塞和等待队列获取而不是我更喜欢使用的spiffy异步通知进程。我的接收客户端是在VM中在RHEL下运行的独立C应用程序。
答案 0 :(得分：4)
我认为你应该在finally块中使用 disconnect 而不是close。