我想知道现代JVM中反射的成本是否下降，除了代码中最关键的部分外，我们可以在任何地方自由使用它。
例如，如果我想基于用户给出的方法名称作为输入调用方法。现在有两种方法可以实现这个：
使用if / else /开关确定要调用的方法。如果存在大量案例，这显然会是很多代码。
使用反射来调用方法。这绝对不是代码。
澄清：上面只是一个使用反射可以缩短代码量的示例。我只是想知道用一些反射魔法替换大量静态代码是否是一种有效的策略。如果您在类似的路线上做过某些事情，也可以分享任何经验。
答案 0 :(得分：4)
不，在我看来还有另一种方法可以做得更好：使用命令模式和名称/命令实例对的映射。您可以在没有开关或反射的情况下缩放很长的路。它也是多态的 - 远远超过“面向对象”。
如果您不想使用自己的命令，请查看java.lang.Runnable或java.util.concurrent.Callable。如果您愿意，可以异步执行您的方法。
我不清楚用户将如何指定他们希望调用哪种方法。如果使用反射，他们必须拼出类的名称，方法，参数，并知道返回类型。你打算如何向他们展示可能的选择？应用程序中的每个类，每个方法？有什么公平的游戏吗？
我认为以一种易于指定和调用的方式提供一系列选择更为合理。我不相信任何基于反射的解决方案都符合这一标准。
您希望为用户提供一个选择，但“一切顺利”对我来说似乎并不实用。
至于下面提供的具体示例，其中包括Spring控制器和服务，我不会使用反射。如果您的用户通过传递HTTP查询参数指定启动或停止，则最好将各个Controller方法映射到您使用REST时考虑的特定URL。我的偏好是清晰度，即使它更加冗长。
答案 1 :(得分：0)
与直接方法调用/字段访问相比，即使它已经下降，它仍然会变慢。但在你的情况下，这真的应该没关系，因为JVM现在非常快。您是否看到可见性能影响以保证这样的问题？另外，要意识到这里的附带损害是你失去了所有静态类型检查的好处。
答案 2 :(得分：0)
您必须区分反射方法调用中的两个步骤：方法查找（慢）和方法调用（非常快）。因此，您真正需要做的就是缓存Method个实例并为它们提供快速查找解决方案。那么你将有一个双赢的解决方案。