GraalVM Native Image mit Spring Boot 3 in 2026: AOT-Kompilierung Schritt für Schritt
Vollständiger Leitfaden zum Kompilieren von Spring Boot 3-Anwendungen zu Native Images mit GraalVM. AOT-Konfiguration, Optimierungen und Produktionsbereitstellung.

Die Native-Kompilierung mit GraalVM verwandelt Spring Boot 3-Anwendungen in native ausführbare Dateien. Die Startzeit sinkt von Sekunden auf Millisekunden und der Speicherverbrauch reduziert sich drastisch. Dieser Leitfaden behandelt jeden Schritt von der AOT-Konfiguration bis zur Produktionsbereitstellung.
GraalVM 22.3+ mit installiertem Native Image, Spring Boot 3.2+ sowie Maven oder Gradle. Die Native-Kompilierung benötigt mehr RAM (8 GB Minimum empfohlen) und dauert mehrere Minuten.
AOT- und Native-Image-Kompilierung verstehen
Unterschied zwischen JIT und AOT
Die klassische JVM nutzt Just-In-Time-Kompilierung (JIT): Der Bytecode wird interpretiert und während der Ausführung in Maschinencode kompiliert. GraalVM Native Image verfolgt den Ahead-Of-Time-Ansatz (AOT): Der gesamte Code wird vor der Ausführung kompiliert.
┌─────────────────────────────────────────────────────────────┐
│ JIT Compilation │
├─────────────────────────────────────────────────────────────┤
│ │
│ .java → .class → JVM → Interpretation → JIT → Machine │
│ (runtime) (runtime) │
│ │
│ Advantages: Adaptive optimizations, fast class loading │
│ Disadvantages: Slow startup, high memory consumption │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ AOT Compilation │
├─────────────────────────────────────────────────────────────┤
│ │
│ .java → .class → GraalVM Native Image → Native executable │
│ (build time) │
│ │
│ Advantages: Instant startup, low memory footprint │
│ Disadvantages: Long build, no dynamic reflection │
└─────────────────────────────────────────────────────────────┘Die AOT-Kompilierung analysiert statisch den gesamten vom Einstiegspunkt erreichbaren Code. Code, der zur Build-Zeit nicht erkannt wird, fließt nicht ins Native Image ein. Daraus erklären sich die Einschränkungen bei Reflection und dynamischem Klassenladen.
Spring-AOT-Architektur
Spring Boot 3 integriert die AOT-Unterstützung nativ. Der Kompilierungsprozess erzeugt zusätzlichen Quellcode, der dynamische Mechanismen durch statische Äquivalente ersetzt.
// Standard Spring configuration
@Configuration
@EnableCaching
public class ApplicationConfig {
@Bean
public CacheManager cacheManager() {
// Bean created dynamically at runtime in JIT mode
// Pre-generated statically in AOT mode
return new ConcurrentMapCacheManager("users", "products");
}
@Bean
@ConditionalOnProperty(name = "app.feature.enabled", havingValue = "true")
public FeatureService featureService() {
// Conditions are evaluated at build time in AOT
return new FeatureServiceImpl();
}
}Der Spring-AOT-Prozess generiert automatisch Dateien unter target/spring-aot/main:
target/spring-aot/main/
├── sources/ # Generated Java code
│ └── com/example/
│ └── ApplicationConfig__BeanDefinitions.java
├── resources/
│ └── META-INF/
│ └── native-image/
│ ├── reflect-config.json # Reflection configuration
│ ├── resource-config.json # Included resources
│ └── proxy-config.json # JDK proxiesKonfiguration des Spring-Boot-Projekts
Maven-Abhängigkeiten
Die Maven-Konfiguration nutzt das Spring-Boot-Plugin mit dem native-Profil. Die Abhängigkeiten müssen GraalVM-kompatibel sein.
<!-- pom.xml -->
<!-- Complete configuration for Spring Boot 3 Native -->
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.4.2</version>
<relativePath/>
</parent>
<groupId>com.example</groupId>
<artifactId>native-demo</artifactId>
<version>1.0.0</version>
<properties>
<java.version>21</java.version>
</properties>
<dependencies>
<!-- Web starter with built-in native support -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!-- JPA with native-compatible Hibernate 6 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<!-- Native-compatible PostgreSQL driver -->
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<scope>runtime</scope>
</dependency>
<!-- Validation with native hints -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
<!-- Tests with native support -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<!-- GraalVM plugin for native compilation -->
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
<!-- Profile for native build -->
<profiles>
<profile>
<id>native</id>
<build>
<plugins>
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<!-- Native build options -->
<buildArgs>
<!-- Size optimizations -->
<buildArg>-O2</buildArg>
<!-- Generate build report -->
<buildArg>--verbose</buildArg>
<!-- Enable HTTP/2 support -->
<buildArg>--enable-http</buildArg>
<buildArg>--enable-https</buildArg>
</buildArgs>
<!-- Memory for build -->
<jvmArgs>
<jvmArg>-Xmx8g</jvmArg>
</jvmArgs>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>Entsprechende Gradle-Konfiguration
Für Gradle-Projekte ist die Native-Konfiguration mit dem GraalVM-Native-Plugin vergleichbar.
// Gradle configuration for Spring Boot Native
plugins {
java
id("org.springframework.boot") version "3.4.2"
id("io.spring.dependency-management") version "1.1.7"
// GraalVM Native plugin
id("org.graalvm.buildtools.native") version "0.10.4"
}
group = "com.example"
version = "1.0.0"
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
dependencies {
implementation("org.springframework.boot:spring-boot-starter-web")
implementation("org.springframework.boot:spring-boot-starter-data-jpa")
runtimeOnly("org.postgresql:postgresql")
testImplementation("org.springframework.boot:spring-boot-starter-test")
}
// Native build configuration
graalvmNative {
binaries {
named("main") {
// Generated executable name
imageName = "native-demo"
// Compilation options
buildArgs.addAll(
"-O2", // Optimization level
"--enable-http", // HTTP support
"--enable-https", // HTTPS support
"--verbose" // Detailed logs
)
// Memory configuration for build
jvmArgs.addAll("-Xmx8g")
}
named("test") {
// Native tests with report
buildArgs.add("--verbose")
}
}
// Tracing agent for automatic discovery
agent {
defaultMode = "standard"
enabled = true
}
}
tasks.withType<Test> {
useJUnitPlatform()
}Der Tracing Agent (-agentlib:native-image-agent) erkennt Reflection-Aufrufe automatisch zur Laufzeit. Anwendung mit dem Agent starten, alle Funktionen durchlaufen und anschließend die generierten Konfigurationsdateien verwenden.
Reflection und Ressourcen verwalten
Manuelle Reflection-Konfiguration
Manche Bibliotheken nutzen Reflection auf Wegen, die die statische Analyse nicht erkennt. Dann ist eine manuelle Konfiguration erforderlich.
// Configuration for classes requiring reflection
[
{
"name": "com.example.entity.User",
"allDeclaredConstructors": true,
"allDeclaredMethods": true,
"allDeclaredFields": true
},
{
"name": "com.example.dto.UserDTO",
"allDeclaredConstructors": true,
"allDeclaredMethods": true,
"allDeclaredFields": true
},
{
"name": "com.example.config.DynamicProperties",
"methods": [
{ "name": "getValue", "parameterTypes": [] },
{ "name": "setValue", "parameterTypes": ["java.lang.String"] }
]
}
]Spring RuntimeHints einsetzen
Spring Boot 3 stellt eine programmatische API für Native-Hints bereit, die wartungsfreundlicher ist als JSON-Dateien.
// Programmatic registration of native hints
@Configuration
@ImportRuntimeHints(NativeHintsRegistrar.AppRuntimeHints.class)
public class NativeHintsRegistrar {
static class AppRuntimeHints implements RuntimeHintsRegistrar {
@Override
public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
// Register classes for reflection
hints.reflection()
// JPA entities with all members
.registerType(User.class, MemberCategory.values())
.registerType(Order.class, MemberCategory.values())
// DTOs with constructors and getters/setters
.registerType(UserDTO.class,
MemberCategory.INVOKE_DECLARED_CONSTRUCTORS,
MemberCategory.INVOKE_DECLARED_METHODS,
MemberCategory.DECLARED_FIELDS
);
// Register resources to include
hints.resources()
// Configuration files
.registerPattern("application*.yml")
.registerPattern("application*.properties")
// Templates and static files
.registerPattern("templates/*")
.registerPattern("static/**/*")
// Validation messages
.registerPattern("ValidationMessages*.properties");
// Register JDK proxies
hints.proxies()
.registerJdkProxy(
UserRepository.class,
Repository.class
);
// Serialization for caching
hints.serialization()
.registerType(User.class)
.registerType(ArrayList.class);
}
}
}// Automatic hints for JPA entities
@Component
public class EntityRuntimeHints implements RuntimeHintsRegistrar {
@Override
public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
// Automatic scan of entities in package
ClassPathScanningCandidateComponentProvider scanner =
new ClassPathScanningCandidateComponentProvider(false);
scanner.addIncludeFilter(new AnnotationTypeFilter(Entity.class));
for (BeanDefinition bd : scanner.findCandidateComponents("com.example.entity")) {
try {
Class<?> entityClass = Class.forName(bd.getBeanClassName());
// Register each entity for full reflection
hints.reflection().registerType(
entityClass,
MemberCategory.INVOKE_DECLARED_CONSTRUCTORS,
MemberCategory.INVOKE_DECLARED_METHODS,
MemberCategory.DECLARED_FIELDS
);
} catch (ClassNotFoundException e) {
// Log error without interrupting build
System.err.println("Entity class not found: " + bd.getBeanClassName());
}
}
}
}Bereit für deine Spring Boot-Interviews?
Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.
Native Image kompilieren und optimieren
Build-Befehle
Die Native-Kompilierung erfolgt mit Maven oder Gradle. Der Vorgang dauert mehrere Minuten und benötigt erhebliche Ressourcen.
# Maven build with native profile
# Generates executable in target/
mvn -Pnative native:compile
# Gradle build
# Generates executable in build/native/nativeCompile/
./gradlew nativeCompile
# Build with native tests included
mvn -Pnative native:compile -DskipTests=false
# Build with tracing agent enabled
mvn -Pnative -Dagent=true test
mvn -Pnative native:compileErweiterte Optimierungsoptionen
Die Kompilierungsoptionen wirken sich auf Image-Größe, Startzeit und Laufzeitperformance aus.
<!-- pom.xml -->
<!-- Advanced native build configuration -->
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>
<!-- Optimization level (0-3, default: 2) -->
<buildArg>-O3</buildArg>
<!-- Optimization for startup time -->
<buildArg>--pgo-instrument</buildArg>
<!-- Executable compression (reduces size) -->
<buildArg>-H:+CompressStrings</buildArg>
<!-- Optimal garbage collector for containers -->
<buildArg>--gc=serial</buildArg>
<!-- Build time initialization -->
<buildArg>--initialize-at-build-time=org.slf4j</buildArg>
<!-- Debug symbols (disable in prod) -->
<buildArg>-H:-IncludeAllTimeZones</buildArg>
<!-- Detailed build report -->
<buildArg>-H:+ReportExceptionStackTraces</buildArg>
<buildArg>--verbose</buildArg>
<!-- Monitoring support -->
<buildArg>--enable-monitoring=heapdump,jfr</buildArg>
</buildArgs>
<!-- Quickbuild for development (faster, less optimized) -->
<quickBuild>false</quickBuild>
<!-- Fallback to jar if native fails -->
<fallback>false</fallback>
</configuration>
</plugin>// Build time initialization to reduce startup
@Configuration
public class BuildTimeInitializer {
// These configurations are evaluated at build time
// not at runtime
static {
// Initialize loggers at build time
LoggerFactory.getLogger(BuildTimeInitializer.class);
}
@Bean
@NativeHint(options = "--initialize-at-build-time=com.example.Constants")
public ConstantsProvider constantsProvider() {
// Constants are computed once at build
return new ConstantsProvider();
}
}Performance-Vergleich
Die Performance-Gewinne durch Native-Kompilierung sind beträchtlich.
┌─────────────────────────────────────────────────────────────────────┐
│ JIT vs Native Comparison │
├─────────────────────┬─────────────────┬─────────────────────────────┤
│ Metric │ JIT (JVM) │ Native (GraalVM) │
├─────────────────────┼─────────────────┼─────────────────────────────┤
│ Startup time │ 2.5 - 5 sec │ 50 - 200 ms │
│ RSS Memory │ 200 - 400 MB │ 50 - 100 MB │
│ Executable size │ JAR ~30 MB │ Binary ~80 MB │
│ First request time │ 100 - 500 ms │ < 10 ms │
│ Peak throughput │ Excellent │ Good (85-95% of JIT) │
│ Build time │ 30 sec │ 3 - 10 min │
└─────────────────────┴─────────────────┴─────────────────────────────┘Der maximale Durchsatz im Native-Modus kann etwas niedriger sein als im JIT-Modus, da adaptive JIT-Optimierungen entfallen. Bei Workloads mit dauerhaft hoher Last sollten beide Modi evaluiert werden.
Häufige Probleme beheben
Reflection-Fehler
Der häufigste Fehler beruht auf nicht deklarierter Reflection. Die Exception zeigt die fehlende Klasse.
// Diagnosing and resolving reflection errors
@Component
@Slf4j
public class ReflectionErrorHandler {
// Typical error:
// java.lang.ClassNotFoundException: com.example.SomeClass
// when accessing via reflection
// Solution 1: Add manual configuration
// src/main/resources/META-INF/native-image/reflect-config.json
// Solution 2: Use @RegisterReflection annotation
@RegisterReflection(classes = {
SomeClass.class,
AnotherClass.class
})
public void configureReflection() {
// Annotated classes will be available for reflection
}
// Solution 3: Programmatic RuntimeHints
public void registerHints(RuntimeHints hints) {
hints.reflection().registerType(
SomeClass.class,
MemberCategory.INVOKE_DECLARED_CONSTRUCTORS,
MemberCategory.INVOKE_DECLARED_METHODS
);
}
}Fehlende Ressourcen
Ressourcendateien müssen explizit deklariert werden, damit sie ins Native Image aufgenommen werden.
// Configuration for resources to include
{
"resources": {
"includes": [
{"pattern": "application\\.yml"},
{"pattern": "application-.*\\.yml"},
{"pattern": "messages.*\\.properties"},
{"pattern": "templates/.*\\.html"},
{"pattern": "static/.*"},
{"pattern": "db/migration/.*\\.sql"}
],
"excludes": [
{"pattern": ".*\\.java"},
{"pattern": ".*\\.class"}
]
},
"bundles": [
{"name": "messages"},
{"name": "ValidationMessages"}
]
}// Programmatic resource configuration
@Configuration
@ImportRuntimeHints(ResourceHintsConfig.ResourceHints.class)
public class ResourceHintsConfig {
static class ResourceHints implements RuntimeHintsRegistrar {
@Override
public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
// YAML/Properties files
hints.resources()
.registerPattern("application*.yml")
.registerPattern("application*.properties");
// Thymeleaf templates
hints.resources().registerPattern("templates/**");
// Flyway SQL scripts
hints.resources().registerPattern("db/migration/*.sql");
// Static files
hints.resources().registerPattern("static/**");
// Message bundles
hints.resources().registerResourceBundle("messages");
hints.resources().registerResourceBundle("ValidationMessages");
}
}
}Probleme mit Proxies
JDK- und CGLIB-Proxies benötigen eine spezielle Konfiguration, damit sie im Native-Modus funktionieren.
// Managing proxies for native compilation
@Configuration
public class ProxyConfiguration implements RuntimeHintsRegistrar {
@Override
public void registerHints(RuntimeHints hints, ClassLoader classLoader) {
// JDK proxies for Spring Data interfaces
hints.proxies().registerJdkProxy(
UserRepository.class,
Repository.class,
CrudRepository.class
);
// Proxies for service interfaces
hints.proxies().registerJdkProxy(
PaymentService.class,
TransactionalService.class
);
}
// Alternative: force CGLIB proxies
@Bean
public BeanFactoryPostProcessor forceProxyTargetClass() {
return beanFactory -> {
// Use CGLIB instead of JDK proxies
// More compatible with native compilation
};
}
}Bereitstellung mit Docker und Kubernetes
Optimiertes Multi-Stage-Dockerfile
Der Multi-Stage-Build trennt Kompilierung und Ausführung, um ein minimales Image zu erhalten.
# Dockerfile
# Multi-stage build for Spring Boot Native
# Stage 1: Build with GraalVM
FROM ghcr.io/graalvm/graalvm-community:21 AS builder
# Install Native Image
RUN gu install native-image
WORKDIR /app
# Copy build files
COPY pom.xml .
COPY src ./src
# Install Maven
RUN microdnf install -y maven
# Native build with dependency caching
RUN \
mvn -Pnative native:compile -DskipTests
# Stage 2: Minimal runtime image
FROM gcr.io/distroless/base-debian12
WORKDIR /app
# Copy native executable
COPY /app/target/native-demo /app/native-demo
# Exposed port
EXPOSE 8080
# Healthcheck
HEALTHCHECK \
CMD ["/app/native-demo", "--health"]
# Execution
ENTRYPOINT ["/app/native-demo"]# Dockerfile.alpine
# Alternative with Alpine for even smaller image
FROM ghcr.io/graalvm/native-image-community:21-muslib AS builder
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN \
mvn -Pnative native:compile \
-Dspring-boot.aot.jvmArguments="-Dspring.aot.processing.resource.matching.strategy=GLOB" \
-DskipTests
# Minimal Alpine image (< 20 MB)
FROM alpine:3.19
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY /app/target/native-demo /app/native-demo
EXPOSE 8080
ENTRYPOINT ["/app/native-demo"]Kubernetes-Deployment mit optimierten Ressourcen
Native Anwendungen benötigen weniger Ressourcen als klassische JVM-Anwendungen.
# kubernetes/deployment.yaml
# Optimized Kubernetes deployment for native
apiVersion: apps/v1
kind: Deployment
metadata:
name: native-demo
spec:
replicas: 3
selector:
matchLabels:
app: native-demo
template:
metadata:
labels:
app: native-demo
spec:
containers:
- name: native-demo
image: registry.example.com/native-demo:1.0.0
ports:
- containerPort: 8080
# Reduced resources thanks to native
resources:
requests:
memory: "64Mi" # vs 256Mi for JVM
cpu: "50m" # vs 200m for JVM
limits:
memory: "128Mi" # vs 512Mi for JVM
cpu: "200m" # vs 500m for JVM
# Fast probes (instant startup)
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 1 # vs 30s for JVM
periodSeconds: 5
failureThreshold: 3
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 2 # vs 60s for JVM
periodSeconds: 10
failureThreshold: 3
# Environment variables
env:
- name: SPRING_PROFILES_ACTIVE
value: "production"
- name: JAVA_TOOL_OPTIONS
value: "" # No JVM options needed
---
apiVersion: v1
kind: Service
metadata:
name: native-demo
spec:
selector:
app: native-demo
ports:
- port: 80
targetPort: 8080
type: ClusterIP
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: native-demo-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: native-demo
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Die sofortige Startzeit ermöglicht eine sehr schnelle horizontale Skalierung. Neue Pods sind innerhalb von Sekunden bereit – ideal für Workloads mit Lastspitzen.
Native Image testen und validieren
Konfiguration nativer Tests
Tests können ebenfalls nativ kompiliert und ausgeführt werden, um das Verhalten zu validieren.
// Integration tests for native validation
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestPropertySource(properties = {
"spring.datasource.url=jdbc:h2:mem:testdb",
"spring.jpa.hibernate.ddl-auto=create-drop"
})
class NativeIntegrationTest {
@Autowired
private TestRestTemplate restTemplate;
@Autowired
private UserRepository userRepository;
@Test
void shouldCreateAndRetrieveUser() {
// Arrange: create a user
UserDTO request = new UserDTO("John", "john@example.com");
// Act: API call
ResponseEntity<UserDTO> createResponse = restTemplate.postForEntity(
"/api/users",
request,
UserDTO.class
);
// Assert: verify creation
assertThat(createResponse.getStatusCode()).isEqualTo(HttpStatus.CREATED);
assertThat(createResponse.getBody()).isNotNull();
assertThat(createResponse.getBody().getName()).isEqualTo("John");
// Verify retrieval
Long userId = createResponse.getBody().getId();
ResponseEntity<UserDTO> getResponse = restTemplate.getForEntity(
"/api/users/{id}",
UserDTO.class,
userId
);
assertThat(getResponse.getStatusCode()).isEqualTo(HttpStatus.OK);
assertThat(getResponse.getBody().getEmail()).isEqualTo("john@example.com");
}
@Test
void shouldHandleReflectionCorrectly() {
// Specific test to validate reflection configuration
User user = new User();
user.setName("Test");
user.setEmail("test@example.com");
// ORM uses reflection to map entities
User saved = userRepository.save(user);
assertThat(saved.getId()).isNotNull();
assertThat(userRepository.findById(saved.getId())).isPresent();
}
}<!-- pom.xml -->
<!-- Native tests configuration -->
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<testArgs>
<!-- Include tests in native build -->
<testArg>--verbose</testArg>
</testArgs>
</configuration>
<executions>
<execution>
<id>test-native</id>
<goals>
<goal>test</goal>
</goals>
<phase>test</phase>
</execution>
</executions>
</plugin>Bereit für deine Spring Boot-Interviews?
Übe mit unseren interaktiven Simulatoren, Flashcards und technischen Tests.
Fazit
Die Native-Kompilierung mit GraalVM verwandelt Spring Boot 3-Anwendungen in performante ausführbare Dateien. Wichtige Punkte:
Projektkonfiguration:
- ✅ Spring Boot 3.2+ mit GraalVM-Native-Plugin
- ✅ RuntimeHints für Reflection und Ressourcen
- ✅ Tracing Agent für automatische Erkennung
Build-Optimierungen:
- ✅ Passende Kompilierungsoptionen (O2/O3, GC, Komprimierung)
- ✅ Build-Time-Initialisierung für statische Komponenten
- ✅ Quickbuild für die Entwicklung, Vollbuild für die Produktion
Fehlerbehebung:
- ✅ Explizite Reflection-Konfiguration für Drittbibliotheken
- ✅ Deklaration der einzubeziehenden Ressourcen
- ✅ Verwaltung von JDK- und CGLIB-Proxies
Bereitstellung:
- ✅ Multi-Stage-Docker-Images mit distroless
- ✅ Geringere Kubernetes-Ressourcen (64 Mi statt 256 Mi)
- ✅ Probes mit minimaler Verzögerung (sofortiger Start)
Die Native-Kompilierung ist ideal für Microservices, Serverless-Funktionen und ressourcenbeschränkte Umgebungen. Der sofortige Start und der niedrige Speicherverbrauch wiegen die längere Build-Zeit deutlich auf.
Fang an zu üben!
Teste dein Wissen mit unseren Interview-Simulatoren und technischen Tests.
Tags
Teilen
Verwandte Artikel

Spring Boot Logging im Jahr 2026: strukturierte Logs in Produktion mit Logback und JSON
Vollständiger Leitfaden zu strukturiertem Logging in Spring Boot. Logback-JSON-Konfiguration, MDC für Tracing, Best Practices in Produktion und ELK-Stack-Integration.

Spring Kafka: ereignisgesteuerte Architektur mit resilienten Consumern
Vollständiger Spring-Kafka-Leitfaden für ereignisgesteuerte Architekturen. Konfiguration, resiliente Consumer, Retry-Strategien, Dead Letter Queues und Produktionsmuster für verteilte Anwendungen.

Spring GraphQL Interview: Resolver, DataLoader und Lösungen für das N+1-Problem
Vorbereitung auf Spring GraphQL Interviews mit diesem vollständigen Leitfaden. Resolver, DataLoader, Umgang mit dem N+1-Problem, Mutationen und Best Practices für technische Fragen.