一、生產者優化策略
默認情況下，ActiveMQ服務端認為生產者端發送的是PERSISTENT Message。所以如果要發送NON_PERSISTENT Message，那么生產者端就要明確指定。發送NON_PERSISTENT Message時，消息發送方默認使用異步方式：即是說消息發送后發送方不會等待NON_PERSISTENT Message在服務端的任何回執。為避免MQ消息堆積但發送方不知道無法采取策略的情況，消息發送者會在發送一定大小的消息后等待服務端進行回執，可以通過代碼設置回執點或者設置每次都等待服務端回執。connectionFactory.setProducerWindowSize(102400); 設置消息發送者在累計發送102400byte大小的消息后（可能是一條消息也可能是多條消息）
等待服務端進行回執,以便確定之前發送的消息是否被正確處理，確定服務器端是否產生了過量的消息堆積，需要減慢消息生產端的生產速度。
如果您不特意指定消息的發送類型，那么消息生產者默認發送PERSISTENT Meaage。這樣的消息發送到ActiveMQ服務端后將被進行持久化存儲（比較耗時），並且消息發送者默認等待ActiveMQ服務端對這條消息處理情況的回執。為了提高ActiveMQ在接受PERSISTENT Meaage時的性能，ActiveMQ允許開發人員遵從JMS API中的設置方式，為消息發送端在發送PERSISTENT Meaage時提供異步方式，connectionFactory.setUseAsyncSend(true);此時要設置回執點。
JMS規范中支持帶事務的消息，也就是說您可以啟動一個事務（並由消息發送者的連接會話設置一個事務號Transaction ID），然后在事務中發送多條消息。這個事務提交前這些消息都不會進入隊列（無論是Queue還是Topic）。
生產流控制，是ActiveMQ消息生產者端最為重要的性能策略，它主要設定了在ActiveMQ服務節點在產生消息堆積，並超過限制大小的情況下，如何進行消息生產者端的限流。在ActiveMQ的主配置文件activemq.xml中，關於ProducerFlowControl策略的控制標簽是“destinationPolicy”和它的子標簽，可以配置每個隊列是否啟用生產者流控，以及每個Queue的最大內存限制。有關於policyEntry標簽的所有配置選項都有完整說明：http://activemq.apache.org/per-destination-policies.html。
二、消費者端優化策略
比起消息生產者來說消息消費者的性能更能影響ActiveMQ系統的整體性能，因為要成功完成一條消息的處理，它的工作要遠遠多於消息生產者。默認情況下ActiveMQ服務端采用異步方式向客戶端推送消息。也就是說ActiveMQ服務端在向某個消費者會話推送消息后，不會等待消費者的響應信息，直到消費者處理完消息后，主動向服務端返回處理結果。
ActiveMQ系統中，默認的策略是ActiveMQ服務端一旦有消息，就主動按照設置的規則推送給當前活動的消費者。其中每次推送都有一定的數量限制，這個限制值就是prefetchSize。針對Queue工作模型的隊列和Topic工作模型的隊列，ActiveMQ有不同的默認“預取數量”；針對NON_PERSISTENT Message和PERSISTENT Message，ActiveMQ也有不同的默認“預取數量”：
- PERSISTENT Message—Queue：prefetchSize=1000
- NON_PERSISTENT Message—Queue：prefetchSize=1000
- PERSISTENT Message—Topic：prefetchSize=100
- NON_PERSISTENT Message—Topic：prefetchSize=32766
ActiveMQ中設置的各種默認預取數量一般情況下不需要進行改變。但是非必要情況下，請不要設置prefetchSize=1，因為這樣就是一條一條的取數據；也不要設置為prefetchSize=0，因為這將導致關閉服務器端的推送機制，改為客戶端主動請求。
JMS規范除了為消息生產者端提供事務支持以外，還為消費服務端准備了事務的支持。您可以通過在消費者端操作事務的commit和rollback方法，向服務器告知一組消息是否處理完成。采用事務的意義在於，一組消息要么被全部處理並確認成功，要么全部被回滾並重新處理。
如果一條消息被不斷的處理失敗，那么最可能的情況就是這條消息承載的業務內容本身就有問題。那么無論重發多少次，這條消息還是會處理失敗。為了解決這個問題，ActiveMQ中引入了“死信隊列”（Dead Letter Queue）的概念。即一條消息再被重發了多次后（默認為重發6次redeliveryCounter==6），將會被ActiveMQ移入“死信隊列”。開發人員可以在這個Queue中查看處理出錯的消息，進行人工干預。默認情況下“死信隊列”只接受PERSISTENT Message，如果NON_PERSISTENT Message超過了重發上限，將直接被刪除。