问题
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?
回答1:
Yes, it is probably a reflection optimisation.
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.
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).
回答2:
I don't see (at least for Hotspot), when looking at code
http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/reflect/ReflectionFactory.java.html
and
http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/reflect/NativeMethodAccessorImpl.java.html
that a setting of zero will turn off the feature. Seems to me only a large value for sun.reflect.inflationThreshold will do the job.
来源：https://stackoverflow.com/questions/6505274/what-for-sun-jvm-creates-instances-of-sun-reflect-delegatingclassloader-at-runti