为什么不鼓励在 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 以及其他工具来说是通用的
也有些重复今天早上的这个
更新:请注意，此问题和答案与 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屋！
