@EJB 注入与查找 - 性能问题

Question

我有一个与使用 @EJB 注释时可能出现的性能问题相关的问题。想象一下以下场景：

public class MyBean1 implements MyBean1Remote{
 @EJB
 private MyBean2Remote myBean2;
 @EJB
 private MyBean2Remote myBean3;
 ...
 @EJB
 private MyBean20Remote myBean20;
}  

有一个 bean 对其他 bean 有许多依赖项。根据 EJB 规范，如果我想将 MyBean1Remote 注入到其他某个 bean，容器必须从其池中获取所有必需的依赖项，将其注入到 MyBean1Remote 中，然后注入对 MyBean1Remote 存根的引用。

因此，在以下场景中，容器需要保留 20 个 ejb（myBean1 及其 19 个依赖项）。

public class MyAnotherBean implement MyAnotherRemote{
  @EJB
  private MyBean1Remote myBean1
}

假设在大多数情况下，我们将仅对 myBean1 的每个业务方法使用单个依赖项。因此，每次我们想要注入该 bean 时，我们都会强制容器保留许多不必要的 EJB。我们还假设我们正在远程 bean 上进行操作，因此容器可能还需要在注入依赖 bean 之前执行一些负载平衡算法。

问题：

1. 在集群环境中运行时，这是否会导致不必要的资源预留和更多的性能问题？

2. 也许旧的 ServiceLocator 可能是更好的解决方案，因为使用这种方法，我们会在真正需要时请求特定的 EJB？

Answer 1

容器不会注入 EJB 实例；它注入一个轻量级容器生成的代理对象的实例，该对象实现所需的接口。

public class MyBean1 implements MyBean1Remote {
   ...
}

public class MyAnotherBean implement MyAnotherRemote {
   @EJB
   private MyBean1Remote myBean1;
}

在您的示例中，MyAnotherBean.myBean1 将注入一个实现 MyBean1Remote 接口的代理对象。

假设是一个无状态会话 bean（因为您提到了池），容器不会从方法就绪池中分配实际的 EJB 实例，直到在代理上调用方法，并且该实例返回到代理方法调用返回之前的池。

Answer 2

在大多数情况下，尤其是在使用无状态会话 bean 时，您的 bean 实例将被池化。池化背后的基本原理之一是依赖项注入查找可能相对昂贵，因此 bean 与已注入的所有依赖项（存根）一起池化。

因此，每次您调用 MyAnotherBean 上的方法时，这个具有 20 个传递依赖项的 Bean 并不是在创建时动态解析所有这些依赖项的。相反，从池中选择一个完全实例化的实例，并将方法调用定向到该实例。

_{另请注意，除非您正在进行 JNDI 联合，否则通常无法轻松注入远程 EJB。}