查看侦听器容器配置中的并发设置。 Spring JMS doc 建议应该设置并发性主题监听器为1。请参阅下文。

并发：为每个侦听器启动的并发会话/使用者数。可以是表示最大数字的简单数字（例如5）或表示较低数字和上限的范围（例如3-5）。请注意，指定的最小值只是一个提示，可能会在运行时被忽略。默认值为1; 在主题侦听器的情况下将并发限制为1，或者队列排序很重要;考虑将其提升为一般队列。

这篇文章与你提出的其他问题类似。

如果您需要多个线程来跟上消息量，您的消息监听器可以委托给Spring TaskExecutor 以异步方式处理消息。 TaskExecutors可以由许多实现支持，包括线程池。

I am setting up a JMS subscriber listener as follows with the goal of achieving a pool of 5 threads listening to topATopic, however, what I see at runtime is multiple consumers processing the same record (recordCount*#of consumers).

I am assuming I am doing something wrong considering I am new to spring.

<bean id="messageListener" class="com.abc.app.mdp.Receiver">
<property name="bean" ref="bean" />
</bean>

<jms:listener-container container-type="default"
connection-factory="connectionFactory" acknowledge="auto" concurrency="5" destination-type="topic" prefetch="1" cache="none" >
<jms:listener destination="topCli_Service" ref="messageListener" 
method="onMessage" subscription="AProjectSubscriber" />
</jms:listener-container>

<bean id="connectionFactory" class="org.springframework.jndi.JndiObjectFactoryB ean">
<property name="jndiName" value="jms/jms-top-notx" />
</bean>

Can somebody please point me in a direction to achieve my goal?

Take a look at the concurrency setting on your listener container configuration. The Spring JMS doc suggests that concurrency should be set to 1 for topic listeners. See below.

concurrency: The number of concurrent sessions/consumers to start for each listener. Can either be a simple number indicating the maximum number (e.g. "5") or a range indicating the lower as well as the upper limit (e.g. "3-5"). Note that a specified minimum is just a hint and might be ignored at runtime. Default is 1; keep concurrency limited to 1 in case of a topic listener or if queue ordering is important; consider raising it for general queues.

This post is similar to the rest of your question.

If you need multiple threads to keep up with message volume, your message listener could delegate to a Spring TaskExecutor to process the messages asynchronously. TaskExecutors can be backed by a number of implementations including Thread Pool.