在 ejb stateless bean 中，方法内创建并返回的对象（如 dto）无需手动清理引用；只要调用方不再持有该对象的强引用，jvm 垃圾回收器即可正常回收，不会因 bean 实例驻留池中而引发内存泄漏。
在 ejb stateless bean 中，方法内创建并返回的对象（如 dto）无需手动清理引用；只要调用方不再持有该对象的强引用，jvm 垃圾回收器即可正常回收，不会因 bean 实例驻留池中而引发内存泄漏。
Stateless Session Bean 的核心设计原则是“无状态”——它不维护任何客户端相关的实例变量或外部对象引用。正如 EJB 规范所定义，容器会将多个无状态 Bean 实例缓存在池中，以复用资源、提升并发性能。但关键在于：Bean 实例自身绝不会长期持有其方法内部临时对象的引用。
以您提供的代码为例：
@Stateless
public class MyStatelessBean implements MyLocal {
public MyDTO myMethod() {
MyDTO myDTO = new MyDTO(); // 在栈帧中创建，生命周期绑定于方法调用
myDTO.setField("value");
// ... 其他赋值逻辑
return myDTO; // 返回的是对象引用，但 Bean 本身不保留该引用
}
}当 myMethod() 执行完毕，方法栈帧被销毁，局部变量 myDTO 引用随之消失。即使该 Bean 实例后续被容器重复用于其他请求，它也不会持有此前任意一次调用中创建的 MyDTO 实例——因为这些对象仅通过方法返回值传递给调用方，Bean 自身无字段、无静态集合、无缓存结构来保存它们。
✅ 正确行为示例（调用方）：
@Stateless
public class ClientBean {
@EJB private MyLocal myBean;
public void process() {
MyDTO dto1 = myBean.myMethod(); // 引用存在，对象可达
// ... 使用 dto1
dto1 = null; // 显式置空非必需，但若后续长时间不使用可辅助 GC 判断
// 此后若无其他强引用，dto1 将在下次 GC 时被回收
}
}⚠️ 真正需警惕的情形（而非 Bean 侧问题）：
- 调用方将返回的 DTO 存入静态集合（如 static List
cache = new ArrayList();）； - 将 DTO 作为长生命周期对象（如 Servlet 上下文、单例服务）的成员变量持有；
- 在异步线程中未正确管理引用（如提交至线程池后忘记清理闭包捕获）。
这些场景导致的内存堆积，根源在于调用方的引用管理不当，与 Stateless Bean 的池化机制完全无关。Bean 池的存在仅影响 Bean 实例的复用，不影响其方法中创建的临时对象的生命周期。
? 总结与最佳实践：
- ✅ Stateless Bean 方法内创建并返回的对象，天然具备“即用即弃”特性，无需在 Bean 内做任何清理；
- ✅ 调用方应遵循常规 Java 内存管理原则：避免不必要的长周期强引用，及时释放不再使用的对象（尤其在循环或高吞吐场景）；
- ❌ 不要尝试在 Bean 方法末尾添加 myDTO = null; 等操作——这既无意义（局部变量作用域已结束），也违背无状态设计初衷；
- ? 若遭遇 OutOfMemoryError，应优先通过 JVM 堆转储（Heap Dump）分析实际存活对象及其引用链，而非假设 Stateless Bean “泄露了 DTO”。
简言之：Stateless 是可靠的，GC 是可信的，责任在调用方——写好业务逻辑，让对象自然消亡。
