EJB 规范说您不应该管理线程。我已经看到 Bean 代码发送远程请求并使用 Thread.sleep 循环等待响应以减少 CPU 使用率。据我了解，这违反了规范。简单地从一个单独的 POJO 或库中调用逻辑，然后在 EJB 的方法中引用它来解决这个问题吗？简单地删除 Thread.sleep 是否会以额外的 CPU 消耗为代价来解决问题？外部同步请求应该如何在 EJB 中编码？
【问题讨论】：
标签： java jakarta-ee ejb-3.2
这取决于业务案例。 EJB 规范为异步/同步处理提供了大量资源，无需使用 Thread、Runnable 或任何其他机制的样板代码。
要异步执行一段或代码（即调用者不会等待响应，而是继续执行），请使用@Asynchronous，如果您想在后面听响应，请使用Future<T>。
您所说的同步调用是等待响应的调用，因此“外部同步请求应该如何在 EJB 中编码”是不需要任何类型的异步的东西/后台执行。您只需进行调用，代码本身就会等待响应（否则它将是异步的），典型的情况是 Web 服务（REST 或 SOAP）。
Web 服务调用实际上可以是同步或异步的，这取决于业务案例，但它们通常是同步的，您进行调用并接收带有数据的响应。在需要一段时间执行的业务逻辑的情况下，Web Service 接收请求并可能异步启动业务逻辑（例如使用 @Asynchronous）并立即使用普通 HTTP 202 - Accepted 响应，这基本上意味着“嘿！你刚刚发给我的请求需要一段时间，所以我会在后台处理。
在这种情况下，您可能需要检查另一个 Web 服务，以了解该长期过程的进展情况。这是我能想到的唯一一种情况，在这种情况下，有人会希望 Thread.sleep(...) 在循环中检查 Web 服务，直到它告诉您该过程已完成。
幸运的是，EJB 还为该业务案例提供了解决方案：
@Schedule 方法，以防您需要在特定的时间间隔内检查/执行某些事情：每天凌晨 2:00，或每月第一天，甚至每 2 秒执行一次。李>
TimerService 和@Timeout，以防您想以编程方式安排单个任务。最后一个更适合我们正在讨论的商业案例。因此，您调用TimerService 并指定您希望等待下一次检查的时间跨度。当时间到来时，@Timeout 方法被触发，您可以在其中检查您需要的任何内容，并在需要时安排另一个执行，即使是新的时间跨度。
【讨论】：