java EJB 和线程
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4587673/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
EJB's and Threading
提问by TheWolf
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?
据我所知，从 EJB 内生成线程是非法的，因为它可能会干扰 EJB 的生命周期。但是，使用来自 JDK 的预定义 Java 类是否非法，这些类在 EJB（特别是 MDB）中内部产生和处理线程，例如 Executor？
采纳答案by Charlie Martin
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.
线程和 EJB 的最大问题是线程是容器大量使用的有限资源，线程错误会导致线程池泄漏，从而可以有效地杀死整个 JVM 实例。
Executor shouldbe 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.
Executor应该表现得更好，但它仍然会在一段时间内用完一个线程；如果有人调整了容器以用完可用线程，它也可能会立即失败。
Summary is that you're going to be tightrope walking.
总结是你要走钢丝。
回答by jtahlborn
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“单例”服务来管理线程处理。但是，正如其他人所提到的，最好将其留给应用程序服务器。在应用程序服务器中进行并行处理的一种方法是使用 MDB（听起来您已经在使用它），尽管根据并行处理的类型，这些可能太重了。
回答by David Blevins
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.
这就是 EJB 3.1@Asynchronous的用途，绝对应该用来代替 Executor。与容器的线程池竞争通常是非常危险的。这样做是降低性能的好方法。
The Asynchronoussupport will use the container's thread pools and be far safer. See this answerfor details on how Asynchronousworks.
该Asynchronous支持将使用容器的线程池并且安全得多。有关工作原理的详细信息，请参阅此答案Asynchronous。
回答by Kelly S. French
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.
要添加到@Charlie Martin 的答案中，无论您需要 Executor 做什么，您都可以设计另一个 EJB 来在没有 Executor 的情况下执行相同的操作。这允许新 EJB 在由容器处理的单独线程中运行。缺点是您可能不得不“重新实现轮子”，因为您仍然不想使用来自 JVM 的线程/执行器。它还增加了让一个 EJB 定位/请求/连接/调用另一个 EJB 的开销。
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.
底线是 EJB 本身应该是工作线程。复制代码而不是使用 Executor 似乎有点矫枉过正，这在一定程度上是有道理的。最大的区别是规模之一。Executors 将被限制为单个 JVM，而 EJB 可以跨 JVM 和跨服务器扩展。
