ActiveMQ消费消息有两种方式。一种是使用同步阻塞的MessageConsumer.receive()方法；另一种是使用消息监听器MessageListener。这里需要注意的是，在同一个session下，只能选择其中一种方式。

消费消息流程图

消费消息源码分析

ActiveMQMessageConsumer.receive，消费端同步接收消息的源码入口：

public Message receive() throws JMSException {
checkClosed();
checkMessageListener(); //检查receive和MessageListener是否同时配置在当前的会话中
sendPullCommand(0); //如果PrefetchSizeSize为0并且unconsumerMessage为空，则发起pull命令
MessageDispatch md = dequeue(-1); //从unconsumerMessage出队列获取消息
if (md == null) {
return null;
}
beforeMessageIsConsumed(md);
afterMessageIsConsumed(md, false); //发送ack给到broker
return createActiveMQMessage(md);//获取消息并返回
}

sendPullCommand()，发送pull命令从broker上获取消息，前提是prefetchSize=0并且unconsumedMessages为空。unconsumedMessage表示未消费的消息，这里面预读取的消息大小为prefetchSize的值。

protected void sendPullCommand(long timeout) throws JMSException {
clearDeliveredList();
if (info.getCurrentPrefetchSize() == 0 && unconsumedMessages.isEmpty()) {
MessagePull messagePull = new MessagePull();
messagePull.configure(info);
messagePull.setTimeout(timeout);
session.asyncSendPacket(messagePull); //向服务端异步发送messagePull指令
}
}

clearDeliveredList()，主要用来清理已经分发的消息链表deliveredMessages。deliveredMessages，存储分发给消费者但还为应答的消息链表。如果session是事务的，则会遍历deliveredMessage中的消息放入到previouslyDeliveredMessage中来做重发；如果session是非事务的，根据ACK的模式来选择不同的应答操作。

dequeue()，从unconsumedMessage中取出一个消息，在创建一个消费者时，会对这个消费者创建一个未消费的消息通道，这个通道分为两种，一种是简单优先级队列分发通道SimplePriorityMessageDispatchChannel ；另一种是先进先出的分发通道FifoMessageDispatchChannel。
通过这样的设计可以允许session能够一次性将多条消息分发给一个消费者，而不用消费者每次消费完一个消息以后再去broker拿消息，提高效率。默认情况下对于queue来说，prefetchSize的值是1000。

beforeMessageIsConsumed()，这里面主要是做消息消费之前的一些准备工作，如果ACK类型不是DUPS_OK_ACKNOWLEDGE或者队列模式（简单来说就是除了Topic和DupAck这两种情况），所有的消息先放到deliveredMessages链表的开头。并且如果当前是事务类型的会话，则判断transactedIndividualAck，如果为true，表示单条消息直接返回ack。否则，调用ackLater，批量应答, client端在消费消息后暂且不发送ACK，而是把它缓存下来(pendingACK)，等到这些消息的条数达到一定阀值时，只需要通过一个ACK指令把它们全部确认，这比对每条消息都逐个确认，在性能上要提高很多。

private void beforeMessageIsConsumed(MessageDispatch md) throws JMSException {
md.setDeliverySequenceId(session.getNextDeliveryId());
lastDeliveredSequenceId = md.getMessage().getMessageId().getBrokerSequenceId();
if (!isAutoAcknowledgeBatch()) {
synchronized(deliveredMessages) {
deliveredMessages.addFirst(md);
}
if (session.getTransacted()) {
if (transactedIndividualAck) {
immediateIndividualTransactedAck(md);
} else {
ackLater(md, MessageAck.DELIVERED_ACK_TYPE);
}
}
}
}

afterMessageIsConsumed()，这个方法的主要作用是执行应答操作，这里面做以下几个操作：
Ø 如果消息过期，则返回消息过期的ack
Ø 如果是事务类型的会话，则不做任何处理
Ø 如果是AUTOACK或者（DUPS_OK_ACK且是队列），并且是优化ack操作，则走批量确认ack
Ø 如果是DUPS_OK_ACK，则走ackLater逻辑
Ø 如果是CLIENT_ACK，则执行ackLater逻辑

消息的确认过程

消息确认有四种 ACK_MODE，分别是：
AUTO_ACKNOWLEDGE = 1 自动确认
CLIENT_ACKNOWLEDGE = 2 客户端手动确认
DUPS_OK_ACKNOWLEDGE = 3 自动批量确认
SESSION_TRANSACTED = 0 事务提交并确认

虽然 Client 端指定了 ACK 模式，但是在 Client 与 broker 在交换 ACK 指令的时候，还需要告知ACK_TYPE。ACK_TYPE 表示此确认指令的类型，不同的ACK_TYPE 将传递着消息的状态，broker 可以根据不同的 ACK_TYPE 对消息进行不同的操作。

ACK_TYPE：
DELIVERED_ACK_TYPE = 0 消息”已接收”，但尚未处理结束；
STANDARD_ACK_TYPE = 2 “标准”类型,通常表示为消息”处理成功”，broker 端可以删除消息；
POSION_ACK_TYPE = 1 消息”错误”,通常表示”抛弃”此消息，比如消息重发多次后，都无法正确处理时，消息将会被删除或者 DLQ(死信队列)；
REDELIVERED_ACK_TYPE = 3 消息需”重发”，比如 consumer 处理消息时抛出了异常，broker 稍后会重新发送此消息；
INDIVIDUAL_ACK_TYPE = 4 表示只确认”单条消息”,无论在任何 ACK_MODE ；
UNMATCHED_ACK_TYPE = 5 在 Topic 中，如果一条消息在转发给“订阅者”时，发现此消息不符合 Selector 过滤条件，那么此消息将 不会转发给订阅者，消息将会被存储引擎删除(相当于在 Broker 上确认了消息)。

消息的重发机制原理

在正常情况下，有几中情况会导致消息重新发送：
Ø 在事务性会话中，没有调用 session.commit 确认消息或者调用session.rollback 方法回滚消息；
Ø 在非事务性会话中，ACK 模式为 CLIENT_ACKNOWLEDGE 的情况下，没有调用 acknowledge 或者调用了 recover 方法。

一个消息被重发超过默认的最大重发次数（默认 6 次）时，消费端会给 broker 发送一个”poison ack，告诉 broker 不要再发了。这个时候 broker 会把这个消息放到 DLQ（死信队列）。

ActiveMQ 的优缺点

ActiveMQ 采用消息推送方式，所以最适合的场景是默认消息都可在短时间内被消费。数据量越大，查找和消费消息就越慢，消息积压程度与消息速度成反比。

缺点：
1.吞吐量低。由于 ActiveMQ 需要建立索引，导致吞吐量下降。
2.无分片功能。这是一个功能缺失，JMS 并没有规定消息中间件的集群、分片机制。而由于 ActiveMQ 是为企业级开发设计的消息中间件，初衷并不是为了处理海量消息和高并发请求。如果一台服务器不能承受更多消息，则需要横向拆分。ActiveMQ 官方不提供分片机制，需要自己实现。

适用场景：
对 TPS 要求比较低的系统，可以使用 ActiveMQ 来实现，一方面比较简单，能够快速上手开发，另一方面可控性也比较好，还有比较好的监控机制和界面。

不适用的场景：
消息量巨大的场景。ActiveMQ 不支持消息自动分片机制，如果消息量巨大，导致一台服务器不能处理全部消息，就需要自己开发消息分片功能。