Reflection Sun JVM在运行时创建Sun.reflect.DelegatingClassLoader实例的原因是什么？

在使用jhat分析堆转储时，我观察到创建了许多DelegatingClassLoader实例，尽管它们没有在代码中显式调用。我希望这是某种反射优化机制。有人知道细节吗？

是的，这可能是反射优化

在Sun JVM上，对属性和方法的反射访问最初是通过JNI调用JVM实现来执行的。如果JVM注意到一个方法或字段经常被反射访问，它将生成字节码来做同样的事情——一种称为“膨胀”的机制。这有一个初始速度命中，但之后运行速度大约快20倍。如果你做了很多反思，这将是一个巨大的胜利

该字节码存在于DelegatingClassLoader实例创建的类中。请注意：这些类可能会对permgen空间施加压力，并导致可怕的“java.lang.OutOfMemoryError:permgen空间”失败。如果出现问题，可以通过将系统属性sun.reflect.inflationThreshold设置为0（零）来关闭充气功能。

查看代码时，我看不到（至少对于热点）

及

---

设置为零将关闭该功能。在我看来，sun.reflect.inflationThreshold只有一个较大的值才能完成这项工作。

警告，该属性在Oracle/OpenJDK和IBM JDK上工作，但是在IBM上它打开了膨胀，在sun上它会立即膨胀（尝试使用-verbose:类，该类返回的delegatedClassLoader正在实例化，因为IBM的代码不可用）. 在这两种情况下，默认值都是15，我会考虑将其设置为1000或其他值，以减少通货膨胀，但仍然可以从加速中获益。IBM的行为不同，它将使用0或1将其关闭。（不确定它对0或1是否有任何不同，但对于这两者，我看不到会加载DelegatingClassLoader）。