本文共 1760 字，大约阅读时间需要 5 分钟。

 以前对JMS尤其是activeMQ不了解，一看到什么地方需要使用消息中间件，就比较反感。主要原因是感觉JMS的实现都比较复杂，怕在真实使用过程中出现什么问题时会比较被动。所以，我们基本上是自己写类似的消息中间件，当然功能非常简单。但其实我们自己写出来的中间件，随着功能的不断增加、人员和时间的种种问题，导致最终我们自己做出来的所谓消息中间件越来越不能维护。在吸取了一次一次这种重复发明"轮子"的事情中，我们觉得也许一开始就采用成熟开源的产品也许是条更好的方式。 

    感觉到现在或将来我们对JMS的使用会更加深入，为了适应这种的需要，作为软件研发人员，需要对在我们工作中占有重要地位的开源产品有源代码级别的熟悉，尤其对我们这些英语不太好的，因为目前用的多的开源产品基本上是以英语作为基础的，那么我们想要提交一个bug或讨论一个什么用法的时候，就比较被动，而且眼巴巴的等着其他人来解决，自己一点都  使不上劲的感觉真的很不舒服。      我们选择activeMQ来分析它的核心架构、源代码，就是希望能尽量少的发生上面的情况，尤其在我们分析activeMQ的过程中，发现其源代码中确实存在不少小问题。消息中间件在许多项目或产品中占有非常重要的地位，虽然我们目前还不是activeMQ的代码提交人员，但希望通过对activeMQ的源码分析这种方式，同样为使用activeMQ的同行们提供一点帮助，也算是间接为开源做点事情。      在后面的一系列文章中，我们将主要从如下几个方面来分析:        一、activeMQ的核心线程的功能和生命周期     二、消息存储的kaha实现的分析    三、消息队列(Queue)实现的分析

   四、activeMQ的领域模型

   五、activeMQ中TCP通讯机制    六、activeMQ的Cluster    七、activeMQ中内存使用和管理     作为开篇，首先我们非常尊重activeMQ的所有committer，它是个不错的软件作品，我们的分析是基于5.1版本的代码，就象任何事情一样，尤其是软件产品它的成熟是需要较长时间的过程，我们也会把分析中发现的5.1版本的bug于大家分享，下面我就以一个小bug作为整个activeMQ分析的开篇。      为了表述的方便，我们把这个bug叫做bug_1，为了讲清楚该bug，首先我会把相关的背景做一个介绍：      消息指针(Message cursor)是activeMQ里一个非常重要的核心类，它是提供某种优化消息存储的方法。消息中间件的实现一般都是当消息消费者准备好消费消息的时候，它会从持久化  存储中一批一批的读取消息，并发送给消费者。消息指针维护着下一批待读取消息的相关位置信息。      消息指针在对不同的消息消费者时，它的内部处理机制也不一样：      1.当消费者跟得上消息生产者的时候，是快消费者。那这种时候Message cursor的内部过程如下图所示：      2.当消费者慢于消息生产者的时候，是慢消费者。那这种时候Message cursor的内部过程如下图所示：

    上面两种情况是能自动调整的，当一个消费者从快变成慢或从慢变成快的时候，Message cursor应该做自动的调整，在5.1里面这种自动调整有点小bug，它只能从快变成慢，反之则不行。具体bug原因应该是疏忽写错了，代码在类AbstractStoreCursor中的public final synchronized void remove()方法中的if (size==0 && isStarted() && cacheEnabled)这一行，只用把cacheEnabled改为useCache就可以了。(该bug已经被后续版本所修复)      我们非常愿意能推动activeMQ的使用，并希望能够结合activeMQ做一些相关的辅助工作。所以如果大家在实际工作中碰到使用activeMQ的各种问题，如群集，消息重发等等，都可以告诉我们，大家一起交流，同时我们也会在线下召开一些交流activeMQ使用和研究的聚会，我们的联系方式：email: yunweitec@yahoo.cn   qq号码：ActiveMQ研究群 62835781

原文链接：http://blog.csdn.net/kongqz/article/details/4014788