在 ejb 无状态会话 bean 中，方法内创建并返回的对象（如 dto）无需手动清理引用；只要调用方不再持有其引用，这些对象即可被 jvm 正常回收，不会因 bean 实例驻留池中而引发内存泄漏。
在 ejb 无状态会话 bean 中，方法内创建并返回的对象（如 dto）无需手动清理引用；只要调用方不再持有其引用，这些对象即可被 jvm 正常回收，不会因 bean 实例驻留池中而引发内存泄漏。
EJB 容器对无状态会话 Bean 的生命周期管理是高度优化的：容器维护一个实例池，Bean 实例在调用结束后不保留任何业务状态，也不会缓存或持有方法内部临时对象的引用。以如下典型代码为例：
@Stateless
public class MyStatelessBean implements MyLocal {
public MyDTO myMethod() {
MyDTO myDTO = new MyDTO();
myDTO.setId(1L);
myDTO.setName("Example");
// ... 其他字段赋值
return myDTO; // ✅ 返回后，myDTO 引用仅存在于调用方栈/堆中
}
}当 myMethod() 被连续调用 100 次时，容器会复用池中的若干 Bean 实例（可能仅需 2–5 个），但每次调用中创建的 MyDTO 实例均独立于 Bean 生命周期——它们的存活与否完全取决于调用方是否还持有引用。一旦客户端方法执行完毕且未将返回值赋给长期存活的变量（如静态字段、缓存容器、长生命周期 Bean 的成员变量等），这些 DTO 对象就会成为 GC 可回收对象。
⚠️ 关键注意事项：
- ❌ 不需要、也不应该在 Bean 方法内“清空”返回对象的引用（例如 myDTO = null），这毫无意义，且破坏代码可读性；
- ✅ 确保调用方遵循良好的内存实践：避免无意识地将返回的 DTO 缓存到全局集合、静态 Map 或 Session Scoped Bean 中；
- ? 若发生 OutOfMemoryError，应优先通过堆转储（Heap Dump）分析真正泄漏源——99% 的情况与 Stateless Bean 本身无关，而是调用方或中间层（如 Web 层缓存、异步任务队列）意外持有了大量 DTO 引用。
✅ 总结：EJB 无状态 Bean 是“无记忆”的，它既不跟踪、也不持有自己方法中创建的返回对象。内存安全的关键不在 Bean 端，而在调用链的引用边界控制。只要调用方合理管理对象生命周期，即使高频调用，也不会因 DTO 创建导致内存溢出。
