При анализе дампа кучи с использованием jhat я наблюдал множество экземпляров DelegatingClassLoader, хотя они явно не вызывались в коде. Я ожидаю, что это будет своего рода механизм оптимизации отражения. Кто-нибудь знает подробности?
Что для Sun JVM создает экземпляры sun.reflect.DelegatingClassLoader во время выполнения?
Ответ 1
Да, это, вероятно, оптимизация отражения.
В Sun JVM рефлексивный доступ к свойствам и методам изначально выполняется путем вызова JNI в реализацию JVM. Если JVM замечает, что метод или поле часто обращается путем отражения, он генерирует байт-код для выполнения того же самого действия - механизма, который он называет "инфляцией". Это имеет начальную скорость, но после этого работает примерно в 20 раз быстрее. Большая победа, если вы много размышляете.
Этот байт-код живет в классах, созданных экземплярами DelegatingClassLoader. Следите за этим: эти классы могут оказывать давление на пространство пермгенов и вызывать ужасные провалы "java.lang.OutOfMemoryError: PermGen space". Если это проблема, вы можете отключить инфляцию, установив свойство системы sun.reflect.inflationThreshold на 0 (ноль).
Ответ 2
Я не вижу (по крайней мере для Hotspot), глядя на код
http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/reflect/ReflectionFactory.java.html
и
что установка нуля отключит функцию. Мне кажется, что только большое значение для sun.reflect.inflationThreshold выполнит эту работу.