Hibernate und JPA haben einen schlechten Ruf in Sachen Performance. Aber in den meisten Fällen liegt das Problem nicht beim Framework, sondern bei typischen Anwendungsfehlern, die sich leicht vermeiden lassen.

Hier sind die fünf häufigsten Performance-Killer — und ihre Lösung.

1. Das N+1 Query Problem

Der Klassiker. Sie laden eine Liste von Bestellungen, und für jede Bestellung wird eine separate Query für den Kunden ausgeführt.

Das Problem:

// 1 Query für Bestellungen + N Queries für Kunden
List<Bestellung> bestellungen = em.createQuery(
    "SELECT b FROM Bestellung b", Bestellung.class)
    .getResultList();

for (Bestellung b : bestellungen) {
    System.out.println(b.getKunde().getName()); // Lazy Load!
}

Die Lösung: JOIN FETCH

List<Bestellung> bestellungen = em.createQuery(
    "SELECT b FROM Bestellung b JOIN FETCH b.kunde",
    Bestellung.class)
    .getResultList();

Eine Query statt N+1. Bei 1.000 Bestellungen ist das der Unterschied zwischen 1 und 1.001 Datenbankaufrufen.

2. Eager Loading als Default

@ManyToOne ist standardmäßig EAGER — das bedeutet, jede Relation wird sofort mitgeladen, auch wenn Sie die Daten gar nicht brauchen.

Die Lösung:

@ManyToOne(fetch = FetchType.LAZY)
private Kunde kunde;

Faustregel: Setzen Sie alles auf LAZY und laden Sie gezielt per JOIN FETCH oder EntityGraph, wenn Sie die Daten brauchen.

3. Fehlende Projektionen

Sie brauchen nur Name und E-Mail, laden aber die komplette Entity mit 30 Feldern, LOBs und Relationen.

Das Problem:

// Lädt ALLES — auch Felder, die Sie nicht brauchen
List<Kunde> kunden = em.createQuery(
    "SELECT k FROM Kunde k", Kunde.class)
    .getResultList();

Die Lösung: DTO-Projektionen

record KundeDto(String name, String email) {}

List<KundeDto> kunden = em.createQuery(
    "SELECT new at.cgs.dto.KundeDto(k.name, k.email) FROM Kunde k",
    KundeDto.class)
    .getResultList();

Weniger Daten über die Leitung, kein Dirty Checking, kein Managed State — deutlich schneller.

4. Batch-Operationen ohne Batching

1.000 Entities einzeln persistieren erzeugt 1.000 INSERT-Statements.

Die Lösung:

# application.properties (Quarkus/Spring)
hibernate.jdbc.batch_size=25
hibernate.order_inserts=true
hibernate.order_updates=true

for (int i = 0; i < entities.size(); i++) {
    em.persist(entities.get(i));
    if (i % 25 == 0) {
        em.flush();
        em.clear(); // First-Level Cache leeren!
    }
}

5. Kein Query-Monitoring

Der gefährlichste Fehler: Sie wissen gar nicht, welche Queries Hibernate generiert.

Aktivieren Sie SQL-Logging in der Entwicklung:

# Quarkus
quarkus.hibernate-orm.log.sql=true

# Spring Boot
spring.jpa.show-sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql=TRACE

Für Produktion: Nutzen Sie Hibernate Statistics oder ein APM-Tool (z.B. OpenTelemetry) um langsame Queries zu identifizieren.

Bonus: EntityGraph statt JOIN FETCH

Für flexible Ladingstrategien ohne Query-Anpassung:

@NamedEntityGraph(
    name = "Bestellung.mitKunde",
    attributeNodes = @NamedAttributeNode("kunde")
)
@Entity
public class Bestellung { ... }

// Verwendung
EntityGraph<?> graph = em.getEntityGraph("Bestellung.mitKunde");
List<Bestellung> result = em.createQuery("SELECT b FROM Bestellung b")
    .setHint("jakarta.persistence.fetchgraph", graph)
    .getResultList();

