После прочтения заголовка у кого-то наверняка возникнет весьма логичный вопрос: «Кто такая эта ваша рефлексия и зачем её ускорять?»
И если первая часть будет волновать только совсем уж откровенных неофитов (ответ тут), то вторая точно нуждается в пояснении.
К текущему моменту рефлексия (и особенно рефлективные вызовы методов) так или иначе используется в прорве самых разных фреймворков, библиотек и просто любых приложениях, по какой-либо причине требующих динамические возможности.
Однако в java рефлексия реализована не самым быстрым (зато надёжным) способом, а именно, через использование JNI-вызовов.
К сожалению, нельзя просто так взять и вызвать потенциально опасный бинарь, во-первых, потенциально несовместимый с внутренним миром машины, а во-вторых, способный без угрызений совести положить всё намертво лёгким взмахом segfault’а. Поэтому непосредственно моменту прямого вызова предшествует тонна инструкций, подготовляющих обе стороны к взаимодействию. Очевидно, не самый быстрый процесс.
Тем не менее, рефлексия работает именно так: машина «выходит наружу», копается в своих внутренностях и «возвращается обратно», доставляя пользователю полученную информацию или вызывая методы/конструкторы.
А теперь представьте примерное быстродействие какого-нибудь фреймворка, который в процессе работы постоянно осуществляет рефлективные вызовы…
Б-р-р! Ужасающая картина. Но, к счастью, есть способ всё исправить!
Постановка задачи
Задача такова – есть n методов с заранее неизвестной сигнатурой, необходимо найти их, получив рефлективное представление, и затем вызывать при наступлении определённого условия.
Очень просто, на первый взгляд, но на практике мы сталкиваемся с некоторыми трудностями, основная из которых – способ вызывать метод таким образом, чтобы расходы на вызов не обходились дороже, чем непосредственно исполнение тела метода.
Характеристики машины
Intel core i5-9400f, 16 GB ОЗУ, Windows 11
Проверяем рефлексию
Сейчас, к счастью, не 2005 год, и вызовы JNI больше не напоминают по скорости фазу stop-the-world GC. На том пути, что java прошла от появления JNI до настоящего времени, была проделана огромная работа по оптимизации и улучшению технологии (спасибо авторам project panama).
Так что, может, всё не так уж и плохо, и ускорять ничего не надо?
Проверим в первую очередь!
Java 17, простой класс A, содержащий в себе целочисленное поле value, которое можно сложить с другим числом с помощью вызова метода add.
Вызовем метод напрямую N раз, чтобы иметь данные, от которых будем отталкиваться в будущем. N для надёжности примем за 5 000 000.
public class Main {
public static void main(String[] args) {
final int N = 5000000;
final A a = new A();
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
a.add(i);
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}В результате получим примерно 5 000 000 ns (у меня получилось 4976700). Прекрасно! А что же там с рефлексией?
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws
NoSuchMethodException, InvocationTargetException, IllegalAccessException {
final int N = 5000000;
final A a = new A();
Method method = A.class.getDeclaredMethod("add", int.class);
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
method.invoke(a, i);
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}Запускаем, и… 71 085 900 ns! В 14 раз медленнее!
Кажется, ускорять всё-таки придётся…
Но откуда такое время? Во-первых, JNI. Во-вторых, проверки доступа. В-третьих, varargs, упаковывающиеся в массив и распаковывающиеся из него при вызове целевого метода.
Попробуем отключить проверки доступа:
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws
NoSuchMethodException, InvocationTargetException, IllegalAccessException {
final int N = 5000000;
final A a = new A();
Method method = A.class.getDeclaredMethod("add", int.class);
method.setAccessible(true);
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
method.invoke(a, i);
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}Уже 40 863 800 ns, примерно в 8 раз медленнее. Лучше, но всё равно не сахар.
Способ первый, мета-лямбды
В java 8 вместе с лямбдами была добавлена заодно интересная технология, позволяющая связывать любой метод с существующим лямбда-интерфейсом и получать на выходе прокси, работающее со скоростью прямого вызова. Это прекрасно, модно, молодёжно, но есть один существенный нюанс – сигнатура метода должна быть заранее известна.
То есть, такой способ потенциально не подходит для, например, веб-фреймворка: методы контроллера могут содержать неизвестное количество дополнительных параметров.
И хотя этот способ не совсем покрывает объявленную выше задачу, давайте измерим его скорость.
import java.lang.invoke.CallSite;
import java.lang.invoke.LambdaMetafactory;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Throwable {
final int N = 5000000;
final A a = new A();
Method method = A.class.getDeclaredMethod("add", int.class);
MethodHandles.Lookup lookup = MethodHandles.lookup();
CallSite callSite = LambdaMetafactory.metafactory(
lookup,
"add",
MethodType.methodType(Adder.class, A.class),
MethodType.methodType(void.class, int.class),
lookup.unreflect(method),
MethodType.methodType(void.class, int.class)
);
Adder adder = (Adder) callSite.getTarget().bindTo(a).invoke();
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
adder.add(i);
}
System.out.println(System.nanoTime() - start);
}
public interface Adder {
void add(int x);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}В результате 5776000 ns, всего в 1,15 раза хуже (примерно). Отличный результат!
И, к сожалению, быстрее уже не будет.
Собственно, на этом функционал встроенных решений исчерпан и дальше нам предстоит действовать самостоятельно.
Способ второй, динамическое проксирование
Если мы покопаемся в реализации мета-лямбд, мы увидим генерирование прокси-классов, имплементирующих конкретную лямбду. Тогда что мешает нам делать тоже самое, только для универсальной сигнатуры метода?
Правильно, нам мешает сложность генерирования байт-кода для jvm «на лету». Совсем немного поискав, утыкаемся в искомую утилиту – ASM. Также не помешает справочник по опкодам.
Напишем универсальный интерфейс, который будем имплементировать в дальнейшем:
public interface Lambda {
Object call(Object[] arguments) throws Throwable;
}Выглядит правдоподобно, я в это верю, как говорится.
А теперь самое интересное. Предлагаю не прыгать с места в байт-код, а написать собственную тестовую реализацию, от которой мы в будущем будем отталкиваться.
Примерно так:
public class Proxy implements Lambda {
private final Main.A body;
public Proxy(Main.A body) {
this.body = body;
}
@Override
public Object call(Object[] arguments) {
body.add((Integer) arguments[0]);
return null;
}
}Вроде всё хорошо, да? А вот и нет. С точки зрения java, код действительно отличный. А вот с точки зрения jvm – ни разу. Пока между этими двумя существует прослойка в виде компилятора, всё работает как надо. Но как только прослойка пропадает и за дело берёмся мы, нам необходимо помнить об одном очень существенном нюансе: боксинг примитивов. Поэтому доработаем наш код так, чтобы не забыть об этом:
public class Proxy implements Lambda {
private final Main.A body;
public Proxy(Main.A body) {
this.body = body;
}
@Override
public Object call(Object[] arguments) {
body.add(((Integer) arguments[0]).intValue());
return null;
}
}Чудесно. Можно приступать к реализации прокси.
Как же будет выглядеть метод call, записанный в jvm-ассемблере?
Краткая справка. JVM – стековая машина, и все операции выполняет исходя из данных, расположенных на операнд-стеке.
Таким образом, вызов метода можно разбить на 3 этапа:
-
Загрузка источника, содержащего вызываемый метод
-
Подготовка всех аргументов в последовательном порядке
-
Непосредственно вызов метода
В нашем случае, это будет происходить следующим образом:
-
Загрузка объекта проксируемого класса
-
Загрузка массива аргументов
-
Загрузка содержимого ячейки массива
-
Каст содержимого
-
Вызов метода
-
Возврат значения, которое он вернул (или null в нашем случае)
Примерный скетч:
aload_0 // Загружаем this, чтобы извлечь поле body
getfield // Загружаем body
aload_1 // Загружаем массив из первого параметра метода
iconst_0 // Пушим в стек int-константу 0 (индекс элемента)
aaload // Загружаем из массива элемент по индексу 0
checkcast // Кастим Object в Integer
invokevirtual // Вызываем Integer::intValue(), распаковывая примитив
invokevirtual // Вызываем целевой метод из body
aconst_null // Помещаем в стек null
areturn // Возвращаем результатВроде ничего не забыли… Раз так, вооружаемся user’s guide’ом ASM и идём реализовывать прокси.
Получаем вот такой результат:
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;
public class Main {
public static void main(String[] args) throws Throwable {
final String OBJECT = "java/lang/Object";
// Создаём генератор нашего прокси-класса,
// указывая ему самому считать за нас максы
ClassWriter writer = new ClassWriter(ClassWriter.COMPUTE_MAXS);
// Объявляем собственно сам заголовок класса
writer.visit(
Opcodes.V1_8,
Opcodes.ACC_PUBLIC,
"Proxy",
null,
OBJECT,
new String[]{"Lambda"}
);
// Объявляем поле для хранения инстанса A
writer.visitField(Opcodes.ACC_PRIVATE, "body", "LMain$A;", null, null)
.visitEnd();
// Объявляем конструктор
MethodVisitor c = writer.visitMethod(Opcodes.ACC_PUBLIC, "<init>",
"(LMain$A;)V", null, null);
// Загружаем и вызываем super();
c.visitVarInsn(Opcodes.ALOAD, 0);
c.visitMethodInsn(Opcodes.INVOKESPECIAL, OBJECT, "<init>", "()V", false);
// Получаем this и загружаем переданный аргумент
c.visitVarInsn(Opcodes.ALOAD, 0);
c.visitVarInsn(Opcodes.ALOAD, 1);
// Присваиваем его в поле body
c.visitFieldInsn(Opcodes.PUTFIELD, "Proxy", "body", "LMain$A;");
c.visitInsn(Opcodes.RETURN);
c.visitMaxs(0, 0);
c.visitEnd();
// Реализуем метод
MethodVisitor m = writer.visitMethod(Opcodes.ACC_PUBLIC,
"call",
"([Ljava/lang/Object;)Ljava/lang/Object;",
null,
new String[]{"java/lang/Throwable"});
// Загружаем this, чтобы извлечь поле body
m.visitVarInsn(Opcodes.ALOAD, 0);
// Загружаем body
m.visitFieldInsn(Opcodes.GETFIELD, "Proxy", "body", "LMain$A;");
// Загружаем массив из первого параметра метода
m.visitVarInsn(Opcodes.ALOAD, 1);
// Пушим в стек int-константу 0 (индекс элемента)
m.visitInsn(Opcodes.ICONST_0);
// Загружаем из массива элемент по индексу 0
m.visitInsn(Opcodes.AALOAD);
// Кастим Object в Integer
m.visitTypeInsn(Opcodes.CHECKCAST, "java/lang/Integer");
// Вызываем Integer::intValue(), распаковывая примитив
m.visitMethodInsn(Opcodes.INVOKEVIRTUAL, "java/lang/Integer", "intValue", "()I",
false);
// Вызываем целевой метод из body
m.visitMethodInsn(Opcodes.INVOKEVIRTUAL, "Main$A", "add", "(I)V", false);
// Помещаем в стек null
m.visitInsn(Opcodes.ACONST_NULL);
// Возвращаем результат
m.visitInsn(Opcodes.ARETURN);
m.visitMaxs(0, 0);
m.visitEnd();
writer.visitEnd();
byte[] bytes = writer.toByteArray();
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}Осталось загрузить класс-лоадером получившееся прокси и можно идти тестировать!
Загрузить стандартными средствами класс не выйдет (метод defineClass protected), и нам придётся создать свой класс-лоадер. Впрочем, ничего сложного:
class Loader extends ClassLoader {
public Class<?> define(String name, byte[] buffer) {
return defineClass(name, buffer, 0, buffer.length);
}
}Загружаем изделие, инстанцируем и проверяем скорость.
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;
public class Main {
public static void main(String[] args) throws Throwable {
...
Loader loader = new Loader();
Class<?> clazz = loader.define("Proxy", bytes);
final A a = new A();
Lambda lambda = (Lambda) clazz.getDeclaredConstructor(A.class).newInstance(a);
final int N = 5000000;
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
lambda.call(new Object[]{i});
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}
class Loader extends ClassLoader {
public Class<?> define(String name, byte[] buffer) {
return defineClass(name, buffer, 0, buffer.length);
}
}И… *барабанная дробь* 16806000 ns. Всего в 3 раза медленнее, чем прямые вызовы. Но откуда взялись эти 3 раза? Неужели прокси так замедляет?
Ответ кроется в конструкции new Object[]{i}. Попробуем вынести создание массива во вне:
import org.objectweb.asm.ClassWriter;
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;
public class Main {
public static void main(String[] args) throws Throwable {
...
Loader loader = new Loader();
Class<?> clazz = loader.define("Proxy", bytes);
final A a = new A();
Lambda lambda = (Lambda) clazz.getDeclaredConstructor(A.class)
.newInstance(a);
final int N = 5000000;
long start = System.nanoTime();
Object[] arguments = new Object[]{5};
for (int i = 0; i < N; ++i) {
lambda.call(arguments);
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}
class Loader extends ClassLoader {
public Class<?> define(String name, byte[] buffer) {
return defineClass(name, buffer, 0, buffer.length);
}
}И получим 5736500 ns. Те же самые мета-лямбды, по факту.
Есть ли способ избежать расходов на инстанцирование массива? Не думаю, телепортировать аргументы машина, к сожалению, не умеет. Критично ли это? Тоже не особо, так как там, где это действительно неизбежно, расходы на подготовку аргументов скорее всего с лихвой перебьют расходы на new.
А можно проще?
Да, разумеется, вам не нужно каждый раз самостоятельно реализовывать генерацию прокси вручную, существуют утилиты, удобно инкапсулирующие этот процесс.
Рассмотрим всё то же самое на примере jeflect (тык)
Мета-лямбды
import com.github.romanqed.jeflect.ReflectUtil;
import com.github.romanqed.jeflect.meta.LambdaClass;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Throwable {
A a = new A();
Method method = A.class.getDeclaredMethod("add", int.class);
LambdaClass<Adder> clazz = LambdaClass.fromClass(Adder.class);
Adder adder = ReflectUtil.packLambdaMethod(clazz, method, a);
final int N = 5000000;
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
adder.add(i);
}
System.out.println(System.nanoTime() - start);
}
public interface Adder {
void add(int x);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}Прокси
import com.github.romanqed.jeflect.Lambda;
import com.github.romanqed.jeflect.ReflectUtil;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Throwable {
A a = new A();
Method method = A.class.getDeclaredMethod("add", int.class);
Lambda lambda = ReflectUtil.packMethod(method, a);
final int N = 5000000;
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
lambda.call(new Object[]{i});
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}Нерассмотренное в статье прокси без привязки к конкретному объекту
import com.github.romanqed.jeflect.LambdaMethod;
import com.github.romanqed.jeflect.ReflectUtil;
import java.lang.reflect.Method;
public class Main {
public static void main(String[] args) throws Throwable {
A a = new A();
Method method = A.class.getDeclaredMethod("add", int.class);
LambdaMethod lambda = ReflectUtil.packLambdaMethod(method);
final int N = 5000000;
long start = System.nanoTime();
for (int i = 0; i < N; ++i) {
lambda.call(a, new Object[]{i});
}
System.out.println(System.nanoTime() - start);
}
public static class A {
public int value = 0;
public void add(int x) {
value += x;
}
}
}Где подвох?
Чудес не бывает, и получая в чём-то преимущество, мы вынуждены платить чем-то другим.
Невозможность обойти проверки доступа
Так как вызовы происходят внутри машины, все упаковываемые сущности обязаны быть видны для упаковщика. Это автоматически отсекает возможность использования обоих подходов для различных хаков, возможных ранее с рефлексией (например, вызов приватных методов класса).
Ресурсоёмкий процесс подготовки
Генерация прокси-классов - дело не быстрое, и занимает достаточно существенное время. В целом, этот подход не подразумевает постоянную переупаковку метода: один раз подготовил, всё время вызываешь.
Выводы
Рефлексия – незаменимый инструмент, но слишком тяжёлый, чтобы быть вызванным в рантайме.
Мета-лямбды – не слишком универсально, но максимально быстро.
Динамические прокси – абсолютно универсально, но медленнее, чем мета-лямбды.
Также стоит помнить о том, что многие вещи могут быть реализованы без рефлексии, и это будет намного лучше, чем любые её оптимизации.
Спасибо за внимание!
Автор: Роман Бакалдин
