Sun JVM在运行时如何创建sun.reflect.DelegatingClassLoader实例? [英] What for Sun JVM creates instances of sun.reflect.DelegatingClassLoader at runtime?

问题描述

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

While analyzing a heap dump using jhat I have observed many instances of DelegatingClassLoader created although they were not called explicitly in code. I expect this to be some sort of reflection optimization mechanism. Does anybody know the details?

推荐答案

是的，这可能是反射优化.

Yes, it is probably a reflection optimisation.

在Sun JVM上，最初是通过JNI调用JVM实现来执行对属性和方法的反射访问.如果JVM注意到通过反射经常访问某个方法或字段，它将生成字节码来执行相同的操作-一种称为通货膨胀"的机制.这具有最初的速度打击，但此后速度提高了约20倍.如果您进行很多思考，那就是一个大胜利.

On the Sun JVM, reflective access to properties and methods is initially performed by calling through JNI into the JVM implementation. If the JVM notices that a method or field is being accessed by reflection a lot, it will generate bytecode to do the same thing -- a mechanism that it calls "inflation". This has an initial speed hit, but after that runs about 20 times faster. A big win if you do a lot of reflection.

该字节码存在于DelegatingClassLoader实例创建的类中.请注意:这些类可能会对permgen空间造成压力，并导致可怕的"java.lang.OutOfMemoryError:PermGen空间"失败.如果有问题，可以通过将系统属性sun.reflect.inflationThreshold设置为0(零)来关闭通货膨胀.

That bytecode lives in classes created by DelegatingClassLoader instances. Keep an eye on it: those classes can put pressure on the permgen space and cause the dreaded "java.lang.OutOfMemoryError: PermGen space" failures. If it is a problem, you can turn inflation off by setting the system property sun.reflect.inflationThreshold to 0 (zero).

这篇关于Sun JVM在运行时如何创建sun.reflect.DelegatingClassLoader实例?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！