Fazit

JPA und Hibernate sind mächtige Werkzeuge — aber sie verzeihen Unwissenheit nicht. Die gute Nachricht: Die fünf häufigsten Fehler sind leicht zu erkennen und zu beheben. Aktivieren Sie SQL-Logging, prüfen Sie Ihre Fetch-Strategien, und nutzen Sie Projektionen wo möglich.

In unseren Training-Angeboten behandeln wir JPA-Performance als festen Bestandteil der Java-Entwickler-Ausbildung.

Der Beitrag JPA & Hibernate: 5 Performance-Fehler, die fast jedes Projekt macht erschien zuerst auf CGS IT Solutions GmbH.

Microservices sind seit Jahren der Architektur-Trend schlechthin. Und ja — für die richtige Problemstellung sind sie hervorragend. Aber die Realität zeigt: Viele Teams führen Microservices ein, ohne die Voraussetzungen dafür zu haben.

Das Ergebnis ist kein verteiltes System — sondern ein verteilter Monolith: alle Nachteile beider Welten, keine der Vorteile.

Wann Microservices Sinn machen

Microservices lösen organisatorische Probleme, nicht primär technische:

– Mehrere Teams arbeiten unabhängig an verschiedenen Geschäftsbereichen
– Unterschiedliche Release-Zyklen pro Domäne sind notwendig
– Unterschiedliche Skalierungsanforderungen pro Service
– Technologievielfalt ist gewünscht (ein Service in Java, ein anderer in Python)

Wenn Ihr Team aus 3–5 Entwicklern besteht und eine Anwendung betreut: Microservices sind sehr wahrscheinlich der falsche Ansatz.

Der gut strukturierte Monolith

Ein Monolith ist kein Anti-Pattern. Ein schlecht strukturierter Monolith ist das Problem. Die Lösung ist nicht automatisch eine Microservice-Architektur, sondern oft ein Modularer Monolith:

– Klare Modul-Grenzen mit definierten APIs
– Eigene Datenhaltung pro Modul (kein Shared Database)
– Module können unabhängig getestet werden
– Spätere Extraktion in Services ist möglich, wenn nötig

Das Beste aus beiden Welten

Monolith mit klaren Modulen
┌──────────────────────────────────┐
│  ┌──────────┐  ┌──────────┐     │
│  │  Bestell- │  │  Kunden- │     │
│  │  wesen    │  │  verw.   │     │
│  │           │  │          │     │
│  └────┬──────┘  └────┬─────┘    │
│       │  definierte   │          │
│       │  Schnittstelle│          │
│  ┌────┴──────┐  ┌────┴─────┐    │
│  │  Lager    │  │  Billing │    │
│  └───────────┘  └──────────┘    │
│                 Ein Deployment   │
└──────────────────────────────────┘

Die Kosten von Microservices

Was selten erwähnt wird — Microservices erfordern erhebliche Infrastruktur:

Wenn Sie diese Infrastruktur nicht haben oder nicht betreiben können, werden Microservices zum Bremsklotz statt zum Beschleuniger.

Entscheidungshilfe

Starten Sie mit einem Monolith, wenn:
– Ein Team, ein Produkt
– Domäne noch nicht vollständig verstanden
– Schnelle Time-to-Market wichtiger als Skalierbarkeit

Wechseln Sie zu Microservices, wenn:
– Team-Autonomie das Hauptziel ist
– Einzelne Domänen unabhängig skaliert werden müssen
– Sie die Infrastruktur betreiben können (oder wollen)

Fazit

Die beste Architektur ist die, die Ihr Team produktiv macht. Für die meisten mittelständischen Unternehmen ist ein modularer Monolith der pragmatischere Weg — mit der Option, gezielt Services zu extrahieren, wenn der Bedarf entsteht.

