在PubSub+ JCSMP API中的线程安全性

PubSub+ JCSMP API 确保某些 API 元素是线程安全的，而其他元素则由应用程序开发人员负责。下表列出了每个 API 元素的线程安全性由谁负责：

PubSub+ API 的元素	线程安全性
API 内置
线程安全性	应用程序开发者的
责任
---	---
上下文
会话
流
消息
事务会话
事务流

上下文、会话和流：线程安全

您的企业可能需要多个上下文来组织应用程序和事件代理之间的通信。同样，您的应用程序可能在单个会话中使用多个发布者或接收者，需要多个线程。为了确保您的应用程序在运行期间可以依赖确定的 API 结果，消息传递 API 保证您创建的所有上下文、会话和流都是线程安全的。消息传递 API 使用两种内置机制来确保上下文、会话和流（允许保证消息传递）保持线程安全：

PubSub+ 消息传递 API 中的所有回调都发生在同一个内部上下文线程上，这使得它们是线程安全的。

互斥锁（互斥）锚点

为了确保线程安全，消息传递 API 使用互斥锁来限制一段代码只能由一个线程执行。在该线程执行了该代码段后，该代码段将被解锁，另一个线程可以访问它。使用互斥锁确保一次只有一个线程可以访问多个线程共享的资源。

序列化锚点

有时，线程安全可能需要跨越数百或数千行代码。为了避免锁定大量代码段（这可能导致程序阻塞并变得低效），消息传递 API 使用序列化。通过序列化，特定操作的任务被安排在一条线程上，以便它们按特定顺序发生，并防止它们同时运行。这确保了这些任务按顺序运行，不会相互冲突。

由于序列化发生在消息传递 API 上下文线程上，因此您无需在应用程序中实现它。

这两种机制的结合确保了在多线程的企业应用程序中使用上下文、流和会话时，不会出现不确定的结果或意外行为。

消息：开发人员责任锚点

消息传递 API 不保证消息是线程安全的；然而，这更多地与事件流的性质有关，而不是数据稳定性。我们建议您在单个线程上实现单个消息处理。这确保了每条消息的有效载荷不会受到竞争条件或线程安全问题的影响，否则可能导致不确定的结果。

事务会话和事务流：开发人员责任锚点

所有 PubSub+ 消息传递 API 都仅支持本地事务（JMS 除外，它还支持分布式事务），并且由于本地事务是基于 JMS 事务建模的，因此它们遵循 JMS 协议。JMS 协议要求本地事务（包括事务流和事务会话）由单个线程处理。这是因为事务会话没有明确的开始或结束，并且事务的完成需要提交调用。事务提交后，它被视为已完成。在这一点上，事务消息被发送或接收，并且开始了一个新的事务。这意味着所有事务会话或流的处理必须由单个线程处理和控制，类似于消息处理。尽管这意味着事务会话和事务流在技术上不是线程安全的，但它们以单线程方式运行，不会带来任何线程安全风险。