是因为我们应该加载类（例如string），创建实例，然后搜索适当的方法，打包参数，然后只调用方法？所以大部分时间花在这些操作上而不是对象上的显式方法调用，对吗？
答案 0 :(得分：29)
每次使用反射时，每次采取步骤都需要进行验证。例如，当你调用一个方法时，它需要检查目标是否实际上是方法的声明者的一个实例，你是否有正确数量的参数，每个参数是否是正确的类型，等等。 / p>
绝对没有内联或其他表演技巧的可能性。
如果您按名称查找类型或方法，那么最多只需要进行简单的地图查找 - 每次执行时都会执行，而不是在JIT时执行一次。
基本上还有很多事要做。然而，反射变得比以前快得多......如果你觉得它太慢了，你可能会过度使用它。
答案 1 :(得分：6)
作为Jon Skeet上述答案的附录（为了能够发表评论，我需要更多声誉。）：
反射取决于可用的CPU资源;如果你的应用程序问题很慢，那么反射就不会解决任何问题，只是让它变慢。
与Java本身一样，反思也不再缓慢 - 它更像是一个古老的谣言;）
答案 2 :(得分：2)
调用方法时，您需要知道是否使用有效参数，有效对象，返回类型以及要执行的字节码。当在代码中指定了确切的方法时，java可以快速计算出这些东西并继续实际执行该方法。
当你用反射做这件事时，你知道的要少得多。由于未在代码中指定要调用的方法，因此无法事先完成此操作，并且VM必须在运行时执行更复杂且处理器密集的操作。
多态方法调用可以介于这两个极端之间。您不知道在运行时调用什么方法，但至少可以确定方法的名称，参数和返回类型。您对执行什么方法的了解越多，Java就越可以避免在运行时执行。
这证明反射较慢，但并不是说它实际上是“慢”。如果您需要反射或多态方法，请使用它们，并保存对以后“慢”的判断。
答案 3 :(得分：0)
如果以适当的方式使用它，它就不那么慢了。 例如，我用它来扫描模型类中的所有属性，它工作得很好。
在其他情况下，例如检查目标是否具有相同的类型或签名，它绝对是慢的。
事件有时很慢，但对开箱即用的实施很重要......：D。
答案 4 :(得分：0)
反射速度较慢，因为它涉及动态解析的类型， 某些Java虚拟机优化无法执行。 因此，反射操作的性能要比其反射操作慢 非反射性对应物，应在代码部分中避免使用 在对性能敏感的应用程序中经常被调用。