Вызов методов через reflection26.12.2016 14:48

Все программисты на Java явно или неявно пользуются reflection для вызова методов. Даже если вы не делали этого сами, это за вас наверняка делают библиотеки или фреймворки, которые вы используете. Давайте посмотрим, как этот вызов устроен внутри и насколько это быстро. Будем глядеть в OpenJDK 8 с последними обновлениями.

Начать изучение стоит собственно с метода Method.invoke. Там делается три вещи:

• Проверяются права доступа на метод.
• Создаётся и запоминается MethodAccessor, если его ещё нет (если данный метод ещё не вызывали через reflection).
• Вызывается MethodAccessor.invoke.

Проверка прав доступа состоит из двух частей. Быстрая проверка устанавливает, что и метод, и содержащий его класс имеют модификаторы public. Если это не так, то проверяется, что у вызывающего класса есть доступ к данному методу. Чтобы узнать вызывающий класс, используется приватный метод Reflection.getCallerClass(). Некоторые люди, кстати, любят им пользоваться в своём коде. В Java 9 появится публичный Stack-Walking API и в высшей степени разумно будет перейти на него.

Известно, что проверки доступа можно отменить, вызвав заранее method.setAccessible(true). Этот сеттер устанавливает флаг override, позволяющий игнорировать проверки. Даже если вы знаете, что ваш метод публичный, установка setAccessible(true) позволит сэкономить немного времени на проверках.

Давайте посмотрим, сколько разные сценарии съедают времени. Напишем простой класс с публичным и непубличным методами:

public static class Person {
    private String name;

    Person(String name) { this.name = name; }

    public String getName1() { return name; }

    protected String getName2() { return name; }
}

Напишем JMH-тест, параметризованный двумя флагами: accessible и nonpublic. Такой у нас будет подготовка:

Method method;
Person p;

@Setup
public void setup() throws Exception {
    method = Person.class.getDeclaredMethod(nonpublic ? "getName2" : "getName1");
    method.setAccessible(accessible);
    p = new Person(String.valueOf(Math.random()));
}

И сам бенчмарк:

@Benchmark
public String reflect() throws Exception {
    return (String) method.invoke(p);
}

Я вижу вот такие результаты (3 форка, 5×500ms прогрев, 10×500ms измерение):

Действительно если выполнен setAccessible(true), то получается быстрее всего. При этом без разницы, публичный метод или нет. Если же setAccessible(false), то оба теста медленнее и непубличный метод чуть медленнее публичного. Впрочем я ожидал, что различие будет сильнее. Главным образом тут помогает, что Reflection.getCallerClass() — это интринсик JIT-компилятора, который в большинстве случаев подменяется просто константой во время компиляции: если JIT-компилятор инлайнит вызов Method.invoke, он знает, в какой метод он его инлайнит, а значит и знает, что должен вернуть getCallerClass(). Дальше проверка по сути сводится к сравнению пакета вызываемого и вызывающего класса. Если бы пакет был разный, проверялась бы ещё иерархия классов.

Что же происходит дальше? Дальше нужно создать объект MethodAccessor. Кстати, несмотря на то что Person.class.getMethod("getName") всегда вернёт новый экземпляр объекта Method, используемый внутри MethodAccessor будет переиспользован через поле root, что, конечно, приятно. Тем не менее сам getMethod существенно медленнее вызова, поэтому если вы планируете вызывать метод несколько раз, разумно хранить объект Method.

Созданием MethodAccessor'а занимается ReflectionFactory. Здесь мы видим два сценария, которые контролируются глобальными настройками JVM:

• Если установлена опция -Dsun.reflect.noInflation=true (по умолчанию выключена), то сразу генерируется вспомогательный класс, который и будет запускать целевой метод.
• Иначе создаётся обёртка DelegatingMethodAccessorImpl, внутрь которой помещается NativeMethodAccessorImpl. В свою очередь он считает, сколько раз данный метод вызывали. Если количество вызовов превысило порог, заданный через -Dsun.reflect.inflationThreshold (по умолчанию 15), то происходит «раздувание» аксессора: генерируется вспомогательный класс, как и в первом сценарии. Если же порог не достигнут, вызов идёт честно через JNI. Хотя реализация на стороне C++ тривиальна, накладные расходы на JNI весьма высоки.

