使用 EJB 的实例池如何提高性能？
使用 EJB 的实例池如何提高性能？难道仅使用 Java Servlet 之类的线程就无法实现相同的性能吗？
或者 EJB 实例池的发生可能是出于其他原因？
How is that instance pooling with EJBs can improve performance? Wouldn't you be able to accomplish the same performance just with threads like a java servlet?
Or perhaps instance pooling with EJBs happens for another reason?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
实例池不仅有帮助，因为您可以重复使用对象（并避免昂贵的对象创建），而且还允许应用程序。服务器正确管理负载。这是应用程序。服务器特定，但您通常可以指定 max-pool-size、min-pool-size、pool-resize 和超时。
当池达到其
max-pool-size容量时，将使用现有实例来处理请求，如果在预期时间范围内没有可用实例，则会超时。这可能会降低应用程序的服务质量，但至少不会破坏应用程序。服务器本身。这与 Web 服务器相同。关于线程安全的一些注意事项：
Sect. 4.3.13“序列化会话 Bean 方法”
根据 EJB 规范，对特定 Bean 实例的所有请求均由应用程序同步。服务器。例如，这允许无状态会话 Bean (SLSB) 在其字段之一中存储数据库连接。不过，SLSB 的字段应该是瞬态的。 （bean 实例可以随时销毁/重新创建。）通过同步，应用程序。服务器确保 SLSB 是线程安全的。无需应用程序同步。服务器端，开发者应该确保SLSB是线程安全的，即它不应该有任何字段。
注意：SLSB 中很少有字段。大多数 SLSB 本质上都是线程安全的。例如，我不建议将连接存储在字段中。最好在方法中获取一个，并尽快在方法中释放。
Instance pooling not only helps because you can re-use objects (and avoid costly object creation), but also allows the app. server to manage the load correctly. It's app. server specific, but you can normally specify
max-pool-size,min-pool-size,pool-resizeand thetimeout.When the pool has reached its
max-pool-sizecapacity, requests are served using the existing instances, and will time out if no instance is available within the expected time frame. That may degrade the quality of service of the application, but at least it doesn't blow the app. server itself. That's the same as with a web server.A few notes about thread-safety:
Sect. 4.3.13 "Serializing Session Bean Methods"
As per the EJB spec, all requests to a specific instance of a bean are synchronized by the app. server. This is, for instance, to allow a stateless session bean (SLSB) to store a database connection in one of its fields. The fields of an SLSB should be transient, though. (The bean instance can be destroyed/re-created any time.) With the synchronization, the app. server ensures the SLSB is thread-safe. Without the synchronization by the app. server, the developer should ensure that the SLSB is thread-safe, that is, it should have no fields.
Note: It's rare to have fields in an SLSB. Most SLSB are thread-safe by nature. I would not recommend storing the connection in field for instance. Better obtain one in the method, and release it in the method asap.
我认为当 bean 的构建成本很高时，可以使用实例池。通过让下一个请求重用同一个 bean，您不必构造另一个实例。
如果 bean 本身的构建成本很低，并且成本是在它正在执行的工作中，那么实例池就不值得这么麻烦。
I think instance pooling is used when the beans are expensive to construct. By letting the next request reuse the same bean you don't have to construct another instance.
If the bean itself is cheap to construct and the cost is in the work that it's doing, then instance pooling isn't worth the hassle.
我认为其优点与连接池的优点类似。在池中准备好实例可以避免每次请求 EJB 时创建新实例的开销。
另一个优点（取决于您如何看待它）是，通过使用最大池大小，您可以通过强制失控的应用程序等待实例变得可用来限制失控应用程序可能造成的损害。这可以帮助防止编写不当的应用程序独占服务器资源。
I think the advantages would be similar to those of connection pooling. Having instances ready in a pool avoids the overhead of creating a new instance every time the EJB is requested.
Another advantage, depending on how you look at it, is that by using a maximum pool size you can limit the damage a runaway application can do by forcing it to wait for an instance to become available. This can help prevent poorly written apps from monopolizing server resources.
AFAIK 的根本原因是与 servlet 相比不同的线程模型。对于servlet来说，只有一个实例，并且许多线程可以同时操作该实例。开发人员有责任确保正确的同步。
与此相反，ejb容器只允许一个线程同时对bean实例进行操作（包括必要的后台同步）。因此，开发人员不必关心同步，而且规范禁止在 bean 代码中使用同步（事实上你可以这样做，但你必须考虑性能后果）。
因此，要启用并发处理，您需要池化多个 bean 实例，以便多个线程可以同时访问它们。池的大小可以根据 bean 内部完成的工作类型进行调整。基本规则是：如果任务是 I/O 密集型，则需要大池，以便在等待 I/O 响应时不会浪费 cpu 时间。如果任务受 CPU 限制，则池的大小应与机器拥有的处理器/内核的数量一样大。但调整应该基于测量。
关于 servlet 的另一点注意事项：在使用 SingleThreadModel 接口时，您可以强制执行与 ejb 相同的行为。但实际上我猜这个用得不多。
AFAIK the fundamental reason is the different threading model compared to the servlet's one. In case of servlet, there is only one instance and many threads can operate on this intstance at the same time. It is the developers responsibility to ensure proper synchronisation.
In contrast to this, ejb container allows only one thread at the same time to operate on the bean instance (including necessary synchronisation at the background). Thanks to this, developer does not have to care about synchronisation, and what's more using synchronisation in the bean's code is forbidden by the spec (in fact you can do it, but you have to consider the performance consequences).
So to enable concurrent processing, you need to pool multiple bean instances so that multiple threads can access them simultaneously. The size of the pool can be tuned depending on what kind of work is done inside the bean. The basic rule is:if the task is I/O bound, you need big pool so that the cpu time is not wasted when waiting for i/o response. If the task is cpu bound, the pool should be as big as much processors/cores the machine does have. But the tuning should be based on measuring.
One more note on the servlets: you can enforce the same behaviour as ejb when using SingleThreadModel interface. But in fact this is not much used I guess.