我想知道现代 JVM 中反射的成本是否已经下降，除了代码中最关键的部分之外，我们可以在任何地方自由使用它。
例如，如果我想根据用户提供的方法名称作为输入来调用方法。现在有两种实现方式：
使用 if/else/switch 来确定调用哪个方法。如果有大量案例，这显然会是很多代码。
使用反射来调用方法。这绝对是更少的代码。
澄清：上面只是一个使用反射可以减少代码量的例子。我只是想知道用一些反射魔法替换大量静态代码是否是一种有效的策略。如果您在类似的线路上做过一些事情，也请分享任何经验。
问问题
937 次
3 回答
4
不，在我看来，还有另一种更好的方法：使用命令模式和名称/命令实例对的映射。您可以在没有开关或反射的情况下扩展很长的距离。它也是多态的——更“面向对象”。
看看java.lang.Runnable或者java.util.concurrent.Callable如果你不想使用你自己的命令。如果您愿意，您的方法可以异步执行。
我不清楚用户将如何指定他们希望调用的方法。如果你使用反射，他们必须拼出类的名称、方法、参数，并知道返回类型。你打算如何向他们展示可能的选择？应用程序中的每个类、每个方法？有什么公平的游戏吗？
我认为以易于指定和调用的方式呈现一个选项列表更为合理。我不相信任何基于反射的解决方案都符合该标准。
您想为用户提供一个选择，但“一切顺利”对我来说似乎并不实际。
至于下面提供的具体示例，包括 Spring 控制器和服务，我不会使用反射。如果您的用户通过传递 HTTP 查询参数来指定开始或停止，最好使用 REST 将各个控制器方法映射到您想到的特定 URL。我的偏好是清晰，即使它更冗长。
于 2012-05-30T09:24:21.547 回答
0
即使它下降了，与直接方法调用/字段访问相比，它仍然慢很多。但是在您的情况下，这真的不重要，因为这些天 JVM 飞速发展。您是否看到明显的性能影响来证明这样的问题？另外，请意识到这里的附带损害是您失去了所有静态类型检查的优点。
于 2012-05-30T09:25:51.133 回答
0
You must differentiate between two steps in a reflective method call: method lookup (slow) and method invocation (very fast). So all you really need to do is cache the Method instances and have a fast lookup solution for them. Then you'll have a win-win solution.
于 2012-05-30T09:33:00.417 回答