Давайте посмотрим, что будет с нашим тестом, если включить -Dsun.reflect.noInflation=true и если использовать только JNI (для этого зададим большой порог -Dsun.reflect.inflationThreshold=100000000):

Здесь и далее все результаты в наносекундах на операцию. Как и ожидалось, JNI существенно медленнее, поэтому включать такой режим неоправданно. Любопытно, что режим noInflation оказался чуть быстрее. Это происходит из-за того, что отсутствует DelegatingMethodAccessorImpl, который убирает необходимость в одной косвенной адресации. По умолчанию вызов проходит через Method → DelegatingMethodAccessorImpl → GeneratedMethodAccessorXYZ, а с этой опцией цепочка сокращается до Method → GeneratedMethodAccessorXYZ. Вызов Method → DelegatingMethodAccessorImpl мономорфный и легко девиртуализируется, но косвенная адресация всё равно остаётся.

Кстати, о девиртуализации. Стоит заметить, что бенчмарк у нас плохой, потому что он не отображает ситуацию в реальной программе. В бенчмарке мы вызываем через reflection только один метод, а значит, у нас всего один сгенерированный аксессор, который тоже легко девиртуализуется и даже инлайнится. В реальном приложении так не бывает: аксессоров много. Чтобы сэмулировать эту ситуацию, давайте опционально отравим профиль типов в методе setup:

if(polymorph) {
    Method method2 = Person.class.getMethod("toString");
    Method method3 = Person.class.getMethod("hashCode");
    for(int i=0; i<3000; i++) {
        method2.invoke(p);
        method3.invoke(p);
    }
}

Обратите внимание, что мы никак не меняли код, производительность которого мы измеряем. Мы просто сделали несколько тысяч с виду бесполезных вызовов перед этим. Однако эти бесполезные вызовы немного подпортят картинку: JIT видит, что вариантов много, и не может подставить единственный возможный, делая теперь честный виртуальный вызов. Результаты будут такие (poly — вариант с превращением вызова метода в полиморфный, на JNI не влияет):

Как видно, виртуальный вызов добавляет около 1,5–1,8 нс на моём железе — даже больше, чем проверки доступа. Важно помнить, что поведение виртуальной машины в микробенчмарке может существенно отличаться от поведения в реальном приложении, и по возможности воссоздавать условия, близкие к реальности. Здесь, конечно, от реальности всё ещё далеко: как минимум, все нужные объекты в L1-кэше процессора и сборка мусора не происходит, потому что мусора нет.

Некоторые могут подумать, круто, мол, что с -Dsun.reflect.noInflation=true всё становится быстрее. Пусть всего на 0,3 нс, но всё же. Да плюс первые 15 вызовов ускорятся. Да и рабочий набор чуть уменьшился, кэш процессора экономим — сплошные плюсы! Добавим опцию в продакшн и заживём! Так делать не надо. В бенчмарке мы протестировали один сценарий, а в природе бывают и другие. Например, какой-нибудь код может по одному разу вызывать множество разных методов. С этой опцией аксессор будет генерироваться сразу на первом вызове. А сколько это стоит? Сколько времени генерируется аксессор?

Чтобы это оценить, можно через reflection очищать приватное поле Method.methodAccessor (очистив предварительно Method.root), принудив инициализировать аксессор заново. Запись поля через reflection хорошо оптимизирована, поэтому от этого тест сильно не замедлится. Получаем такие результаты. Верхняя строка — ранее полученные результаты (polymorph, accessible), для сравнения:

Как видим, если аксессор сбрасывать, то по дефолту производительность становится немного хуже, чем в варианте с JNI. А вот если мы от JNI полностью отказываемся, то получаем 100 микросекунд на запуск метода. Генерация и загрузка класса в рантайме по сравнению с однократным вызовом метода (даже через JNI), конечно, чудовищно медленна. Поэтому дефолтное поведение «пробовать 15 раз через JNI и только потом генерировать класс» кажется в высшей степени разумным.

Вообще помните, что нет волшебной опции, которая ускорит любое приложение. Если бы она была, она бы была включена по умолчанию. Какой смысл её прятать от людей? Возможно, есть опция, которая ускорит конкретно ваше приложение, но не принимайте на веру любые советы типа «врубите -XX:+MakeJavaFaster, и всё будет летать».

