【quarkus系列】解决native包反射问题之RegisterForReflection 注解

背景

在使用 Quarkus 等框架时，反射机制可能是我们剥离spring框架之后做native包需要的解决问题。
首先先了解讨论为什么原生包（native image）不支持传统的反射机制呢？扩展一下知识点，两者之间的区别。

反射机制：反射允许 Java 程序在运行时动态地发现和使用类、方法和字段。这种动态性带来了极大的灵活性，但也有一些缺点，如性能开销和安全问题。

原生包（native image）：GraalVM 提供了一种将 Java 应用程序编译为原生可执行文件的能力，这种方式能够显著提高启动速度和减少内存占用。这是因为原生包在编译时进行了大量的优化和提前计算，而不是依赖运行时的动态特性。

综上，我们在编译期，即使使用了反射机制，也不会影响我们代码正常运行，换言之，只要我们不制作native镜像包，都不会影响我们的使用。

那我们解释一下为什么会不支持呢。

原生包的构建依赖静态分析，分析应用程序的全部代码路径。这种方法需要知道所有可能的类、方法和字段引用。
编译时，所有可能被使用的代码都必须是已知的。反射机制的动态性使得在编译时无法确定哪些类和成员会在运行时被访问。
生成原生包时，GraalVM 会去除所有未使用的类和方法以减少包的大小。反射需要运行时的类型信息和元数据，而这些信息在编译期间可能被删除，导致运行时无法通过反射机制访问。
反射机制需要大量的元数据来支持运行时动态查找，这会增加内存占用。而原生包的一个主要优势就是减少内存占用，因此这两者是矛盾的。

针对上面的扩展，相信大家应该会进一步了解了原生包的机制了吧！下面开启今天的主题RegisterForReflection

RegisterForReflection

为了在原生包中使用反射，GraalVM 提供了一些解决方案，主要是通过显式注册反射信息。
@RegisterForReflection注解用于显式声明哪些类需要在运行时使用反射。这些信息在编译时被收集并保存在配置文件中，以便在生成原生包时包含必要的元数据，确保在原生镜像中能够正确处理反射操作。

实践

语法示例

方式一：使用 @RegisterForReflection 注解

import io.quarkus.runtime.annotations.RegisterForReflection;@RegisterForReflection
public class MyClass {private String name;private int age;// Constructors, Getters, and Setters
}

方式二：配置文件注册反射信息
除了使用注解，还可以通过配置文件注册反射信息。这在处理第三方库或无法修改源代码的情况下非常有用。

在META-INF/native-image/reflect-config.json文件中添加如下配置：

[{"name": "com.example.MyClass","allDeclaredFields": true,"allDeclaredMethods": true}
]

构建native镜像

dockerfile.native

FROM quay.io/quarkus/ubi-quarkus-native-image:22.3-java11 AS buildWORKDIR /workspace
COPY . .RUN ./mvnw package -Pnative -Dquarkus.native.container-build=true# Stage 2: Create the minimal runtime image
FROM registry.access.redhat.com/ubi8/ubi-minimal:8.6WORKDIR /work/
RUN chown 1001 /work \&& chmod "g+rwX" /work \&& chown 1001:root /workCOPY --from=build /workspace/target/*-runner /work/applicationEXPOSE 8080
USER 1001CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]