Bei CGS IT Solutions beraten wir technologieneutral: Wir empfehlen die Architektur, die zu Ihrer Organisation passt — nicht die, die gerade im Trend liegt. Mehr dazu unter Software Architektur.

Der Beitrag Microservices oder Monolith? Die ehrliche Antwort erschien zuerst auf CGS IT Solutions GmbH.

Genau dafür haben wir den CGS Fragenkatalog entwickelt: ein kostenloses, browser-basiertes Quiz-Tool mit über 540 Fragen zu Java und Software Engineering.

Was steckt drin?

Der Fragenkatalog besteht aus zwei Teilen:

• Java 25 Fragenkatalog — 24 Kapitel, 428 Fragen: Von Grundlagen (JVM, Datentypen, Kontrollstrukturen) über Collections, Streams und Generics bis hin zu modernen Features wie Virtual Threads, Pattern Matching und Sealed Classes.
• Software Engineering Fragenkatalog — 12 Kapitel, 115 Fragen: Projektmanagement, Vorgehensmodelle, Qualitätssicherung, Versionskontrolle, UML, Datenbanken und mehr.

Für wen ist das gedacht?

• Java-Entwickler:innen, die ihr Wissen testen und Lücken finden wollen
• Studierende, die sich auf Prüfungen vorbereiten
• Workshop-Teilnehmer:innen unserer Quarkus- und Java-Trainings
• Trainer:innen und Lehrende, die ein fertiges Prüfungstool brauchen

Features

• Sofort-Auswertung — Jede Antwort wird direkt geprüft, mit Erklärung bei falscher Antwort
• Schwierigkeitsgrade — Easy, Medium und Advanced, filterbar
• Fortschritt wird gespeichert — Dank Browser-Speicher geht nichts verloren
• Dark/Light Mode — Augenschonend zu jeder Tageszeit
• Syntax-Highlighting — Java-Code in den Fragen wird korrekt formatiert
• Scoreboard — Live-Übersicht über richtige/falsche Antworten, mit Sprung zu Fehlern
• 100% im Browser — Kein Login, kein Server, keine Installation nötig

Jetzt ausprobieren

Der Fragenkatalog ist kostenlos verfügbar unter quiz.cgs.at — einfach öffnen und loslegen. Kein Account, keine Registrierung.

Sie möchten den Fragenkatalog in Ihrem Unternehmen oder Ihrer Lehrveranstaltung einsetzen? Wir bieten auch maßgeschneiderte Versionen mit eigenen Fragen und Auswertung. Kontaktieren Sie uns für ein individuelles Angebot.

Der Beitrag CGS Fragenkatalog: 540+ Quizfragen zu Java und Software Engineering erschien zuerst auf CGS IT Solutions GmbH.

Java 21 ist nicht einfach ein weiteres Update — es ist das umfangreichste LTS-Release seit Java 11. Mit Virtual Threads, ausgereiftem Pattern Matching und Records wird Java zu einer deutlich moderneren Sprache. Hier sind die Features, die im Projektalltag den größten Unterschied machen.

1. Virtual Threads (Project Loom)

Das wahrscheinlich wichtigste Feature: Leichtgewichtige Threads, die von der JVM verwaltet werden.

Vorher: Platform Threads

// Jeder Thread = ein OS-Thread (~1 MB Stack)
// Bei 10.000 gleichzeitigen Requests: 10 GB RAM nur für Threads
ExecutorService executor = Executors.newFixedThreadPool(200);

Nachher: Virtual Threads

// Millionen gleichzeitiger Threads möglich
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

// Oder direkt
Thread.startVirtualThread(() -> {
    var result = httpClient.send(request, BodyHandlers.ofString());
    // Blocking ist OK — der Virtual Thread wird geparkt, nicht der OS-Thread
});

Wann einsetzen: Bei I/O-lastigen Anwendungen (REST-APIs, Datenbankzugriffe, HTTP-Clients). Nicht relevant für CPU-intensive Berechnungen.

