JMS中为数不多的重点就是消息的确认机制，下面分别介绍J2EE和Spring的MessageListenerContainer的确认机制

J2EE中JMS确认机制

在JMS规范中一共4种确认方式

AUTO_ACKNOWLEDGE当调用recieve方法成功后或MessageListener处理函数成功返回后进行确认

CLIENT_ACKNOWLEDGE客户端通过message的acknowledge方法手动确认

DUPS_OK_ACKNOWLEDGE延迟确认，在对重复接受同一消息不敏感时可以选用此确认模式，相比AUTO_ACKNOWLEDGE有性能提升

SESSION_TRANSACTED调用session的commit或rollback进行事务式确认

Spring中的确认机制

多数情况下会使用Spring集成相关JMS的操作，可以减少相关开发的复杂度，但是Spring的确认方式和默认的JMS确认方式有些许不同，根据官方API

AUTO_ACKNOWLEDGE(默认):这个模式依赖于具体的实现，DefaultMessageListenerContainer中是在调用listener方法之前确认，SimpleMessageListenerContainer是在listener返回后确认，但是即使listener抛出异常，是不会重发的。

DUPS_OK_ACKNOWLEDGE延迟确认,同样也不会对用户异常进行重发

CLIENT_ACKNOWLEDGE当listener抛出异常时会进行重发

基于事务的确认将sessionTransacted设置为true，会在listener抛出异常进行重发，同时这也是spring推荐使用的方式

可以看出Spring的AUTO_ACKNOWLEDGE方式并不会关心listener抛出的异常，这个和J2EE的在listener成功返回后确认有所区别。

SpringJMS相关实现

下面看下SpringJMS MessageListenerContainer的继承树

Object

|-JmsAccessor

	|-JmsDestinationAccessor

		|-AbstractJmsListeningContainer

			|-AbstractMessageListenerContainer

				|-AbstractPollingMessageListenerContainer

					|-DefaultMessageListenerContainer

				|-SimpleMessageListenerContainer

					|-SimpleMessageListenerContainer

如上面介绍的DefaultMessageListenerContainer和SimpleMessageListenerContainer是两个不同的分支，

前者继承了AbstractPollingMessageListenerContainer，从名字可以看出这个是客户端polling来获得消息的，也就是使用recieve方法，所以在API中说是在listener方法执行前确认的

后者是直接封装了MessageListener进行调用，但是对用户代码进行了异常控制所以就算抛出异常也不会进行重发，这个也许是为了统一AUTO_ACKNOWLEDGE的行为吧。

总结

spring默认的JMS确认方式是无法保证在用户代码出现异常时进行重发的（如OOM的情况等），这样会导致消息的丢失，在某些场景这个是不可接受的，所以使用中需要注意选用适当的确认方式进行JMS开发