我在 Adam Bien 的 JavaEE night hacks 书中读到，虽然 EJB 容器上禁止创建线程，但 Web 容器却并非如此。他实际上在他的 X 射线探测器中创建了一个在 Tomcat 上运行的线程池执行器。
我现在有点困惑。虽然我遇到了必须在 EE 应用程序中进行手动线程池管理的情况，但我能以某种方式理解为什么在 JavaEE 容器中手动创建线程是一个坏主意。但是，当您可以将大部分 EJB 部署到任一容器时，我不明白 EJB 容器和 Web 容器在线程创建方面的区别。如果 session bean 在 Web 容器中生成线程没有任何问题，那么将相同的 session bean 部署到 EJB 容器可能会导致什么问题？
最佳答案
这是 Java EE 的“企业”部分与现实世界相遇的地方。
使用“企业”系统的前提主要是围绕管理。具体来说，将决策和配置交给容器，而不是依赖应用程序本身来管理这些资源。通过将资源的创建和管理与应用程序代码分离并依赖于容器，系统管理员可以查看并访问这些资源，从而有可能以通用的方式在更高级别上调整和监控应用程序，而不是为此使用特定于应用程序的机制。
所以，这就是我们所处的环境，也是插入 Java EE 规范中有关您可以做什么和不可以(不应该)做什么的“规则”的一部分。
现在，servlet 容器规范更加狂野西部。它不具备所有这些“企业”管理功能(请注意，许多容器公开了它们，但规范没有提及它们)。例如，提供静态文件是 Web 容器的一项基本功能，因此限制开发人员对所述文件的访问几乎没有意义。另外，servlet 规范出现在 EJB 规范之前，并且被固定到环境中，而不是根据该环境重新制定。
这为您提供了在特定事物(例如线程)方面的两个“矛盾”规范。
所以，是的，Servlet 规范“让您”管理自己的线程池，即使在 Java EE 应用程序中也是如此，即使这些线程池可能位于完全相同的 JVM 中(因此“难以管理”地消耗 Java EE 资源) )作为 Java EE 容器。
这在现实世界中的最终意义是，是的，如果您愿意，您可以在 Java EE 容器或 servlet 容器中对线程等进行假脱机处理。没有一个流行的容器会禁止您这样做(WebSphere 可能会，我不使用它)。
但是，你不应该这样做。 Java EE(尤其是 Java EE 6)具有您可以跳过的机制和环路来执行操作，而不是使用线程池。像 WorkManager、JMS 队列、异步 session bean、计时器作业之类的东西。
在 servlet 应用程序中，大多数机制都不存在，因此您无法利用它们，因此您可以使用“仅 Java”。
在使用 Java EE 应用程序部署的 Web 应用程序中使用“Just Java”的后果是容器内的可见性。例如，您的网络应用程序需要自己的配置变量来设置其线程池的大小，并且不能依赖容器来管理它。
最后，这通常没什么大不了的。 Java EE 的大部分复杂性都集中在许多人不使用的管理功能上。就我自己而言，我使用 Java EE，很少使用普通的 OL WAR，我喜欢将尽可能多的内容推送到容器中——让它完成它的工作。也就是说，我在 Java EE 容器的 WAR 中运行自定义套接字服务器，这打破了所有可以想象的规则，只是因为它更容易做到。 “Java EE 方式”对于我们想要完成的事情来说还不够灵活，所以我们选择了“Just Java”并将代码注入(inject)到 WAR 中，这样我们就可以在狂野的西部玩耍，在那里，男人就是男人，管理自己的线程。
关于java - JavaEE EJB/Web 容器中的线程创建，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13161634/