Quarkus und Spring Boot unterstützen Virtual Threads bereits — oft reicht eine Konfigurationsänderung.

2. Pattern Matching for switch

Typprüfungen und Casts in einem Schritt — deutlich lesbarer als verschachtelte instanceof-Ketten.

Vorher:

if (shape instanceof Circle c) {
    return c.radius()  c.radius()  Math.PI;
} else if (shape instanceof Rectangle r) {
    return r.width() * r.height();
} else {
    throw new IllegalArgumentException("Unknown shape");
}

Nachher:

return switch (shape) {
    case Circle c    -> c.radius()  c.radius()  Math.PI;
    case Rectangle r -> r.width() * r.height();
    default          -> throw new IllegalArgumentException("Unknown shape");
};

In Kombination mit Sealed Classes prüft der Compiler Vollständigkeit — kein default nötig:

sealed interface Shape permits Circle, Rectangle {}
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}

// Compiler weiß: alle Fälle abgedeckt
double area = switch (shape) {
    case Circle c    -> c.radius()  c.radius()  Math.PI;
    case Rectangle r -> r.width() * r.height();
};

3. Records für DTOs und Value Objects

Records eliminieren Boilerplate für unveränderliche Datenobjekte:

// Statt 50 Zeilen mit Konstruktor, Getter, equals, hashCode, toString:
record KundeDto(String name, String email, LocalDate registriert) {}

// Verwendung
var kunde = new KundeDto("Max Mustermann", "max@example.com", LocalDate.now());
System.out.println(kunde.name()); // Accessor ohne "get"

Ideal für: JPA-Projektionen, REST-Request/Response-Objekte, Event-Payloads.

4. Sequenced Collections

Endlich eine einheitliche API für den Zugriff auf erstes und letztes Element:

// Vorher: Inkonsistent
list.get(0);                    // List
set.iterator().next();          // SortedSet
deque.getFirst();               // Deque

// Nachher: Einheitlich
collection.getFirst();
collection.getLast();
collection.reversed();

5. String Templates (Preview)

Interpolation direkt in Java — kein String.format oder +-Verkettung mehr:

// Preview in Java 21, stabil erwartet in Java 23+
String html = STR."""
    <h1>\{kunde.name()}</h1>
    <p>Registriert seit \{kunde.registriert()}</p>
    """;

Migration von Java 11/17 auf 21

Die Migration ist in den meisten Fällen unkompliziert:

1. Build-Tool aktualisieren: Maven Compiler Plugin auf Java 21
2. Dependencies prüfen: Die meisten Libraries unterstützen Java 21
3. Deprecated APIs ersetzen: SecurityManager ist deprecated
4. Schrittweise Features einführen: Records und Pattern Matching zuerst, Virtual Threads nach Lasttests

<properties>
    <maven.compiler.source>21</maven.compiler.source>
    <maven.compiler.target>21</maven.compiler.target>
</properties>

Fazit

Java 21 macht die Sprache kompakter, ausdrucksstärker und leistungsfähiger. Virtual Threads allein rechtfertigen die Migration — sie beseitigen das größte Skalierungsproblem von Java-Anwendungen ohne Code-Änderungen.

Wenn Sie noch auf Java 11 oder 17 sind: Die Migration auf 21 lohnt sich. In unseren Schulungen zeigen wir, wie Sie die neuen Features praxisnah in bestehende Projekte integrieren.

Der Beitrag Java 21 in der Praxis: Die Features, die Ihren Code verändern erschien zuerst auf CGS IT Solutions GmbH.

Java-Microservices galten lange als ressourcenhungrig: langsame Startzeiten, hoher Speicherverbrauch, schwerfällige Application Server. Quarkus ändert das grundlegend.

Als Kubernetes-natives Java-Framework kombiniert Quarkus das Beste aus dem Java-Enterprise-Ökosystem (CDI, JPA, JAX-RS) mit einer Build-Time-Optimierung, die Startzeiten im Millisekundenbereich und minimalen Speicherverbrauch ermöglicht.

