1.先讲严重的：服务挂掉。html
这得从ActiveMQ的储存机制提及。在一般的状况下，非持久化消息是存储在内存中的，持久化消息是存储在文件中的，它们的最大限制在配置文件的<systemUsage>节点中配置。可是，在非持久化消息堆积到必定程度，内存告急的时候，ActiveMQ会将内存中的非持久化消息写入临时文件中，以腾出内存。虽然都保存到了文件里，但它和持久化消息的区别是，重启后持久化消息会从文件中恢复，非持久化的临时文件会直接删除。java
那若是文件增大到达了配置中的最大限制的时候会发生什么？我作了如下实验：apache
设置2G左右的持久化文件限制，大量生产持久化消息直到文件达到最大限制，此时生产者阻塞，但消费者可正常链接并消费消息，等消息消费掉一部分，文件删除又腾出空间以后，生产者又可继续发送消息，服务自动恢复正常。缓存
设置2G左右的临时文件限制，大量生产非持久化消息并写入临时文件，在达到最大限制时，生产者阻塞，消费者可正常链接但不能消费消息，或者本来慢速消费的消费者，消费忽然中止。整个系统可链接，可是没法提供服务，就这样挂了。服务器
具体缘由不详，解决方案：尽可能不要用非持久化消息，非要用的话，将临时文件限制尽量的调大。网络
详细配置信息见文档：http://activemq.apache.org/producer-flow-control.html异步
这得从java的java.net.SocketException异常提及。简单点说就是当网络发送方发送一堆数据，而后调用close关闭链接以后。这些发送的数据都在接收者的缓存里，接收者若是调用read方法仍旧能从缓存中读取这些数据，尽管对方已经关闭了链接。可是当接收者尝试发送数据时，因为此时链接已关闭，因此会发生异常，这个很好理解。不过须要注意的是，当发生SocketException后，本来缓存区中数据也做废了，此时接收者再次调用read方法去读取缓存中的数据，就会报Software caused connection abort: recv failed错误。socket
经过抓包得知，ActiveMQ会每隔10秒发送一个心跳包，这个心跳包是服务器发送给客户端的，用来判断客户端死没死。若是你看过上面第一条，就会知道非持久化消息堆积到必定程度会写到文件里，这个写的过程会阻塞全部动做，并且会持续20到30秒，而且随着内存的增大而增大。当客户端发完消息调用connection.close()时，会期待服务器对于关闭链接的回答，若是超过15秒没回答就直接调用socket层的close关闭tcp链接了。这时客户端发出的消息其实还在服务器的缓存里等待处理，不过因为服务器心跳包的设置，致使发生了java.net.SocketException异常，把缓存里的数据做废了，没处理的消息所有丢失。tcp
解决方案：用持久化消息，或者非持久化消息及时处理不要堆积，或者启动事务，启动事务后，commit()方法会负责任的等待服务器的返回，也就不会关闭链接致使消息丢失了。函数
关于java.net.SocketException请看个人详细研究：http://blog.163.com/_kid/blog/static/3040547620160231534692/
3.持久化消息很是慢。
默认的状况下，非持久化的消息是异步发送的，持久化的消息是同步发送的，遇到慢一点的硬盘，发送消息的速度是没法忍受的。可是在开启事务的状况下，消息都是异步发送的，效率会有2个数量级的提高。因此在发送持久化消息时，请务必开启事务模式。其实发送非持久化消息时也建议开启事务，由于根本不会影响性能。
4.消息的不均匀消费。
有时在发送一些消息以后，开启2个消费者去处理消息。会发现一个消费者处理了全部的消息，另外一个消费者根本没收到消息。缘由在于ActiveMQ的prefetch机制。当消费者去获取消息时，不会一条一条去获取，而是一次性获取一批，默认是1000条。这些预获取的消息，在还没确认消费以前，在管理控制台仍是能够看见这些消息的，可是不会再分配给其余消费者，此时这些消息的状态应该算做“已分配未消费”，若是消息最后被消费，则会在服务器端被删除，若是消费者崩溃，则这些消息会被从新分配给新的消费者。可是若是消费者既不消费确认，又不崩溃，那这些消息就永远躺在消费者的缓存区里没法处理。更一般的状况是，消费这些消息很是耗时，你开了10个消费者去处理，结果发现只有一台机器吭哧吭哧处理，另外9台啥事不干。
解决方案：将prefetch设为1，每次处理1条消息，处理完再去取，这样也慢不了多少。
详细文档：http://activemq.apache.org/what-is-the-prefetch-limit-for.html
5.死信队列。
若是你想在消息处理失败后，不被服务器删除，还能被其余消费者处理或重试，能够关闭AUTO_ACKNOWLEDGE，将ack交由程序本身处理。那若是使用了AUTO_ACKNOWLEDGE，消息是何时被确认的，还有没有阻止消息确认的方法？有！
消费消息有2种方法，一种是调用consumer.receive()方法，该方法将阻塞直到得到并返回一条消息。这种状况下，消息返回给方法调用者以后就自动被确认了。另外一种方法是采用listener回调函数，在有消息到达时，会调用listener接口的onMessage方法。在这种状况下，在onMessage方法执行完毕后，消息才会被确认，此时只要在方法中抛出异常，该消息就不会被确认。那么问题来了，若是一条消息不能被处理，会被退回服务器从新分配，若是只有一个消费者，该消息又会从新被获取，从新抛异常。就算有多个消费者，每每在一个服务器上不能处理的消息，在另外的服务器上依然不能被处理。难道就这么退回--获取--报错死循环了吗？
在重试6次后，ActiveMQ认为这条消息是“有毒”的，将会把消息丢到死信队列里。若是你的消息不见了，去ActiveMQ.DLQ里找找，说不定就躺在那里。
详细文档：http://activemq.apache.org/redelivery-policy.html
http://activemq.apache.org/message-redelivery-and-dlq-handling.html