异步发送消息生产者使用持久(persistent)传递模式发送消息的时候，Producer.send() 方法会被阻塞，直到 broker 发送一个确认消息给生产者，这个确认消息暗示生产者 broker 已经成功地将它发送的消息路由到目标目的并把消息保存到二级存储中。这个过程通常称为同步发送。但有一个例外，当发送方法在一个事物上下文中时，被阻塞的是 commit 方法而不是 send 方法。commit 方法成功返回意味着所有的持久消息都以被写到二级存储中。
同步发送持久消息能够提供更好的可靠性，但这潜在地影响了程序的相应速度，因为在接受到 broker 的确认消息之前应用程序或线程会被阻塞。如果应用程序能够容忍一些消息的丢失，那么可以使用异步发送。异步发送不会在受到 broker 的确认之前一直阻塞 Producer.send 方法。如果想启动异步传送可以把 connector uri 的 jms.useAsyncSend 选项设为 true，如下所示：
tcp://localhost:61616?jms.useAsyncSend=true
从 ActiveMQ 5 开始可以控制异步发送流。也就是说，在受到 broker 的确认应答之前，生产者能够传送消息给 broker 的最大信息量。即使是异步发送消息，生产者也是在收到 broker 的确认应答后才把下一条消息传送给 broker。当使用异步传送的时候，可以设置 jms.producerWindowSize(单位为字节)属性，当生产者中等待发送的信息量到达设置的值时，即使没有收到 broker 的应答消息，生产者同样会把这些消息发给 broker。如下面的示例设置：
tcp://localhost:61616?jms.useAsyncSend=true&jms.producerWindowSize=1024000
单独确认
在 ActiveMQ 5.2 中添加了一个新的确认模式，这种确认模式是特定于 ActiveMQ 的，jms 规范暂时并不支持这种确认模式。这种确认模式由 ora.apache.activemq.ActiveMQSession.INDIVIDUAL_ACKNOWLEDGE 表示，用来确认一个单独的消息。这中确认模式是相对于 Session.CLIENT_ACKNOWLEDGE 的，在 CLIENT_ACKNOWLEDGE 模式下，调用消息的 acknowledge() 方法会确认由此 session 消费的所有消息，而在 INDIVIDUAL_ACKNOWLEDGE 模式下，仅会确认调用 acknowledge() 方法的消息。