Die entscheidenden Vorteile

1. Build-Time statt Runtime

Klassische Java-Frameworks wie Spring erledigen viel Arbeit beim Start: Classpath-Scanning, Reflection, Proxy-Generierung. Quarkus verlagert das alles in den Build-Prozess. Das Ergebnis:

– Startzeit: ~0,5 Sekunden (JVM) bzw. ~15 ms (Native)
– Speicher: ~70 MB (JVM) vs. ~300 MB bei klassischen Frameworks
– Ideal für Serverless und Auto-Scaling-Szenarien

2. Vertraute Standards

Quarkus setzt auf bewährte Java-Standards — keine neue API zu lernen:

– CDI für Dependency Injection
– JAX-RS (RESTEasy) für REST-Endpoints
– JPA (Hibernate ORM) mit Panache für vereinfachten Datenzugriff
– MicroProfile für Health, Metrics, Config, Fault Tolerance

3. Developer Experience

Der Entwicklungsalltag mit Quarkus fühlt sich modern an:

– Live Reload: Code ändern, Browser refreshen — fertig
– Dev Services: Testcontainers starten automatisch (PostgreSQL, Kafka, Redis)
– Unified Config: Eine application.properties für alles

Quickstart: REST-Service in 5 Minuten

# Projekt generieren
mvn io.quarkus.platform:quarkus-maven-plugin:create \
  -DprojectGroupId=at.cgs \
  -DprojectArtifactId=demo-service \
  -Dextensions="resteasy-reactive-jackson,hibernate-orm-panache,jdbc-postgresql"

cd demo-service
./mvnw quarkus:dev

Damit haben Sie einen laufenden REST-Service mit Hot-Reload, Dev-UI unter localhost:8080/q/dev/ und automatischer PostgreSQL-Testinstanz.

Wann Quarkus die richtige Wahl ist

Quarkus eignet sich besonders für:

– Neue Microservices in containerisierten Umgebungen (Kubernetes, OpenShift)
– Serverless Functions (AWS Lambda, Azure Functions)
– Event-Driven Architectures mit Kafka oder AMQP
– Teams mit Java-EE-Erfahrung, die ohne Umlernen modern entwickeln wollen

Weniger geeignet ist es für monolithische Legacy-Anwendungen, die bereits auf Spring Boot aufgebaut sind — hier ist eine Migration selten wirtschaftlich sinnvoll.

Fazit

Quarkus ist kein Hype, sondern eine technisch fundierte Antwort auf die Anforderungen moderner Cloud-Architekturen. Wer Java-Microservices entwickelt, sollte Quarkus ernsthaft evaluieren.

CGS IT Solutions bietet hierzu einen praxisorientierten Quarkus Microservice Workshop an — von den Grundlagen bis zum produktionsreifen Deployment.

Der Beitrag Quarkus: Der moderne Weg zu Java-Microservices erschien zuerst auf CGS IT Solutions GmbH.

Software-Architektur wird oft mit Boxen und Pfeilen gleichgesetzt. Aber Architektur sind die Entscheidungen, die schwer rückgängig zu machen sind — und die den Rahmen für alles Weitere setzen.

Hier sind die fünf Entscheidungen, die den größten Einfluss auf den Erfolg eines Softwareprojekts haben.

1. Synchron oder Asynchron?

Die fundamentalste Entscheidung: Kommunizieren Ihre Komponenten synchron (Request/Response) oder asynchron (Events/Messages)?

Synchron (REST, gRPC):
– Einfacher zu verstehen und zu debuggen
– Direkte Fehlermeldung an den Aufrufer
– Enge Kopplung zwischen Sender und Empfänger

Asynchron (Kafka, RabbitMQ, SQS):
– Lose Kopplung, höhere Resilienz
– Natürliche Skalierbarkeit durch Queues
– Komplexeres Fehlerhandling, Eventual Consistency

