使用接口和反射 API 在运行时创建实例是昂贵的选择答案

【问题标题】：Is using interface and reflection APIs to create instances at runtime is costly option使用接口和反射 API 在运行时创建实例是昂贵的选择
【发布时间】：2026-02-07 01:00:02
【问题描述】：

我遇到过需要从表中动态选择实现接口的类的情况。该类的绝对路径将在表中配置。将从表中选择类名，然后使用反射 API 创建和执行该类的实例。

我假设当多个线程访问该程序时会创建许多实例，这可能会占用大量内存并且可能会对性能产生影响。我的这个假设是对的吗？有什么办法可以处理我这里的情况吗？

下面是sn-p的代码：

Class<?> c = Class.forName(dynamicClass);            
ServiceValidatorInterface inst = (ServiceValidatorInterface) c.newInstance();
inst.validateService(serviceDetails);

【问题讨论】：

如果您基于某些输入和类输出进行一对一映射，则不一定需要在请求时创建该表。就内存而言，一旦离开方法，实例就会超出范围，不是吗？
嗨戴夫，感谢您的评论。 1. 还有一个程序根据某些条件从表中提供类名。该表将配置许多用于不同目的的类，但它们都实现相同的接口。 2. 我创建的实例会一直存在，直到它被垃圾回收，对吧？不过我不确定:)
是的，它会一直存在，直到它被 GCed。任何 JVM 对象都是如此，无论它是如何实例化的。
有更好的方法可以做到这一点，根本不会使用反射。我假设您实现 ServiceValidatorInterface 的类数量有限。因此，创建一个枚举（可能称为 ValidatorType），将枚举值存储在您的数据库中（在一个字符字段中），并在您的应用程序中，保持一个静态的Map<ValidatorType, Supplier<ValidatorType>>。每个供应商值都是一个构造函数引用，例如AlbatrossServiceValidator::new。

标签： java performance reflection interface

【解决方案1】：

无论您如何创建实例，创建实例都会占用内存，因此这与问题无关。

至于性能影响，通过newInstance()创建实例当然和直接调用构造函数不一样，但是真的对你有影响吗？此外，如果您要一遍又一遍地创建同一个类的实例，您可以将它们汇集起来，以便它们只创建一次。您只需确保类是无状态的并且可以共享。

不要急于担心性能影响。现在是 2018 年，我们拥有有史以来最强大的计算机，但人们会提前（通常没有理由）担心无关紧要的事情。了解某事物是否具有可接受的性能的唯一方法是对其进行测量，除非你先编写代码，否则你无法做到这一点。

【讨论】：