蛋疼的PooledConnectionFactory

PooledConnectionFactory有两个属性maxConnections，maximumActive。咋一看来，用人类的常识理解，maxConnection应该表示最大可建的connection数，maximumActive应该表示最大活跃的connection数，当pool中的连接数大于最大活跃数时，又超过idleTimeout会被回收线程回收到。

如果是这样理解的，就大错特错了。PooledConnetionFactory的这两个参数根本不是这个意思。

看一下PooledConnectionFactory的组成结构：



注：ConnectionPool其实存储的就是一个ActivemqConnection，起的名字真是蛋疼。

更糟的是上面两个属性也不是我们想的一样。maxConnections表示的是LinkedList中connection的数目。maximumActive表示的是SessionPool中session的最大数目。IdleTime是Connection的回收时间，回收时也不是多线程的，每次getConnection时，都会检测是否超时，如果超时，就是立即回收，此时立即重建，真蛋疼。SeesionPool是用Commons-pool实现的。

上图的结构表示的是一个PooledConnetion维护了一个Map，Map的Key可以是由username，password决定的， LinkedList维护了一个循环链表的ActivemqConnection。每次从LinkedList中的头部取出一个AactivemqConnection，然后再添加到尾部，简单的轮询式的负载均衡。而这些ActivemqConnection是可以被多线程重用的。Pool实现中也没有connection是否inactive的检测机制，因为ActivemqConnection有自己的heartbeat检测机制。每次发送或接收时候先从ConnectionPool中取出一个connection，如果Connection都用光了，就会重用在链表头部的Connection的SessionPool，所以一个Connection可能会被多个线程使用，但一个session只会对应一个线程，保证上下文隔离性。多线程同享一个物理信道，这需要Activemq有自己的拆包机制，才不会混乱。而上面提到的负载均衡，也没考虑到session的使用情况，可能我从头部拿出的connection的session
pool已经被耗光，而尾部的connection session pool却很空闲，这样就要无辜的阻塞等待session。

这样看来在我们设置PooledConnection时，建议有条件的还是需要把maxConnections设置的大一些。它的默认值是1。maximumActive可以设的相对小一些，它的默认值是500，这值太大，担心内存溢出。IdleTime有条件的可以设置的大一些，增加connection的重用时间，默认值是30秒。