Empfehlung: Starten Sie synchron und führen Sie Asynchronität gezielt ein, wo sie Probleme löst — nicht als Grundsatzentscheidung.

2. Datenhoheit: Shared Database oder Database per Service?

Teilen sich Ihre Services eine Datenbank — oder hat jeder Service seine eigene?

Die Wahrheit: Die meisten Systeme brauchen einen Mittelweg. Logische Trennung (eigenes Schema pro Service) mit physisch geteilter Infrastruktur ist oft der pragmatische Start.

3. Deployment-Einheit: Monolith, Modulith oder Microservices?

Diese Entscheidung bestimmt Ihre gesamte Infrastruktur, CI/CD-Pipeline und Team-Organisation:

– Monolith: Ein Artefakt, einfaches Deployment, ein Team
– Modulith: Ein Artefakt mit klaren internen Grenzen, mehrere Teams möglich
– Microservices: Mehrere Artefakte, unabhängiges Deployment, Team-pro-Service

Die Entscheidung hängt weniger von der Technik ab als von der Teamgröße und -struktur (Conway’s Law).

4. Frontend-Architektur: Server-Rendered oder SPA?

Oft unterschätzt, aber schwer zu ändern:

Server-Side Rendering (Thymeleaf, JSF, HTMX):
– Weniger Komplexität, kein separater Build-Prozess
– SEO-freundlich out of the box
– Gut für content-lastige Anwendungen

Single Page Application (React, Angular, Vue):
– Reichere Interaktivität
– Eigenes Team für Frontend möglich
– API-first ermöglicht mehrere Clients (Web, Mobile)

Trend: HTMX und Server Components (React) bringen die Welten zusammen.

5. Fehlerbehandlungsstrategie

Die am häufigsten vergessene Architekturentscheidung: Was passiert, wenn etwas schiefgeht?

Definieren Sie frühzeitig:
– Circuit Breaker: Wann wird ein abhängiger Service als „down“ betrachtet?
– Retry-Strategie: Wie oft, mit welchem Backoff?
– Fallback-Verhalten: Degraded Mode oder Fehlerseite?
– Timeout-Budgets: Wie lange darf ein Request maximal dauern?

Ohne diese Entscheidungen wird Ihr System bei der ersten Störung kaskadierend ausfallen.

Architektur-Entscheidungen dokumentieren

Nutzen Sie Architecture Decision Records (ADRs) — kurze Dokumente, die festhalten:

1. Kontext: Welches Problem lösen wir?
2. Entscheidung: Was haben wir entschieden?
3. Konsequenzen: Was folgt daraus (positiv und negativ)?

# ADR-001: Asynchrone Kommunikation für Bestellprozess

Kontext
Der Bestellprozess muss 5 nachgelagerte Systeme benachrichtigen.
Synchrone Aufrufe führen zu Timeouts bei Last.

Entscheidung
Wir verwenden Apache Kafka für die Event-basierte
Kommunikation im Bestellprozess.

Konsequenzen
+ Lose Kopplung, keine kaskadierenden Fehler
+ Natürliche Skalierbarkeit
- Eventual Consistency, kein sofortiges Feedback
- Zusätzliche Infrastruktur (Kafka Cluster)

Fazit

Gute Architektur entsteht nicht durch die Wahl des richtigen Frameworks, sondern durch bewusste Entscheidungen an den richtigen Stellen. Nehmen Sie sich Zeit für diese fünf Weichenstellungen — sie bestimmen den Erfolg Ihres Projekts mehr als jede Technologiewahl.

Bei CGS IT Solutions unterstützen wir Sie als Software-Architekten bei genau diesen Entscheidungen — pragmatisch, erfahrungsbasiert und technologieneutral.

Der Beitrag Software-Architektur: Die 5 Entscheidungen, die alles bestimmen erschien zuerst auf CGS IT Solutions GmbH.