EJB 和线程
据我了解，从 EJB 内部生成线程是非法的，因为它可能会干扰 EJB 的生命周期。但是，使用 JDK 中的预定义 Java 类（这些类在 EJB（特别是 MDB）中内部生成和处理线程，例如 Executor）是否违法？
From what I understand it is illegal to spawn threads from within an EJB as it may potentially interfere with the EJB's lifecycle. However, is it illegal to use predefined Java classes from the JDK which internally spawn and handle threads such as Executor within an EJB, specifically an MDB?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你“不能”（不应该）使用线程、线程池、执行器......以上所有。使用应用程序服务器的要点是仅编写业务逻辑并让应用程序服务器完成繁重的工作。如果您确实需要自己处理线程，请使用 EJB 3.1“单例”服务来管理线程。但是，正如其他人提到的，最好将其留给应用程序服务器。在应用程序服务器中进行并行处理的一种方法是使用 MDB（听起来您已经在使用），尽管根据并行处理的类型，这些可能太重量级了。
You "cannot" (should not) use threads, thread pools, executors... all of the above. the point of using an app server is to only write business logic and let the app server do the heavy lifting. if you really, really need to do your own threading, use an EJB 3.1 "singleton" service to manage the threading. however, as mentioned by others, it's best to leave this to the app server. one way to do parallel processing in an app server is to use MDBs (which it sounds like you already are using), although depending on the type of parallel processing, these may be too heavyweight.
这就是 EJB 3.1
@Asynchronous的用途，并且绝对应该使用它来代替 Executor。与容器的线程池竞争通常是非常危险的。这样做是扼杀性能的好方法。异步支持将使用容器的线程池并且更加安全。请参阅此回答以获取有关异步如何工作的详细信息。This is what EJB 3.1
@Asynchronousis for and definitely should be used instead of an Executor. It's generally very dangerous to compete with the container's thread pools. Doing so is a great way to kill performance.The
Asynchronoussupport will use the container's thread pools and be far safer. See this answer for details on howAsynchronousworks.线程和 EJB 的最大问题是线程是容器大量使用的有限资源，线程错误会导致线程池泄漏，从而有效地杀死整个 JVM 实例。
执行器应该表现得更好，但它仍然会在一段时间内耗尽线程；如果有人调整容器以耗尽可用线程，它也可能会立即失败。
总结就是你将走钢丝。
The biggest issue with threads and EJBs is that threads are a limited resource heavily used by the container, and thread mistakes lead to thread pool leaks that can effectively kill the whole JVM instance.
Executor should be better behaved, but it's still going to use up a thread for some length of time; it also may just fail instantly if someone has tuned the container to use up the available threads.
Summary is that you're going to be tightrope walking.
为了补充 @Charlie Martin 的答案，无论您需要执行器做什么，您都可以设计另一个 EJB 在没有执行器的情况下执行相同的操作。这允许新的 EJB 在由容器处理的单独线程中运行。缺点是您可能必须“重新实现轮子”，因为您仍然不想使用 JVM 中的线程/执行器。它还增加了让一个 EJB 定位/请求/连接/调用另一个 EJB 的开销。
底线是 EJB 本身应该是工作线程。复制代码而不是使用执行器似乎有点矫枉过正，而且在一定程度上也是如此。最大的区别在于规模。执行器将仅限于单个 JVM，而 EJB 可以跨 JVM 和服务器进行扩展。
To add to @Charlie Martin's answer, whatever you need the Executor to do, you could design another EJB to perform the same action without the Executor. This allows the new EJB to run in a separate thread handled by the container. The downside is you might have to "reimplement the wheel" since you still do not want to use threads/Executor from the JVM. It also adds to the overhead of getting one EJB to locate/request/connect/call another.
The bottom line is that EJBs are supposed to be worker threads themselves. It may seem like overkill to replicate code instead of use the Executor and it is up to a point. The biggest distinction is one of scale. Executors will be limited to a single JVM while EJBs can be scaled across JVMs and across servers.