摘要：本文旨在指出中集成的一些性能陷阱，在另一篇文章各組件詳解里有組件介紹及如何正確使用的內(nèi)容。因此的做法會大大降低性能，并且將大部分的時間都花在反復(fù)重建這些對象上。提供的可以讓使用避免頻繁創(chuàng)建的問題。至于使用的性能測試則留給同學(xué)自己做了。

Github

本文旨在指出Spring/Spring Boot中集成JMS的一些性能陷阱，在另一篇文章Spring JMS各組件詳解里有Spring JMS組件介紹及如何正確使用的內(nèi)容。

Spring提供了JmsTemplate用來簡化JMS的操作，但是JmsTemplate的性能是有很大問題的，主要體現(xiàn)在以下幾個方面：

根據(jù)Artemis官方文檔的說法，JmsTemplate是一種anti-pattern，如果在使用JmsTemplate的情況下覺得很慢，那么就不要怪Artemis。

并且Connection，Session，Producer，Consumer這些對象本身設(shè)計上是可以復(fù)用的。因此JmsTemplate的做法會大大降低性能，并且將大部分的時間都花在反復(fù)重建這些對象上。

Spring提供的Workaround

可以讓JmsTemplate使用SingleConnectionFactory避免頻繁創(chuàng)建Connection的問題。或者其子類CachingConnectionFactory避免頻繁創(chuàng)建Connection，Session，Producer，Consumer的問題。

JmsTemplate#sendAndReceive方法可以用來模擬RPC調(diào)用過程，內(nèi)部原理是：

A程序創(chuàng)建一個臨時Queue作為接受相應(yīng)的Queue

send一個Message到Queue，并在這個臨時Queue上等待結(jié)果

B程序consume了這個Message把結(jié)果send到那個臨時Queue

A接受到結(jié)果，把這個臨時Queue干掉

當(dāng)然整個過程中還包括前面提到的創(chuàng)建Connection，Session，Producer，Consumer的動作。

不出所料，Artemis官方文檔也提到了，頻繁創(chuàng)建臨時Queue是一種anti-pattern，會大大影響性能。

使用@JmsListener注解可以很方便的用來consume消息，但它是同步而非異步，這個和官方文檔所說的恰恰相反（關(guān)于sync/async consume消息的資料）。

Spring Boot的JmsAnnotationDrivenConfiguration默認(rèn)使用DefaultJmsListenerContainerFactory生成DefaultMessageListenerContainer ，而它的內(nèi)部原理是使用TaskExecutor發(fā)起多個線程同時從Queue中拉取消息，這也就是為什么Spring官方文檔里說如果監(jiān)聽的是Topic且concurrency > 1，那么可能會收到重復(fù)消息的原因。

DefaultMessageListenerContainer的javadoc中說道：

Actual MessageListener execution happens in asynchronous work units which are created through Spring"s TaskExecutor abstraction

這里就有個矛盾，如果使用async的方式consume消息，那么只需給consumer設(shè)置MessageListener就行了，何必使用TaskExecutor呢？

一看代碼果然不出所料：

DefaultMessageListenerContainer#runcallinvokeListener

然后callAbstractPollingMessageListenerContainer#receiveAndExecute

然后calldoReceiveAndExecute

然后callreceiveMessage

然后callreceiveFromConsumer

然后callJmsDestinationAccessor#receiveFromConsumer這個方法調(diào)用了MessageConsumer#consume

也就是說Spring只是使用一個或多個線程在不停的同步的consume消息而已。

雖然可以使用concurrency參數(shù)提高并發(fā)，但是多線程從Queue/Topic中consume消息的性能比javax.jms.MessageConsumer#setMessageListener的方法要低上很多。

有興趣的同學(xué)可以使用Artemis Example（下載地址）里的JMS Perf代碼做一下測試，它的測試代碼用的是javax.jms.MessageConsumer#setMessageListener的方式來consume消息的，在配置正確的情況下可以達(dá)到接近10w/s。至于使用MessageConsumer.receive的性能測試則留給同學(xué)自己做了。

還是之前提到的JmsAnnotationDrivenConfiguration，使用的DefaultJmsListenerContainerFactoryConfigurer默認(rèn)是把session設(shè)置為transacted的。

根據(jù)測算，當(dāng)一個session是transacted的時候其性能會相差20%，有興趣的同學(xué)可以使用Artemis Example（下載地址）里的JMS Perf代碼做一下測試。

下載之后找到examples/jms/perf目錄，看這個目錄下的readme.html獲得執(zhí)行方法，在執(zhí)行之前修改src/main/resources/perf.properties文件，下面是部分參數(shù)的解釋：

num-messages，測試多少個消息

num-warmup-messages，熱身用的消息數(shù)，熱身過之后性能會提升

durable，對應(yīng)DeliveryMode

transacted，是否transacted

batch-size，批量commit的大小

drain-queue，是否測試前先把隊列里已有的消息都清空

可以使用以下兩套配置對比transacted的性能差別：

配置一，transacted=false：

num-messages=100000
num-warmup-messages=1000
message-size=1024
durable=false
transacted=false
batch-size=1
drain-queue=true
destination-lookup=perfQueue
connection-factory-lookup=/ConnectionFactory
throttle-rate=-1
dups-ok-acknowledge=false
disable-message-id=true
disable-message-timestamp=true

配置二，transacted=true：

num-messages=100000
num-warmup-messages=1000
message-size=1024
durable=false
transacted=true
batch-size=1
drain-queue=true
destination-lookup=perfQueue
connection-factory-lookup=/ConnectionFactory
throttle-rate=-1
dups-ok-acknowledge=false
disable-message-id=true
disable-message-timestamp=true

關(guān)于加入事務(wù)控制是否會有性能問題沒有實際測試過，不過值得注意的這是Spring Boot的默認(rèn)行為。

相關(guān)連接：代碼1, 代碼2，代碼3，Javadoc。

Spring將JMS的集成變得非常簡單，只需提供幾個配置參數(shù)就可以了，但是只能提供一種默認(rèn)配置，不管業(yè)務(wù)場景如何都使用同一種配置是非常有問題的。

spring-boot提供了以下幾種方式（文檔）集成JMS：

JNDI

Artemis, native模式和embedded模式

ActiveMQ

這幾種模式的缺點都是只能配置一個ConnectionFactory，這對于簡單應(yīng)用來說沒問題，對于復(fù)雜應(yīng)用來說就顯得不夠用了，這讓你喪失了針對不同場景配置不同ConnectionFactory的機(jī)會。
而且Artemis的native模式只支持host:port，不支持更豐富參數(shù)的url模式。

看過DefaultJmsListenerContainerFactoryConfigurer和JmsAnnotationDrivenConfiguration的代碼就明白了。