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