为什么不鼓励在Java EE容器中生成线程？ [英] Why is spawning threads in Java EE container discouraged?
问题描述
我学到的关于Java EE开发的第一件事就是我不应该在Java EE容器中生成自己的线程。但是当我开始思考它时，我不知道原因。
One of the first things I've learned about Java EE development is that I shouldn't spawn my own threads inside a Java EE container. But when I come to think about it, I don't know the reason.
你能清楚地解释为什么气馁吗？
Can you clearly explain why it is discouraged?
我相信大多数企业应用程序都需要某种异步工作，如邮件守护进程，空闲会话，清理工作等。
I am sure most enterprise applications need some kind of asynchronous jobs like mail daemons, idle sessions, cleanup jobs etc.
所以，如果确实不应该生成线程，那么在需要时这样做的正确方法是什么？
So, if indeed one shouldn't spawn threads, what is the correct way to do it when needed?
推荐答案
不鼓励使用，因为服务器要管理并可能监视环境中的所有资源。此外，正在使用线程的大部分上下文通常附加到执行线程本身。如果您只是启动自己的线程（我相信某些服务器甚至不允许），它就无法访问其他资源。这意味着，您无法获取InitialContext并执行JNDI查找以访问其他系统资源，例如JMS连接工厂和数据源。
It is discouraged because all resources within the environment are meant to be managed, and potentially monitored, by the server. Also, much of the context in which a thread is being used is typically attached to the thread of execution itself. If you simply start your own thread (which I believe some servers will not even allow), it cannot access other resources. What this means, is that you cannot get an InitialContext and do JNDI lookups to access other system resources such as JMS Connection Factories and Datasources.
有很多方法可以执行此操作正确，但它取决于所使用的平台。
There are ways to do this "correctly", but it is dependent on the platform being used.
commonj WorkManager对于WebSphere和WebLogic以及其他人来说很常见
从今天早晨起这一个也有些重复
Also somewhat duplicates this one from this morning
更新：请注意，这个问题和答案与2009年的Java EE状态有关，自那时起情况有所改善！
UPDATE: Please note that this question and answer relate to the state of Java EE in 2009, things have improved since then!
这篇关于为什么不鼓励在Java EE容器中生成线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
