ActiveMQ 鏈接池

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秒。