异步发送消息
ActiveMQ 支持生产者以同步或异步模式发送消息。使用不同的模式对send 方法的
反应时间有巨大的影响，反映时间是衡量ActiveMQ 吞吐量的重要因素，使用异步发送
可以提高系统的性能。
在默认大多数情况下，AcitveMQ 是以异步模式发送消息。例外的情况：在没有使用
事务的情况下，生产者以PERSISTENT 传送模式发送消息。在这种情况下，send 方法都
是同步的，并且一直阻塞直到ActiveMQ 发回确认消息：消息已经存储在持久性数据存
储中。这种确认机制保证消息不会丢失，但会造成生产者阻塞从而影响反应时间。
高性能的程序一般都能容忍在故障情况下丢失少量数据。如果编写这样的程序，可
以通过使用异步发送来提高吞吐量（甚至在使用PERSISTENT 传送模式的情况下）。
异步发送
消息生产者使用持久（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() 方法的消息。