Spring源碼分析總結——Spring整合activeMQ

該文章基於《Spring源碼深度解析》撰寫，感謝郝佳老師的奉獻
承接上文activeMQ的使用，下面來進行源碼分析。

JmsTemplate

在配置文件中我們定義了JmsTemplate，先來看看JmsTemplate的類層次結構：

雖然出現了常見的InitializingBean接口，但是該接口實際上只是一個驗證的功能。
下面來看看實際的方法調用：

public void send(final Destination destination, final MessageCreator messageCreator) throws JmsException {
    this.execute(new SessionCallback<Object>() {
        public Object doInJms(Session session) throws JMSException {
            JmsTemplate.this.doSend(session, destination, messageCreator);
            return null;
        }
    }, false);
}

這種風格及其類似於JdbcTemplate類的實現風格，通過提取一個公共的方法作爲最底層，最通用的功能實現，然後用回調函數的不同來區分個性化的功能。
下面先分析通用代碼的抽取：抽取了Connection，Session的創建以及關閉的通用處理方式。
接下來分析發送消息是如何實現的：首先execute中封裝了冗餘代碼，個性化的代碼放在了回調函數doInJms中進行實現，實現的方式大概步驟是通過Destination創建MessageProceducer，創建Message，並使用MessageProcedure實例來發送消息。
下面接下來來看接收消息的實現，套路與消息發送差不多，都是通過定義內部類，然後調用統一的execute方法然後再調用內部類中定義的doInJms進行個性化方法的實現。

監聽器容器

Spring中提供的監聽器容器一共分爲以下三類：
（1）SimpleMessageListenerContainer，不支持事務，只能處理固定數量的JMS會話
（2）DefaultMessageListenerContainer，建立在SimpleMessageListenerContainer之上，支持事務
下面給出DefaultMessageListenerContainer的類層次結構圖：

初始化的工作仍然在InitializingBean接口的afterPropertiesSet方法中實現，其邏輯爲：
（1）屬性的驗證，connectionFactory和destination屬性是否爲空
（2）初始化，由於可以創建多個Session和MessageConsumer來接收消息（最好在Destination類型爲Queue才使用多個MessageConsumer，否則消息的處理可能會因爲併發的原因而出現錯誤；不應該在Destination爲Topic時使用多個MessageConsumer，其原因也是因爲併發），也正是因爲可以創建多個多個Session和MessageConsumer來接收消息，所以Spring的處理方式是通過創建對應數量的線程，每個線程都作爲獨立的接收者循環接受消息，而線程的實現類是AsyncMessageListenerInvoker，我們通過分析這個類的run方法可以知道，實際上該方法的流程分爲了兩個：
1.允許無限制的接收消息，2.需要控制消息的數量，其實兩者的最終邏輯都是通過invokeListener方法接收消息並激活監聽器，只不過允許無限制接收消息的不同就在於允許暫停線程，以及恢復線程。Spring在處理這個問題上是通過使用全局控制變量lifecycleMonitor的wait方法來暫停線程，並且通過lifecycleMonitor的notifyAll方法恢復線程。
接下來討論消息接受的處理方式：當討論DefaultMessageListenerContainer時由於存在事務管理所以沒法複用模板中的方法，其中包括了1.接收消息，2.模板方法，調用子類的實現，3.激活監聽器，4.處理空消息，我們針對其中的第三點進行重點說明，該方法中除了調用監聽器的onMessage方法進行消息的傳遞，還有一個其他的要點就是消息服務的提交其實包含了兩個事務，其中一個是通用事務，用於處理數據庫提交等問題，其中第二個事務是消息事務，必須使用消息提交的方式告訴服務器本地已經正常接受消息，之後纔可以將此消息刪除，否則會被重新接受