Как же выглядят эти сгенерированные аксессоры? Байткод генерируется в классе MethodAccessorGenerator с использованием довольно тривиального низкоуровневого API ClassFileAssembler, которое чем-то похоже на урезанную библиотеку ASM. Классам даются имена вида sun.reflect.GeneratedMethodAccessorXYZ, где XYZ — глобальный синхронизированный счётчик, вы их можете увидеть в стектрейсах и отладчике.

Сгенерированный класс существует только в памяти, но мы легко можем сдампить его на диск, добавив в метод ClassDefiner.defineClass строчку вида

try { Files.write(Paths.get(name+".class"), bytes); } catch(Exception ex) {}

После этого можно смотреть на класс в декомпиляторе. Для нашего метода getName1() сгенерировался такой код (декомпилятор FernFlower и ручное переименование переменных):

public class GeneratedMethodAccessor1 extends MethodAccessorImpl {
    public GeneratedMethodAccessor1() {}

    public Object invoke(Object target, Object[] args) throws InvocationTargetException {
        if(target == null) {
            throw new NullPointerException();
        } else {
            Person person;
            try {
                person = (Person)target;
                if(args != null && args.length != 0) {
                    throw new IllegalArgumentException();
                }
            } catch (NullPointerException | ClassCastException ex) {
                throw new IllegalArgumentException(ex.toString());
            }

            try {
                return person.getName1();
            } catch (Throwable ex) {
                throw new InvocationTargetException(ex);
            }
        }
    }
}

Заметьте, сколько приходится делать дополнительных вещей. Надо проверить, что нам передали непустой объект нужного типа и передали пустой список аргументов или null вместо списка аргументов (не все знают, но при вызове через reflection метода без аргументов мы можем передать null вместо пустого массива). При этом надо аккуратно соблюдать контракт: если вместо объекта передали null, то выкинуть NullPointerException. Если передали объект другого класса, то IllegalArgumentException. Если произошло исключение при выполнении person.getName1(), то тогда InvocationTargetException. И это ещё у метода нет аргументов. А если они есть? Вызовем, например, такой метод (для разнообразия теперь статический и возвращающий void):

class Test {
    public static void test(String s, int x) {}
}

Теперь кода существенно больше:

public class GeneratedMethodAccessor1 extends MethodAccessorImpl {
    public GeneratedMethodAccessor1() {}

    public Object invoke(Object target, Object[] args) throws InvocationTargetException {
        String s;
        int x;
        try {
            if(args.length != 2) {
                throw new IllegalArgumentException();
            }

            s = (String)args[0];
            Object arg = args[1];
            if(arg instanceof Byte) {
                x = ((Byte)arg).byteValue();
            } else if(arg instanceof Character) {
                x = ((Character)arg).charValue();
            } else if(arg instanceof Short) {
                x = ((Short)arg).shortValue();
            } else {
                if(!(arg instanceof Integer)) {
                    throw new IllegalArgumentException();
                }

                x = ((Integer)arg).intValue();
            }
        } catch (NullPointerException | ClassCastException ex) {
            throw new IllegalArgumentException(ex.toString());
        }

        try {
            Test.test(s, x);
            return null;
        } catch (Throwable ex) {
            throw new InvocationTargetException(ex);
        }
    }
}

Заметьте, что вместо int мы имеем право передать Byte, Short, Character или Integer, и всё это обязано преобразоваться. Именно здесь преобразование и идёт. Такой блок будет добавляться для каждого примитивного аргумента, где возможно расширяющее преобразование. Теперь также понятно, зачем в catch ловится NullPointerException: он может возникнуть при анбоксинге и тогда мы обязаны также выдать IllegalArgumentException. Зато благодаря тому, что метод статический, нас совершенно не волнует, что в параметре target. Ну и появилась строчка return null, потому что наш метод возвращает void. Вся эта магия аккуратно расписана в MethodAccessorGenerator.emitInvoke.

Вот так примерно и работает вызов методов. Похожим образом устроен вызов конструкторов. Также этот код частично переиспользован для десериализации объектов. Когда аксессор уже существует, с точки зрения JVM он не особо отличается от кода, который вы бы написали сами вручную, поэтому рефлекшн начинает работать весьма быстро.

В заключение отмечу, что начиная с Java 7 появилось API java.lang.invoke которое тоже позволяет вызывать методы динамически, но работает оно совсем по-другому.

Комментарии (0)