Nothing unusual so far.

Now imagine entering a piece of SQL instead of an email address. What happens next depends on how the developer built the database query.

If the application inserts your input directly into its SQL statement, you might change what the database executes.

That’s the problem behind SQL Injection, often shortened to SQLi.

Although SQL Injection has been around for decades, developers still encounter it in modern web applications, REST APIs, backend services, and systems that use object-relational mapping frameworks.

The good news? Developers can prevent most SQL Injection vulnerabilities through a few reliable coding practices.

This guide explains how SQL Injection works, why it matters, and how to write safer Java database code.

What Is SQL Injection?

SQL Injection is a security vulnerability that allows an attacker to interfere with a database query by supplying specially crafted input.

The vulnerability appears when an application mixes untrusted data with SQL commands.

Consider a database query that retrieves a customer by email address:

SELECT id, email, full_name
FROM customers
WHERE email = 'alice@example.com';

This query looks for a specific customer.

But what if the application builds the query by joining SQL text with whatever the user enters?

An attacker may then influence the query’s logic instead of simply providing a value.

Depending on the application, database permissions, and query structure, SQL Injection can enable attackers to:

• Access sensitive customer information
• Read data that should remain private
• Modify or delete database records
• Bypass certain authentication checks
• Interfere with application business logic
• Disrupt database availability

Some database configurations can expose additional capabilities when the application connects with excessive privileges.

The OWASP Top 10:2025 includes SQL Injection within A05:2025 – Injection, a broader category covering injection vulnerabilities.

The important distinction is that SQL itself isn’t the problem.

The vulnerability comes from how an application handles SQL commands and external data.

How Does SQL Injection Work?

Let’s examine a small Java application.

Suppose an online store allows users to search for customer information by email address.

A developer might write the following JDBC code.

A Vulnerable Java Example

public Customer findByEmail(
        Connection connection,
        String email
) throws SQLException {

    String sql =
        "SELECT id, email, full_name " +
        "FROM customers WHERE email = '" +
        email + "'";

    try (Statement statement =
             connection.createStatement();
         ResultSet rs =
             statement.executeQuery(sql)) {

        if (rs.next()) {
            return new Customer(
                rs.getLong("id"),
                rs.getString("email"),
                rs.getString("full_name")
            );
        }

        return null;
    }
}

The code appears straightforward.

It creates a SQL query, executes it, and retrieves the first matching customer.

Unfortunately, one line introduces a serious security weakness:

"FROM customers WHERE email = '" + email + "'"

The application inserts the supplied email address directly into the SQL command.

That means the value becomes part of the SQL statement’s text.

The database cannot reliably distinguish the developer’s intended query structure from SQL syntax that arrived through the user input.

What Happens When an Attacker Changes the Input?

Instead of a normal email address, consider this input:

' OR '1'='1'

When the application concatenates it into the original query, the final SQL becomes:

SELECT id, email, full_name
FROM customers
WHERE email = '' OR '1'='1';

Look closely at the condition:

'1'='1'

This comparison always evaluates to true.

As a result, the database may return every row instead of looking for one customer.

The sample Java method reads only the first result, but the query itself no longer applies the intended email filter.

If other application logic treats that result as proof of identity or authorization, the consequences could become much more serious.

This example captures the central idea behind SQL Injection:

The attacker turns input data into executable SQL logic.

Why Is SQL Injection Dangerous?

SQL Injection can affect more than a single database query.

Its impact depends on the application’s architecture, the affected SQL statement, and the privileges assigned to the database connection.

Exposure of Sensitive Data

Applications often store customer details, addresses, order histories, and other valuable information.

A vulnerable query can expose data that users should never access.

Even when an attacker cannot download an entire database, accessing another customer’s records creates a security and privacy problem.

Unauthorized Data Modification

Some application accounts can create, update, or delete database records.

If an attacker exploits a suitable SQL Injection vulnerability through one of these accounts, the attacker may gain opportunities to modify business data.

For an online store, that might affect product information, customer records, or order management processes.

Application Disruption

A maliciously altered query may consume excessive database resources.

Expensive operations can reduce performance and interfere with legitimate requests.

Under certain conditions, this behavior can contribute to a denial-of-service incident.

Authentication and Authorization Risks

SQL Injection can sometimes interfere with authentication or authorization checks.

However, not every SQL Injection vulnerability gives an attacker the ability to log in as another user.

The actual outcome depends on how the application uses the query result and which permissions the database account holds.

Common Types of SQL Injection

Security professionals commonly classify SQL Injection techniques by how attackers retrieve information or observe the application’s behavior.

1. In-Band SQL Injection

In-band SQL Injection uses the same communication channel to influence the SQL query and observe its output.

Two common forms exist.

Error-Based SQL Injection

Attackers examine database error messages to learn about the underlying system.

Detailed error responses may reveal query structure, table names, or other technical information.

Union-Based SQL Injection

Attackers attempt to combine the results of different SQL queries through the UNION operator.

The technique requires compatible query structures and data types.

2. Blind SQL Injection

Some applications hide database errors and query output.

That doesn’t automatically make them immune to SQL Injection.

Attackers may still infer information by observing application behavior.

Boolean-Based Blind SQL Injection

This technique compares how an application responds to conditions that evaluate to true or false.

Time-Based Blind SQL Injection

This technique relies on differences in response times.

Since network latency and server load can introduce noise, timing observations require careful interpretation.

3. Out-of-Band SQL Injection

Out-of-band techniques attempt to use a separate communication channel to retrieve information.

These attacks depend on particular database capabilities, network access, and configuration choices.

Not every database environment supports the conditions they require.

4. Second-Order SQL Injection

Second-order SQL Injection often surprises developers.

An application first stores untrusted input in its database.

Later, another part of the application retrieves that stored value and inserts it into a new SQL query without proper parameter binding.

The vulnerability appears during the second operation rather than the original request.

This illustrates an important security principle: data doesn’t automatically become trustworthy because it came from your own database.

How to Prevent SQL Injection

The most effective approach starts with one rule:

Keep SQL commands separate from data values.

OWASP recommends parameterized queries as a primary defense.

Let’s examine what that means in practice.

1. Use Prepared Statements and Parameterized Queries

Java provides the PreparedStatement interface through JDBC.

Instead of embedding a value inside SQL text, we define the SQL statement and bind the value separately.

Here’s a safer version of our customer lookup.

public Customer findByEmail(
        Connection connection,
        String email
) throws SQLException {

    String sql = """
        SELECT id, email, full_name
        FROM customers
        WHERE email = ?
        """;

    try (PreparedStatement statement =
             connection.prepareStatement(sql)) {

        statement.setString(1, email);

        try (ResultSet rs =
                 statement.executeQuery()) {

            if (rs.next()) {
                return new Customer(
                    rs.getLong("id"),
                    rs.getString("email"),
                    rs.getString("full_name")
                );
            }

            return null;
        }
    }
}

Two details matter here.

First, the ? placeholder represents a data value.

Second, setString() binds the supplied email address to that placeholder.

The JDBC driver handles the value through the database parameter-binding mechanism.

Even if someone enters:

' OR '1'='1'

the database treats that input as a string value to search for rather than additional SQL logic.

Why Do Prepared Statements Work?

Prepared statements establish a boundary between the SQL statement’s structure and its data values.

The application defines the query.

The user supplies the values.

That difference prevents data-bound input from changing the query’s intended syntax.

It also handles legitimate values containing special characters, such as a customer’s name with an apostrophe.

One limitation matters, though: prepared statements protect the values you bind. They cannot protect SQL fragments that you still construct through unsafe concatenation.

2. Use Allow-Lists for Dynamic Query Structure

Parameterized queries work for data values, but they don’t replace SQL identifiers or keywords.

For example, a JDBC ? placeholder cannot represent a column name in an ORDER BY clause.

Suppose your online store allows customers to sort products by price or name.

Avoid this approach:

String sql =
    "SELECT id, name, price FROM products ORDER BY "
    + sortBy;

Here, the application inserts untrusted input into the SQL statement’s structure.

Instead, define which options the application supports.

public String buildProductQuery(
        String sortBy,
        String direction
) {
    String column = switch (sortBy) {
        case "name"  -> "name";
        case "price" -> "price";
        default -> throw new
            IllegalArgumentException(
                "Invalid sorting field"
            );
    };

    String order = switch (direction) {
        case "asc"  -> "ASC";
        case "desc" -> "DESC";
        default -> throw new
            IllegalArgumentException(
                "Invalid sorting direction"
            );
    };

    return """
        SELECT id, name, price
        FROM products
        ORDER BY %s %s
        """.formatted(column, order);
}

The application now controls the SQL identifiers and keywords.

Users can request only the choices the developer explicitly supports.

Continue using prepared statements for the query’s ordinary data values.

3. Validate Input According to Business Rules

Input validation helps applications reject unexpected values.

For example, an application can require a product identifier to contain a positive integer or limit the length of a search term.

Those checks improve reliability and reduce unnecessary processing.

However, input validation alone doesn’t prevent SQL Injection.

Blocking quotation marks or maintaining a blacklist of suspicious SQL keywords cannot reliably address every SQL dialect and query context.

Use validation for business rules and parameter binding for database query safety.

4. Apply the Principle of Least Privilege

Database accounts should have only the permissions their applications actually need.

For example, a service that reads product information shouldn’t require permission to modify every customer record.

A PostgreSQL administrator could restrict table permissions with statements such as:

REVOKE ALL ON TABLE products
FROM product_reader;

GRANT SELECT ON TABLE products
TO product_reader;

These statements control permissions on the specified table. A production security review must also consider role inheritance, schema permissions, and access to other database objects.

Least privilege doesn’t remove a SQL Injection vulnerability.

Instead, it reduces the potential damage if an attacker successfully exploits one.

For larger architectures, consider different database roles for services with different responsibilities.

A reporting service and an order-processing service rarely need identical database privileges.

5. Don’t Assume Your ORM Makes Every Query Safe

Developers often use Hibernate, JPA, or similar frameworks to avoid writing repetitive SQL code.

These frameworks support parameterized query APIs, but developers can still introduce vulnerabilities through unsafe query construction.

Consider this JPQL example:

String jpql =
    "SELECT u FROM User u WHERE u.email = '"
    + email + "'";

var query = entityManager.createQuery(
    jpql,
    User.class
);

The application still inserts untrusted input into the query text.

A better approach uses a named parameter.

var query = entityManager.createQuery(
    """
    SELECT u
    FROM User u
    WHERE u.email = :email
    """,
    User.class
);

query.setParameter("email", email);

List<User> users = query.getResultList();

Here, the ORM treats the email value as a parameter.

Review dynamically constructed JPQL, HQL, native SQL, and sorting expressions with the same attention you give to ordinary JDBC queries.

6. Review Stored Procedures Carefully

Stored procedures can help organize database logic.

However, they don’t automatically eliminate SQL Injection.

A procedure that constructs dynamic SQL by concatenating untrusted values can create the same vulnerability as application-level string concatenation.

Use bound arguments when calling procedures.

Inside the procedure, prefer static SQL or parameterized dynamic SQL.

When a procedure needs a dynamic identifier, restrict the selection to trusted, application-approved choices.

7. Handle Database Errors and Logs Safely

Database error messages help developers diagnose problems.

But detailed SQL errors can reveal useful information to attackers.

Production applications should avoid returning raw database exceptions to clients.

Keep technical error details in protected logs, and provide clients with appropriate generic error responses.

Make sure your logging strategy also protects sensitive information.

Passwords, authentication tokens, and private customer data shouldn’t appear in ordinary diagnostic logs.

How Can Developers Test for SQL Injection?

You should test only applications and environments you own or have explicit authorization to assess.

Start with code review and repeatable automated checks.

Review Query Construction

Look for places where the application builds SQL statements dynamically.

Pay particular attention to:

• String concatenation inside SQL queries
• Dynamic JDBC Statement execution
• Native SQL constructed through ORM frameworks
• Dynamic JPQL or HQL expressions
• Stored procedures that assemble SQL text
• User-controlled sorting fields and identifiers

The presence of Statement alone doesn’t prove a vulnerability. The risk arises when untrusted data can modify SQL syntax.

Combine SAST and DAST

Static Application Security Testing (SAST) tools inspect source code for potential vulnerabilities.

Dynamic Application Security Testing (DAST) tools examine a running application’s behavior.

Tools such as OWASP ZAP can support an authorized testing process.

Neither category guarantees complete coverage.

Use automated testing alongside code review and carefully designed regression tests.

Write a Java Regression Test

A simple JUnit 5 test can verify that your repository treats suspicious input as ordinary data.

@Test
void shouldNotInterpretInputAsSql()
        throws SQLException {

    String input = "' OR '1'='1";

    Customer customer =
        repository.findByEmail(
            connection,
            input
        );

    assertNull(customer);
}

For this test, use an isolated database with known records and no customer whose email equals the supplied test string.

You can strengthen the test by inserting a legitimate customer first and verifying that the suspicious input doesn’t return that record.

This doesn’t replace broader security testing.

It does, however, help prevent a previously corrected vulnerability from returning during a future code change.

A Real-World Example: Securing an E-Commerce Product Search

An e-commerce application exposes many database-driven operations.

Product searches, price filters, order histories, customer profiles, and administrative reports all deserve attention.

Let’s implement a simple product search using Java and JDBC.

The method accepts a keyword and a maximum price.

public List<Product> searchProducts(
        Connection connection,
        String keyword,
        BigDecimal maxPrice
) throws SQLException {

    String sql = """
        SELECT id, name, price
        FROM products
        WHERE LOWER(name) LIKE LOWER(?)
          AND price <= ?
        """;

    List<Product> products =
        new ArrayList<>();

    try (PreparedStatement statement =
             connection.prepareStatement(sql)) {

        statement.setString(
            1,
            "%" + keyword + "%"
        );

        statement.setBigDecimal(
            2,
            maxPrice
        );

        try (ResultSet rs =
                 statement.executeQuery()) {

            while (rs.next()) {
                products.add(
                    new Product(
                        rs.getLong("id"),
                        rs.getString("name"),
                        rs.getBigDecimal("price")
                    )
                );
            }
        }
    }

    return products;
}

This example binds both user-controlled values.

The first parameter searches for products containing the requested keyword.

The second parameter limits the maximum price.

Notice that the code adds % characters to the Java string before binding it.

That’s safe from SQL Injection because the application constructs a parameter value rather than adding SQL syntax to the query.

There is one additional detail worth understanding.

SQL LIKE treats % and _ as wildcard characters. If your application expects literal text matching, you should handle those characters according to your database’s escaping rules.

That’s a search-behavior concern rather than an SQL Injection vulnerability, but it demonstrates why secure code must also follow the application’s business requirements.

Frequently Asked Questions About SQL Injection

Is SQL Injection still a problem in modern applications?

Yes. Modern frameworks provide safer database APIs, but developers can still introduce SQL Injection vulnerabilities when they concatenate untrusted values into query text.

Does SQL Injection affect only login forms?

No. Search fields, filters, reports, API parameters, and other database-driven operations may expose vulnerable queries.

Can prepared statements completely prevent SQL Injection?

Correctly parameterized data values cannot change the SQL statement’s structure. However, developers can still create vulnerabilities by constructing other query fragments from untrusted input.

Does Hibernate prevent SQL Injection automatically?

No. Hibernate supports secure parameter binding, but unsafe dynamically constructed HQL, JPQL, or native SQL can introduce vulnerabilities.

Should I remove special characters from user input?

Not as a general SQL Injection defense. Legitimate values may contain apostrophes and other special characters. Use parameter binding instead of relying on character filtering.

Can a Web Application Firewall stop SQL Injection?

A WAF may detect or block some malicious requests, but it cannot guarantee protection and doesn’t fix the underlying code defect. Treat it as an additional security layer.

What’s the difference between SQL Injection and XSS?

SQL Injection targets the structure of database queries. Cross-Site Scripting (XSS) targets how browsers interpret untrusted content. Both involve trust boundaries, but they affect different execution contexts.

Final Thoughts: Make Safe Queries Your Default

SQL Injection becomes possible when an application allows external data to change the structure of a database query.

You don’t need an elaborate security system to address the core problem.

Start by writing parameterized queries. Use explicit allow-lists when users need to influence query structure. Limit database privileges and include security checks in your development workflow.

If you’re writing Java, make PreparedStatement your default choice for JDBC queries that include variable data.

If you’re using an ORM, learn how its parameter-binding APIs work and avoid unsafe dynamic query construction.

Most importantly, keep one principle in mind:

Your application defines the SQL. Your users provide the data.

That separation is the foundation of SQL Injection prevention.

References and Further Reading

1. OWASP — SQL Injection Prevention Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
2. OWASP — Top 10:2025, A05 Injection
   https://top10.owasp.org/2025/A05_2025-Injection/
3. OWASP — Web Security Testing Guide
   https://owasp.org/www-project-web-security-testing-guide/
4. Oracle — Using Prepared Statements
   https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html

SQL Injection: A Friendly Guide to Understanding the Threat yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Peki, kullanıcı adı alanına normal bir isim yerine SQL komutu yazarsanız ne olur?

Uygulama bu girdiyi doğrudan SQL sorgusuna ekliyorsa veritabanı beklediğinizden farklı bir komut çalıştırabilir. Böylece basit bir metin alanı, veritabanı güvenliğini tehdit eden bir noktaya dönüşür.

Bu güvenlik açığına SQL Injection (SQL enjeksiyonu) adını veriyoruz.

SQL Injection yalnızca eski web uygulamalarının sorunu değil. Modern Java uygulamaları, REST API’ler, mikroservisler ve ORM kullanan sistemler de hatalı sorgu oluşturduklarında aynı riskle karşılaşır.

Bu rehberde SQL Injection’ın nasıl çalıştığını, hangi hataların güvenlik açığı oluşturduğunu ve Java ile güvenli veritabanı sorgularını nasıl geliştirebileceğinizi inceleyeceğiz.

SQL Injection Nedir?

SQL Injection, saldırganın uygulamanın SQL sorgusuna kendi girdisi üzerinden müdahale etmesini sağlayan bir güvenlik açığıdır.

Sorunun temelinde SQL komutları ile kullanıcı verilerinin birbirine karışması yatar.

Bir uygulama kullanıcı girdisini SQL sorgusunun metnine doğrudan eklediğinde, saldırgan sorgunun mantığını değiştirebilir.

Bu durum saldırgana uygulamanın veritabanı izinleri ve sorgunun yapısına bağlı olarak şu fırsatları verebilir:

• Normalde erişemeyeceği verilere ulaşmak
• Kullanıcı hesapları ve müşteri bilgilerini okumak
• Yetkisiz veri değişiklikleri yapmak
• Kayıtları silmek veya bozmak
• Kimlik doğrulama kontrollerini aşmak
• Veritabanı hizmetinin çalışmasını olumsuz etkilemek

Bazı veritabanı özellikleri ve yüksek yetkili hesaplar, saldırının etkisini veritabanının dışına da taşıyabilir.

SQL Injection, OWASP Top 10:2025 listesindeki A05:2025 – Injection kategorisinin kapsamına girer.

Burada önemli nokta şu: SQL dili tek başına güvenlik açığı oluşturmaz. Açığı, uygulamanın güvenilmeyen verileri SQL sözdiziminin parçası hâline getirmesi oluşturur.

SQL Injection Nasıl Çalışır?

Bir e-ticaret uygulamasında kullanıcıların e-posta adresleri üzerinden hesap bilgilerini aradığımızı düşünelim.

Normal koşullarda uygulama şu sorguyu çalıştırır:

SELECT id, email, full_name
FROM customers
WHERE email = 'ali@example.com';

Veritabanı yalnızca ilgili e-posta adresini taşıyan kaydı döndürür.

Şimdi Java tarafında SQL sorgusunu nasıl oluşturduğumuza bakalım.

Güvensiz Java Kod Örneği

public Customer findByEmail(
        Connection connection,
        String email
) throws SQLException {

    String sql = "SELECT id, email, full_name " +
                 "FROM customers WHERE email = '" +
                 email + "'";

    try (Statement statement =
             connection.createStatement();
         ResultSet rs = statement.executeQuery(sql)) {

        if (rs.next()) {
            return new Customer(
                rs.getLong("id"),
                rs.getString("email"),
                rs.getString("full_name")
            );
        }

        return null;
    }
}

İlk bakışta kod oldukça basit. Geliştirici e-posta adresini SQL sorgusuna ekliyor ve sorguyu çalıştırıyor.

Ancak şu satır ciddi bir güvenlik problemi yaratıyor:

"FROM customers WHERE email = '" + email + "'"

Uygulama, email değişkeninin içeriğini SQL komutunun bir parçası hâline getiriyor.

Geliştirici burada SQL’in nerede bittiğini ve kullanıcı verisinin nerede başladığını veritabanına güvenilir şekilde anlatmıyor.

Saldırgan Sorguyu Nasıl Değiştirir?

Saldırganın e-posta alanına şu ifadeyi yazdığını düşünelim:

' OR '1'='1'

Uygulama bu ifadeyi sorguya doğrudan eklerse ortaya şu SQL çıkar:

SELECT id, email, full_name
FROM customers
WHERE email = '' OR '1'='1';

Sorgunun mantığı artık değişti.

'1'='1' ifadesi her zaman doğru sonuç verir. Dolayısıyla WHERE koşulu bütün satırlar için doğru olur.

Veritabanı sorgusu tek bir müşteri yerine birden fazla müşteriyi döndürebilir.

Örnekteki Java metodu yalnızca ilk kaydı okuyacak olsa da saldırgan arama sonucunun kapsamını değiştirmiş olur. Uygulamanın geri kalan mantığı bu davranışı hesap erişimi veya yetkilendirme için kullanıyorsa daha ciddi sorunlar ortaya çıkabilir.

Bu örnek, SQL Injection’ın temel mekanizmasını gösterir: Saldırgan veri göndermek yerine sorgunun mantığını değiştirir.

SQL Injection Neden Tehlikelidir?

Saldırının etkisini yalnızca sorgu sonucunda kaç kayıt gördüğümüzle ölçemeyiz.

Veritabanı kullanıcısının yetkileri, uygulamanın işlevleri ve verinin niteliği de sonuçları belirler.

Veri Gizliliğinin Kaybı

Bir uygulama müşteri adreslerini, e-posta bilgilerini veya finansal kayıtları saklıyor olabilir.

SQL Injection açığı, saldırganın bu verilere yetkisiz erişim elde etmesine yol açabilir.

Güvenlik açısından sorun yalnızca verinin dışarı çıkması değildir. Uygulamanın normalde göstermediği bilgilerin başka bir kullanıcıya ulaşması da gizlilik ihlalidir.

Veri Bütünlüğünün Bozulması

Yeterli veritabanı yetkisine sahip bir uygulama üzerinden saldırgan bazı kayıtları değiştirebilir veya silebilir.

Örneğin ürün fiyatları, sipariş durumları ve müşteri hesap bilgileri saldırgan için hedef oluşturabilir.

Bu tür değişiklikler yalnızca teknik hata yaratmaz. İş süreçlerini ve raporların doğruluğunu da etkiler.

Hizmet Kesintileri

Bazı SQL sorguları çok fazla işlemci, bellek veya disk kaynağı tüketebilir.

Saldırganın sorgu davranışını değiştirmesi, veritabanının performansını düşürebilir. Ağır durumlarda uygulama hizmet veremez hâle gelebilir.

Yetkilendirme Sorunları

SQL Injection, kimlik doğrulama ve yetkilendirme mekanizmalarını etkileyebilir.

Ancak her SQL Injection açığı otomatik olarak giriş ekranını aşma imkânı vermez.

Saldırganın hangi işlemleri gerçekleştirebileceğini sorgunun konumu, uygulama mantığı ve veritabanı yetkileri belirler.

SQL Injection Türleri

Güvenlik uzmanları SQL Injection saldırılarını çoğunlukla uygulamanın veritabanından nasıl yanıt aldığına göre sınıflandırır.

1. In-Band SQL Injection

Bu yöntemde saldırgan aynı iletişim kanalı üzerinden hem sorguyu etkiler hem de sonucu görür.

İki yaygın alt türü bulunur.

Error-Based SQL Injection

Saldırgan, veritabanının ürettiği hata mesajlarından teknik bilgi elde etmeye çalışır.

Hata mesajları bazen tablo isimleri, sütunlar veya SQL sözdizimi hakkında ipuçları verebilir.

Union-Based SQL Injection

Saldırgan, uygun koşullarda UNION operatörünü kullanarak farklı sorguların sonuçlarını birleştirmeye çalışır.

Bu yöntem belirli sorgu yapısı ve veri tipi uyumluluğu koşullarını gerektirir.

2. Blind SQL Injection

Bazı uygulamalar sorgu sonucunu veya veritabanı hatalarını doğrudan göstermez.

Bu durum SQL Injection riskini ortadan kaldırmaz.

Saldırgan, uygulamanın davranışındaki küçük farkları gözlemleyerek bilgi elde etmeye çalışabilir.

Boolean-Based Blind SQL Injection

Saldırgan doğru ve yanlış koşullara karşılık uygulamanın farklı tepkiler verip vermediğini inceler.

Time-Based Blind SQL Injection

Saldırgan veritabanının yanıt süresindeki farklılıklardan çıkarım yapmaya çalışır.

Ancak ağ gecikmeleri ve sistem yükü, zaman ölçümlerini yanıltabilir.

3. Out-of-Band SQL Injection

Bazı senaryolarda saldırgan, veritabanının farklı bir iletişim kanalı üzerinden dış sistemlerle etkileşim kurmasını hedefler.

Bu yaklaşım özel veritabanı özellikleri, yapılandırmalar ve ağ erişim koşulları gerektirir.

4. Second-Order SQL Injection

Bu türü özellikle gözden kaçırmak kolaydır.

Uygulama saldırganın girdisini önce veritabanına kaydeder. Daha sonra başka bir işlem bu veriyi okuyup güvensiz biçimde yeni bir SQL sorgusuna ekler.

Dolayısıyla güvenlik açığı ilk veri girişinde değil, verinin sonraki kullanımında ortaya çıkar.

Bu nedenle geliştirici yalnızca HTTP isteklerini değil, veritabanından, dosyalardan ve diğer servislerden gelen verileri de sorgu oluştururken güvenilmeyen girdi olarak ele almalıdır.

SQL Injection Nasıl Önlenir?

SQL Injection’a karşı en güçlü temel savunma, SQL komutlarının yapısını kullanıcı verilerinden ayrı tutmaktır.

OWASP, veri değerleri için parametreli sorguları temel savunma olarak önerir.

1. PreparedStatement ve Parametreli Sorgular Kullanın

Java JDBC API, PreparedStatement sınıfıyla parametreli sorgular oluşturmanıza imkân verir.

Önceki güvensiz örneği yeniden yazalım.

public Customer findByEmail(
        Connection connection,
        String email
) throws SQLException {

    String sql = """
        SELECT id, email, full_name
        FROM customers
        WHERE email = ?
        """;

    try (PreparedStatement statement =
             connection.prepareStatement(sql)) {

        statement.setString(1, email);

        try (ResultSet rs =
                 statement.executeQuery()) {

            if (rs.next()) {
                return new Customer(
                    rs.getLong("id"),
                    rs.getString("email"),
                    rs.getString("full_name")
                );
            }

            return null;
        }
    }
}

Burada iki önemli değişiklik yaptık.

İlk olarak kullanıcı girdisini SQL metnine eklemek yerine ? yer tutucusunu kullandık.

İkinci olarak setString() metoduyla parametre değerini sorguya bağladık.

JDBC sürücüsü, parametre bağlama mekanizması üzerinden SQL yapısıyla veri değerini ayrı ele alır.

Artık kullanıcı şu ifadeyi gönderse bile:

' OR '1'='1'

Veritabanı bunu sorgunun mantığını değiştiren bir SQL ifadesi olarak değil, email sütununda aranacak bir değer olarak değerlendirir.

PreparedStatement neden güvenlidir?

Çünkü SQL’in komut yapısı ile dışarıdan gelen veri arasında açık bir sınır kurar.

Tek başına kullanıcı girdisindeki özel karakterleri yasaklamamız gerekmez.

Örneğin O'Connor gibi tek tırnak içeren gerçek isimler de güvenli biçimde işlenebilir.

Ancak geliştirici SQL yapısını kullanıcı girdisiyle birleştirmeye devam ederse yalnızca sorgunun başka bir bölümünde PreparedStatement kullanması yeterli olmaz.

2. Dinamik SQL Yapıları İçin Allowlist Kullanın

Parametreli sorguların önemli bir sınırı bulunur.

? yer tutucusu tablo ismi, sütun ismi veya ASC ve DESC gibi SQL anahtar kelimeleri yerine geçmez.

Bir e-ticaret uygulamasında kullanıcılar ürünleri fiyat veya isim üzerinden sıralamak isteyebilir.

Şu yaklaşım güvenli değildir:

String sql =
    "SELECT id, name, price FROM products ORDER BY "
    + sortBy;

Çünkü uygulama dışarıdan gelen sortBy değerini doğrudan SQL yapısına ekler.

Bunun yerine izin verdiğimiz seçenekleri kodda tanımlayalım.

public String createProductQuery(
        String sortBy,
        String direction
) {
    String column = switch (sortBy) {
        case "price" -> "price";
        case "name"  -> "name";
        default -> throw new
            IllegalArgumentException(
                "Unsupported sort field"
            );
    };

    String order = switch (direction) {
        case "asc"  -> "ASC";
        case "desc" -> "DESC";
        default -> throw new
            IllegalArgumentException(
                "Unsupported direction"
            );
    };

    return """
        SELECT id, name, price
        FROM products
        ORDER BY %s %s
        """.formatted(column, order);
}

Burada kullanıcı yalnızca önceden tanımladığımız seçenekler arasından seçim yapabilir.

Uygulama SQL sorgusuna doğrudan kullanıcı girdisini değil, kendi belirlediği güvenilir SQL ifadelerini ekler.

Dinamik yapıları bu şekilde sınırlandırırken diğer veri değerleri için yine parametreli sorgular kullanmalıyız.

3. Girdi Doğrulama Uygulayın

Bir e-posta alanı e-posta biçimini, bir ürün kimliği ise beklenen veri tipini taşımalıdır.

Girdi doğrulama uygulamanın beklenmedik verilerle karşılaşmasını azaltır.

Ancak doğrulama SQL Injection’a karşı tek başına yeterli değildir.

Örneğin sadece tek tırnak karakterini engellemek güvenilir bir savunma oluşturmaz.

Farklı SQL sözdizimleri, karakter dönüşümleri ve sorgu bağlamları bu tür filtreleri yetersiz bırakabilir.

Doğru yaklaşım şudur:

• Girdi doğrulamayı iş kuralları için kullanın.
• Parametreli sorgularla SQL yapısını koruyun.
• Dinamik SQL parçalarını allowlist ile sınırlandırın.

4. Veritabanında En Az Ayrıcalık İlkesini Uygulayın

Bir uygulamanın yalnızca müşteri listesini okuması gerekiyorsa veritabanı hesabına tüm tabloları değiştirme yetkisi vermemelisiniz.

Örneğin PostgreSQL üzerinde yalnızca ürün okuma görevi olan bir hesap için gerekli erişimi sınırlayabilirsiniz.

REVOKE ALL ON TABLE products
FROM product_reader;

GRANT SELECT ON TABLE products
TO product_reader;

Bu örnek ilgili tablo üzerindeki yetkileri sınırlar. Gerçek sistemde rol üyeliklerini, şema erişimini, varsayılan yetkileri ve diğer tabloları da kontrol etmelisiniz.

En az ayrıcalık ilkesi SQL Injection açığını doğrudan engellemez.

Ancak saldırgan bir açık bulsa bile veritabanı hesabının yapabileceği işlemleri sınırlar.

5. ORM Kullanırken Dinamik Sorgulara Dikkat Edin

Hibernate veya JPA kullanmak SQL Injection riskini otomatik olarak ortadan kaldırmaz.

Örneğin şu JPQL oluşturma biçimi risklidir:

String jpql =
    "SELECT u FROM User u WHERE u.email = '"
    + email + "'";

var query = entityManager.createQuery(
    jpql,
    User.class
);

Güvenli yaklaşımda parametre bağlamalıyız:

var query = entityManager.createQuery(
    """
    SELECT u
    FROM User u
    WHERE u.email = :email
    """,
    User.class
);

query.setParameter("email", email);

List<User> users = query.getResultList();

ORM araçları geliştiricinin işini kolaylaştırır. Ancak sorgu oluşturma kararının güvenliği yine geliştiricinin sorumluluğundadır.

Özellikle native SQL, dinamik JPQL/HQL ve elle oluşturduğunuz sıralama koşullarını dikkatle incelemelisiniz.

6. Stored Procedure Kullanımını da Denetleyin

Stored procedure kullanımı SQL Injection riskini tek başına ortadan kaldırmaz.

Bir procedure içinde kullanıcı verilerini birleştirerek dinamik SQL oluşturursanız aynı güvenlik açığını yeniden yaratabilirsiniz.

Procedure çağrısında parametre bağlamak önemlidir. Ancak procedure içindeki dinamik sorgular için de aynı güvenlik kuralını uygulamalısınız.

Statik SQL tercih edin. Dinamik SQL gerektiğinde veri parametrelerini bağlayın ve SQL yapılarını güvenilir seçeneklerle sınırlandırın.

7. Hata Mesajlarını ve Kayıtları Kontrol Edin

Geliştirme sırasında ayrıntılı SQL hataları sorunları çözmenize yardımcı olur.

Ancak canlı ortamda ham veritabanı hatalarını istemciye göndermek gereksiz bilgi açığa çıkarabilir.

Uygulama, kullanıcıya genel bir hata yanıtı vermeli ve teknik ayrıntıları yetkili ekiplerin erişebileceği güvenli log sisteminde tutmalıdır.

Log kayıtlarına parola, erişim belirteci veya hassas kişisel veri eklemeyin.

Ayrıca veritabanı kullanıcısının izinlerini ve uygulamanın hata yönetimini düzenli olarak inceleyin.

SQL Injection Açıklarını Nasıl Test Edebilirsiniz?

SQL Injection kontrollerini yalnızca sahibi olduğunuz veya açıkça test izni aldığınız sistemlerde gerçekleştirin.

Güvenli bir geliştirme ortamında aşağıdaki yaklaşımı kullanabilirsiniz.

Kod İncelemesi

Öncelikle SQL sorgularını oluşturan kodu inceleyin.

Özellikle şu kalıplara dikkat edin:

• SQL metniyle kullanıcı girdisinin birleştirilmesi
• Statement ile dinamik sorgu çalıştırma
• Native SQL ve dinamik JPQL/HQL oluşturma
• Stored procedure içinde dinamik SQL kullanımı
• ORDER BY ve tablo isimleri gibi yapısal alanlarda kullanıcı girdisi kullanımı

Her Statement kullanımı otomatik olarak açık anlamına gelmez. Asıl risk, güvenilmeyen girdinin SQL komutunun yapısını değiştirebilmesidir.

Otomatik Güvenlik Testleri

Statik uygulama güvenliği testleri (SAST), kaynak kodda şüpheli sorgu oluşturma kalıplarını bulmanıza yardımcı olabilir.

Dinamik uygulama güvenliği testleri (DAST), çalışan uygulamanın girdilere verdiği tepkileri analiz eder.

OWASP ZAP ve uygun yapılandırılmış güvenlik test araçları, yetkili test süreçlerinde yardımcı olabilir.

Bir aracın herhangi bir bulgu üretmemesi uygulamanın kesinlikle güvenli olduğu anlamına gelmez.

Java ile Basit Bir Regresyon Testi

Parametreli sorgunun beklendiği gibi davrandığını birim veya entegrasyon testinde de kontrol edebilirsiniz.

Örneğin aşağıdaki JUnit 5 testi, depo katmanının şüpheli bir girdiyi geçerli müşteri kaydı gibi yorumlamamasını bekler.

@Test
void shouldTreatSqlPayloadAsPlainData()
        throws SQLException {

    String input = "' OR '1'='1";

    Customer result =
        repository.findByEmail(
            connection,
            input
        );

    assertNull(result);
}

Bu testi çalıştırırken izole test veritabanınızda ilgili girdiyi e-posta değeri olarak taşıyan bir kayıt bulunmadığından emin olun.

Testin gerçek değerini artırmak için veritabanını başlangıç verileriyle kurun, bilinen bir müşteri kaydı ekleyin ve sorgunun beklenmedik kayıt döndürmediğini doğrulayın.

Tek bir test bütün SQL Injection türlerini kapsamaz. Ancak daha önce düzelttiğiniz bir açığın tekrar ortaya çıkmasını yakalayabilir.

Bir E-Ticaret Uygulamasında SQL Injection Güvenliği

Bir e-ticaret sisteminin yalnızca giriş ekranını koruduğunu varsayalım.

Bu yeterli değildir.

Ürün arama, fiyat filtreleme, müşteri hesapları, sipariş geçmişi, kampanya sorguları ve yönetim paneli aynı güvenlik prensiplerine ihtiyaç duyar.

Örneğin ürün arama sorgusunu şöyle oluşturabiliriz:

public List<Product> searchProducts(
        Connection connection,
        String keyword,
        BigDecimal maxPrice
) throws SQLException {

    String sql = """
        SELECT id, name, price
        FROM products
        WHERE LOWER(name) LIKE LOWER(?)
          AND price <= ?
        """;

    List<Product> products =
        new ArrayList<>();

    try (PreparedStatement statement =
             connection.prepareStatement(sql)) {

        statement.setString(
            1,
            "%" + keyword + "%"
        );

        statement.setBigDecimal(
            2,
            maxPrice
        );

        try (ResultSet rs =
                 statement.executeQuery()) {

            while (rs.next()) {
                products.add(
                    new Product(
                        rs.getLong("id"),
                        rs.getString("name"),
                        rs.getBigDecimal("price")
                    )
                );
            }
        }
    }

    return products;
}

Bu örnekte iki farklı parametre bağladık.

İlk parametre ürün isminde arama yapıyor. İkinci parametre maksimum fiyatı belirliyor.

keyword değerini Java tarafında % karakterleriyle birleştiriyoruz. Ancak bu birleşim SQL sorgusunun yapısını değil, parametre değerini değiştiriyor.

Bu nedenle sorgu SQL Injection’a karşı güvenli bir sınır koruyor.

Burada küçük bir ayrıntı daha var: Kullanıcı % veya _ karakterlerini arama metnine eklerse LIKE operatörü bu karakterlere özel anlam yükleyebilir.

Bu davranış SQL Injection değildir. Ancak uygulama düz metin araması bekliyorsa geliştirici joker karakterleri ayrıca ele almalıdır.

Güvenli yazılım geliştirme yalnızca SQL Injection’ı durdurmakla bitmez. Uygulamanın iş kurallarını doğru uygulamasını da gerektirir.

SQL Injection Hakkında Sık Sorulan Sorular

SQL Injection sadece giriş ekranlarında mı ortaya çıkar?

Hayır. Arama alanları, filtreler, raporlama ekranları, API parametreleri ve veritabanına sorgu gönderen diğer işlemler SQL Injection riski taşıyabilir.

PreparedStatement SQL Injection’ı tamamen engeller mi?

PreparedStatement, doğru parametre bağlama kullanımıyla sorgunun veri değerlerinden kaynaklanan SQL Injection riskini önler. Ancak kullanıcı girdisini SQL yapısına başka bir noktada eklemek yeni bir açık oluşturabilir.

Hibernate veya JPA kullanırsam güvende olur muyum?

ORM araçları parametreli sorgu kullanımını kolaylaştırır. Ancak dinamik sorguları güvensiz biçimde oluşturursanız SQL Injection açığı yine ortaya çıkabilir.

SQL Injection ve XSS aynı şey mi?

Hayır. SQL Injection veritabanı sorgularının yapısını hedefler. Cross-Site Scripting (XSS) ise tarayıcının işlediği içerik üzerinden istemci tarafındaki güven sınırlarını hedefler.

SQL Injection önlemek için kullanıcı girdisindeki özel karakterleri engellemeli miyim?

Hayır. Genel bir özel karakter yasağı güvenilir çözüm sunmaz ve geçerli kullanıcı verilerini de reddedebilir. Parametreli sorgular, iş kurallarına uygun doğrulama ve allowlist yaklaşımı daha doğru bir savunma oluşturur.

Web Application Firewall (WAF) yeterli mi?

WAF bazı şüpheli istekleri engelleyebilir. Ancak uygulamanın güvensiz sorgu oluşturma hatasını düzeltmez. WAF’ı ek koruma katmanı olarak değerlendirin.

Sonuç: SQL Injection’a Karşı Güvenli Kodlama Alışkanlığı

SQL Injection, uygulamanın veri ile komut arasındaki sınırı kaybetmesiyle ortaya çıkar.

Geliştirici kullanıcı girdisini SQL sorgusuna doğrudan eklediğinde saldırgan sorgunun davranışını etkileyebilir.

Bu riski azaltmak için karmaşık güvenlik algoritmalarına ihtiyacımız yok. Öncelikle doğru sorgu oluşturma alışkanlığını benimsememiz gerekiyor.

Java uygulamalarında PreparedStatement kullanmak, dinamik SQL parçalarını allowlist ile sınırlandırmak, veritabanı hesaplarının yetkilerini azaltmak ve sorguları düzenli test etmek güçlü bir başlangıç sağlar.

En önemli kural oldukça basit:

SQL komutlarını uygulama belirlesin. Kullanıcılar yalnızca veri sağlasın.

Bu ayrımı koruduğunuzda SQL Injection saldırılarının temel giriş noktasını kapatmış olursunuz.

Kaynaklar

1. OWASP — SQL Injection Prevention Cheat Sheet
   https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
2. OWASP — Top 10:2025, A05 Injection
   https://top10.owasp.org/2025/A05_2025-Injection/
3. OWASP — Web Security Testing Guide
   https://owasp.org/www-project-web-security-testing-guide/
4. Oracle — JDBC PreparedStatement
   https://docs.oracle.com/javase/tutorial/jdbc/basics/prepared.html

SQL Injection Nedir? Saldırıyı Anlamak ve Önlemek İçin Pratik Rehber yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Markdrop brings that step into your browser. It is a Markdown to PDF and Word converter with an editable source panel, a live A4 preview, and support for images you select from your computer. You can move from a plain-text draft to a PDF or an editable `.docx` file without creating an account or uploading your document to a conversion server.

From a Markdown draft to a shareable document

Markdown is useful for keeping writing focused. A few characters create headings, lists, links, and tables, while the source stays easy to edit. When the next person needs a PDF attachment or a Word document, those same notes need a different form.

With Markdrop, you can open a `.md` or `.markdown` file, edit its source, and see a formatted document beside it. The preview uses an A4 layout with readable typography for headings, paragraphs, tables, quotations, and code blocks.

That makes it useful for everyday handoffs: a project proposal with a diagram, meeting notes with action items, documentation for a colleague, or a brief that needs another round of editing in Word.

How to convert Markdown with Markdrop

1. Bring in your file or start writing

Drag a Markdown file into the workspace, choose browse files, or type directly into the editor. Markdrop accepts Markdown files up to 10 MB.

You can also paste a copied file when your browser and operating system make it available through the clipboard. If the clipboard contains only a filename or a path, choose the file through the browser instead. Ordinary text can be pasted straight into the editor.

2. Add any local images

A Markdown image reference usually points to a separate file:

```markdown
![Project overview](images/overview.png)
```

The Markdown document contains the path `images/overview.png`, not the image itself. Selecting the document does not give your browser permission to read that image from your computer.

Use Add images to select it, or drop one Markdown file together with its images. Markdrop supports PNG, JPEG, and still WebP files and prepares them locally for the preview and both export formats.

3. Review the preview and document checks

Edit your Markdown on the left and review the document on the right. Headings, emphasis, lists, tables, and supported images update as you work.

The Document checks section calls out issues that could affect the result, such as a missing image or an ambiguous filename. Resolve those issues before exporting, or explicitly choose to include visible placeholders for unavailable images.

4. Download a PDF or Word document

Choose Export to PDF for a rendered document or Export to Word (.docx) for editable text with embedded images. Downloads use your document’s filename, which you can also edit in the workspace.

For example, `project-brief.md` becomes `project-brief.pdf` or `project-brief.docx`.

Local images, with clear path matching

Image folders often contain familiar filenames: `logo.png`, `screenshot.png`, or `diagram.webp`. Markdrop can match a unique filename automatically, but it also lets you enter the exact Markdown path for each selected image.

Suppose your document uses both of these references:

```markdown
![Primary logo](brand/logo.png)

![Footer logo](footer/logo.png)

```

Those paths may point to different images. Markdrop asks you to resolve the mapping instead of guessing which logo belongs in each position. Set the paths beside the selected images to `brand/logo.png` and `footer/logo.png`, and the preview updates accordingly.

Paths with spaces also work with standard Markdown syntax:

```markdown

![Workshop notes](<images/workshop photo.jpg>)

```

Matching is case-sensitive. A reference to `Photo.jpg` is different from one to `photo.jpg`, so the workspace makes path checks part of the conversion process.

Your document is processed on your device

File reading, Markdown parsing, image preparation, and document generation happen in the browser. Markdrop does not upload your document or selected images, and the application does not include analytics or persistent document storage.

It does need an internet connection to load its third-party libraries from CDNs. Those library requests do not include your document contents, but they mean Markdrop should not be described as a fully offline application.

Remote image URLs do not load automatically. To include an image from a website, save an appropriate local copy, select it through Add images, and update the Markdown reference. This also keeps document rendering from silently contacting image hosts.

Selected images are prepared as PNG files with the original image metadata removed. Their longest side is limited to 2,400 pixels for export, so keep your originals when full-resolution images matter.

Choose the output that suits the next step

Word is useful when the recipient needs to revise the document. Markdrop exports editable text, native lists and tables, and embedded images. Markdown image descriptions are also carried into the Word file.

PDF is useful for a rendered version of the document, with an important distinction: Markdrop’s PDF export uses page images. Its text is not selectable, and the resulting PDF is not tagged for accessibility. If searchable text or accessible publishing is a requirement, choose the Word output and use a suitable document workflow afterward.

The A4 preview is a continuous sheet. Page breaks, table widths, and typography can differ in the exported files, so review the result before sharing it. The browser’s Print option is also available, including as an alternative for documents that exceed the PDF renderer’s size limits.

A few details to check before you export

Markdrop supports up to 20 selected images, with a 10 MB limit per image and a 40 MB combined limit for both the original image collection and the prepared PNG collection. Large dimensions, damaged files, and unsupported formats produce explanatory messages. SVG, GIF, HEIC, TIFF, and animated PNG or WebP files need conversion to a supported still image first.

Some Markdown extensions also need attention. Mermaid diagrams and math code blocks remain source code; they are not rendered as diagrams or equations. You can include a prepared image when a visual result is needed. YAML front matter is treated as document content, while local file links and internal anchors remain plain text.

Your workspace lasts only for the current session. Reloading or closing the page clears the text and selected images, so keep your source files and export your work before leaving.

Give your next draft a finished form

Start with a meeting note, a project brief, or a page of documentation. Add its images, check the preview, and choose the format that fits the person receiving it.

Open Markdrop and convert your Markdown

Meet Markdrop: Convert Markdown to PDF and Word, with Local Images yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Örneğin bir e-ticaret uygulamasında sipariş oluşturma işlemini düşünelim. İlk sürümde kullanıcı sipariş verir, sistem ödemeyi alır ve e-posta gönderir. Bir süre sonra ürün ekibi yeni ödeme yöntemleri, farklı indirim kuralları, SMS bildirimleri ve kurumsal müşterilere özel işlemler ister.

Bu noktada geliştirici tek bir OrderService sınıfına sürekli yeni metotlar ekliyorsa basit bir değişiklik bile beklenmedik hatalara yol açabilir.

SOLID prensipleri tam olarak bu tür tasarım sorunlarıyla ilgilenir.

SOLID, nesne yönelimli yazılım tasarımında sorumlulukları ayırmayı, bağımlılıkları yönetmeyi ve değişikliklerin etkisini sınırlamayı hedefleyen beş temel prensibin baş harflerinden oluşur.

Bu makalede SOLID’in beş ilkesini gerçek Java örnekleriyle inceleyeceğiz. Her ilke için önce problemli yaklaşımı görecek, ardından kodu yeniden düzenleyeceğiz. Ayrıca Java 17 ve Java 21 özelliklerinin bu prensiplerle nasıl ilişkilendiğini ve gereksiz soyutlamalardan nasıl kaçınabileceğimizi ele alacağız.

SOLID Prensipleri Nedir?

SOLID kavramı, Robert C. Martin’in yaygınlaştırdığı beş nesne yönelimli tasarım prensibini bir araya getirir. Michael Feathers bu prensiplerin baş harflerini SOLID kısaltması altında topladı.

Bu ilkeler Java’ya özel değildir. C#, Kotlin, C++ ve nesne yönelimli başka dillerde de aynı tasarım problemleriyle karşılaşırız.

Prensipleri birbirinden bağımsız kurallar gibi düşünmek doğru olmaz.

Örneğin Dependency Inversion uyguladığınızda çoğu zaman Interface Segregation ilkesiyle de karşılaşırsınız. Strategy tasarım desenini kullanırken Open/Closed Principle önem kazanır. Sınıfların sorumluluklarını ayırdığınızda ise test yazmak kolaylaşır.

Bununla birlikte SOLID’e uyan bir tasarımın otomatik olarak iyi tasarım olacağını söyleyemeyiz. Ekibin deneyimi, uygulamanın büyüklüğü ve iş gereksinimlerinin değişme sıklığı da mimari kararları etkiler.

SOLID Prensipleri Neden Önemlidir?

Yazılım geliştirme sürecinde en yüksek maliyet her zaman ilk kodu yazmak değildir. Mevcut kodun nasıl çalıştığını anlamak, bir değişikliğin etkisini belirlemek ve yeni davranışı güvenli biçimde eklemek de zaman alır.

SOLID bu maliyetleri azaltmaya yardımcı olur.

Değişikliklerin Etkisini Sınırlar

Bir ödeme yöntemi eklemek için stok, bildirim ve raporlama kodlarını değiştirmek zorunda kalmamalısınız.

Test Yazmayı Kolaylaştırır

Bir sınıf ihtiyaç duyduğu servisleri dışarıdan alıyorsa test sırasında gerçek veritabanı veya ödeme sistemi yerine kontrollü test nesneleri kullanabilirsiniz.

Bağımlılıkları Daha Açık Hâle Getirir

Constructor üzerinden alınan bağımlılıklar, sınıfın hangi bileşenlere ihtiyaç duyduğunu doğrudan gösterir.

Kodun Okunabilirliğini Artırabilir

Her sınıf belirli bir sorumluluğa odaklandığında geliştirici davranışın nerede bulunduğunu daha kolay bulur.

Ancak aşırı soyutlama tam tersine etki edebilir. Her işlem için ayrı interface, factory, manager ve helper sınıfları oluşturmak kodun anlaşılmasını zorlaştırabilir.

Önemli olan sınıf sayısını artırmak değil, değişikliklerin maliyetini düşürmektir.

1. Single Responsibility Principle (SRP)

Single Responsibility Principle, Türkçede Tek Sorumluluk Prensibi olarak bilinir.

Bu ilkeyi genellikle “Bir sınıf yalnızca tek bir iş yapmalı” şeklinde duyarız. Ancak bu açıklama eksik kalır.

SRP’nin daha anlamlı yorumu şudur:

Bir modülün değişmesi için tek bir temel neden bulunmalıdır.

Buradaki değişiklik nedenini, modülün hizmet ettiği iş sorumluluğu veya ilgili paydaşın beklentisi üzerinden değerlendirebiliriz.

Bir sınıfta birden fazla metot bulunması tek başına SRP ihlali değildir.

SRP İhlali: Her Şeyi Yöneten OrderService

Bir sipariş servisi yazdığımızı düşünelim.

import java.math.BigDecimal;

public class OrderService {

    public void createOrder(String customerEmail,
                            BigDecimal amount) {

        // Sipariş kaydını oluştur.
        System.out.println("Order created");

        // Ödemeyi al.
        System.out.println("Payment: " + amount);

        // E-posta gönder.
        System.out.println("Email: " + customerEmail);

        // Rapor oluştur.
        System.out.println("Report updated");
    }
}

Bu örnekte OrderService dört farklı sorumluluk taşıyor.

Sipariş yönetimi ekibi sipariş kurallarını değiştirebilir. Finans ekibi ödeme akışına yeni kontroller ekleyebilir. Bildirim ekibi SMS desteği isteyebilir. Raporlama ekibi ise yeni bir analitik servisine geçebilir.

Bütün bu değişiklikler aynı sınıfı etkiliyor.

Kod başlangıçta küçük görünse bile gerçek servislerle entegrasyon kurduğumuzda sınıf hızla büyür.

SRP’ye Uygun Tasarım

Önce sipariş verisini tanımlayalım.

import java.math.BigDecimal;
import java.util.Objects;

public record Order(
        String id,
        String customerEmail,
        BigDecimal amount) {

    public Order {
        Objects.requireNonNull(id);
        Objects.requireNonNull(customerEmail);
        Objects.requireNonNull(amount);

        if (amount.signum() < 0) {
            throw new IllegalArgumentException(
                    "Sipariş tutarı negatif olamaz"
            );
        }
    }
}

Java 17 ile kullanabileceğimiz record, veri modelinin tekrar eden kodunu azaltır.

Ardından sorumlulukları ayıralım.

interface OrderRepository {
    void save(Order order);
}

interface PaymentProcessor {
    void charge(Order order);
}

interface OrderNotifier {
    void notifyCustomer(Order order);
}

Şimdi iş akışını koordine eden servisi oluşturalım.

public final class OrderService {

    private final OrderRepository repository;
    private final PaymentProcessor paymentProcessor;
    private final OrderNotifier notifier;

    public OrderService(
            OrderRepository repository,
            PaymentProcessor paymentProcessor,
            OrderNotifier notifier) {

        this.repository = repository;
        this.paymentProcessor = paymentProcessor;
        this.notifier = notifier;
    }

    public void createOrder(Order order) {
        repository.save(order);
        paymentProcessor.charge(order);
        notifier.notifyCustomer(order);
    }
}

OrderService artık sipariş oluşturma akışını koordine eder. Veritabanına nasıl yazacağımızı, ödemeyi hangi sağlayıcıyla alacağımızı veya müşteriye hangi kanaldan ulaşacağımızı bilmez.

Burada önemli bir ayrıntı var: OrderService üç ayrı bileşeni çağırdığı için SRP’yi ihlal etmiş sayılmaz. Servisin temel sorumluluğu sipariş oluşturma sürecini koordine etmektir.

Gerçek Projede Neye Dikkat Etmeliyiz?

Bu kod sorumluluk ayrımını gösterir, ancak üretim ortamına hazır bir sipariş akışı değildir.

Örneğin veritabanına sipariş kaydettikten sonra ödeme başarısız olursa ne olacak? Ödeme başarılı olurken bildirim servisi hata verirse işlemi geri alacak mıyız?

Gerçek projede sipariş durumlarını, ödeme idempotency anahtarlarını ve hata sonrası telafi işlemlerini ayrıca tasarlamalıyız.

SRP bu kararların yerine geçmez. Yalnızca ilgili sorumlulukları doğru bileşenlerde tutmamıza yardımcı olur.

SRP ne zaman önem kazanır? Bir sınıfın farklı iş ekiplerinden gelen değişiklikler nedeniyle sık sık güncelleme gerektirdiği durumlarda SRP’yi yeniden değerlendirin.

2. Open/Closed Principle (OCP)

Open/Closed Principle, Açık/Kapalı Prensibi olarak bilinir.

Bertrand Meyer’in ortaya koyduğu yaklaşım, yazılım bileşenlerinin genişlemeye açık, mevcut davranışı değiştirmeye ise mümkün olduğunca kapalı olmasını hedefler.

Buradaki amaç hiçbir zaman mevcut kodu değiştirmemek değildir.

Amaç, yeni bir davranış eklerken mevcut ve doğruluğunu testlerle desteklediğimiz kod üzerinde gereksiz değişiklik yapmamaktır.

OCP İhlali: İndirim Hesaplama

E-ticaret uygulamamızda standart, premium ve kurumsal müşteriler için farklı indirim oranları bulunsun.

import java.math.BigDecimal;

public class DiscountService {

    public BigDecimal calculate(
            BigDecimal amount,
            String customerType) {

        if ("STANDARD".equals(customerType)) {
            return BigDecimal.ZERO;
        }

        if ("PREMIUM".equals(customerType)) {
            return amount.multiply(
                    new BigDecimal("0.10")
            );
        }

        if ("CORPORATE".equals(customerType)) {
            return amount.multiply(
                    new BigDecimal("0.20")
            );
        }

        throw new IllegalArgumentException(
                "Unknown customer type"
        );
    }
}

Yeni bir müşteri tipi eklediğimizde DiscountService kodunu değiştirmek zorundayız.

Üstelik her yeni koşul, mevcut davranışları yanlışlıkla etkileme ihtimalini artırır.

OCP Çözümü: Strategy Pattern

İndirim algoritmasını bir arayüzle temsil edelim.

import java.math.BigDecimal;

@FunctionalInterface
public interface DiscountPolicy {

    BigDecimal calculate(BigDecimal amount);
}

Premium indirim politikası:

public final class PremiumDiscount
        implements DiscountPolicy {

    private static final BigDecimal RATE =
            new BigDecimal("0.10");

    @Override
    public BigDecimal calculate(BigDecimal amount) {
        return amount.multiply(RATE);
    }
}

Kurumsal müşteri politikası:

public final class CorporateDiscount
        implements DiscountPolicy {

    private static final BigDecimal RATE =
            new BigDecimal("0.20");

    @Override
    public BigDecimal calculate(BigDecimal amount) {
        return amount.multiply(RATE);
    }
}

Şimdi indirim servisini düzenleyelim.

import java.math.BigDecimal;
import java.util.Objects;

public final class DiscountService {

    private final DiscountPolicy policy;

    public DiscountService(DiscountPolicy policy) {
        this.policy = Objects.requireNonNull(policy);
    }

    public BigDecimal calculateDiscount(
            BigDecimal amount) {

        Objects.requireNonNull(amount);

        if (amount.signum() < 0) {
            throw new IllegalArgumentException(
                    "Tutar negatif olamaz"
            );
        }

        BigDecimal discount = policy.calculate(amount);

        if (discount == null
                || discount.signum() < 0
                || discount.compareTo(amount) > 0) {

            throw new IllegalArgumentException(
                    "Geçersiz indirim tutarı"
            );
        }

        return discount;
    }
}

Kullanım:

DiscountService service =
        new DiscountService(
                new PremiumDiscount()
        );

BigDecimal discount = service.calculateDiscount(
        new BigDecimal("1000.00")
);

System.out.println(discount); // 100.0000

Artık yeni bir kampanya için farklı bir DiscountPolicy uygulaması yazabiliriz.

DiscountService ise aynı sözleşme üzerinden çalışmaya devam eder.

Java Lambda ile Daha Kısa Bir Çözüm

DiscountPolicy fonksiyonel bir arayüz olduğu için Java lambda ifadelerini kullanabiliriz.

DiscountPolicy seasonalDiscount =
        amount -> amount.multiply(
                new BigDecimal("0.15")
        );

DiscountService service =
        new DiscountService(seasonalDiscount);

Bu yaklaşım küçük, durum tutmayan hesaplamalar için yeterli olabilir.

Ancak kampanya yönetimi farklı veritabanı sorguları, koşullar veya harici servisler gerektiriyorsa ayrı bir sınıf daha anlamlıdır.

OCP’nin Sınırları

Strategy kullanmak yeni bir algoritmanın sistem tarafından otomatik olarak keşfedileceği anlamına gelmez.

Örneğin stratejileri seçen bir factory veya registry varsa yeni davranışı oraya tanıtmanız gerekebilir.

Ayrıca her yeni iş kuralı için interface oluşturmak doğru değildir. Değişim ihtiyacını destekleyen gerçek bir nedeniniz olmalı.

OCP ne zaman önem kazanır? Yeni varyasyonlar aynı kod bloğunda sürekli yeni koşullar oluşturuyorsa genişletilebilir bir davranış modeli değerlendirin.

3. Liskov Substitution Principle (LSP)

Liskov Substitution Principle, Barbara Liskov’un alt türler ve davranışsal sözleşmeler üzerine geliştirdiği yaklaşıma dayanır.

İlkenin temel düşüncesi şudur:

Bir alt tür, üst türün beklentilerini bozmadan onun yerine kullanılabilmelidir.

Burada yalnızca Java derleyicisinin tür uyumluluğunu kontrol etmesi yeterli değildir.

Metotların ön koşulları, son koşulları, hata davranışları ve nesnenin koruması gereken kurallar da önem taşır.

LSP İhlali: Bütün Ödemeler İptal Edilebilir mi?

Bir ödeme sisteminin hem kredi kartı ödemelerini hem de belirli hediye kartı ödemelerini desteklediğini düşünelim.

İlk tasarımda bütün ödeme yöntemleri için aynı arayüzü kullanalım.

import java.math.BigDecimal;

interface PaymentMethod {

    void pay(BigDecimal amount);

    void refund(BigDecimal amount);
}

Kredi kartı uygulaması:

class CreditCardPayment implements PaymentMethod {

    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Card payment");
    }

    @Override
    public void refund(BigDecimal amount) {
        System.out.println("Card refund");
    }
}

Belirli bir hediye kartı ürününün iadeyi desteklemediğini varsayalım.

class GiftCardPayment implements PaymentMethod {

    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Gift card payment");
    }

    @Override
    public void refund(BigDecimal amount) {
        throw new UnsupportedOperationException(
                "Refund is not supported"
        );
    }
}

GiftCardPayment, Java tür sistemi açısından geçerli bir PaymentMethod uygulamasıdır.

Ancak arayüzün sözleşmesi bütün ödeme yöntemlerinin iade yapabildiğini vaat ediyorsa bu sınıf beklentiyi karşılamaz.

İstemci güvenle refund() çağıracağını düşünürken çalışma zamanında hata alır.

Bu örnekte hata, somut türün üst tür sözleşmesini yerine getirememesidir.

LSP’ye Uygun Arayüz Tasarımı

Bütün ödeme yöntemlerinin ödeme yapabildiğini, ancak yalnızca belirli yöntemlerin iade desteklediğini açık biçimde modelleyelim.

import java.math.BigDecimal;

interface PaymentMethod {
    void pay(BigDecimal amount);
}

interface RefundablePayment extends PaymentMethod {
    void refund(BigDecimal amount);
}

Kredi kartı:

final class CreditCardPayment
        implements RefundablePayment {

    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Card payment");
    }

    @Override
    public void refund(BigDecimal amount) {
        System.out.println("Card refund");
    }
}

Hediye kartı:

final class GiftCardPayment
        implements PaymentMethod {

    @Override
    public void pay(BigDecimal amount) {
        System.out.println("Gift card payment");
    }
}

İade servisi yalnızca iade yeteneğine sahip ödeme türleriyle çalışsın.

import java.math.BigDecimal;
import java.util.Objects;

final class RefundService {

    private final RefundablePayment payment;

    RefundService(RefundablePayment payment) {
        this.payment = Objects.requireNonNull(payment);
    }

    void refund(BigDecimal amount) {
        payment.refund(amount);
    }
}

Bu tasarım, bütün ödeme yöntemlerine sahip olmadıkları bir davranışı zorla eklemez.

Ayrıca derleyici, iade yeteneği olmayan bir PaymentMethod nesnesini doğrudan RefundService constructor’ına vermemize izin vermez.

LSP Yalnızca Exception Meselesi Değildir

Bir alt tür metot imzasını koruduğu hâlde farklı semantik davranış gösterebilir.

Örneğin:

• Üst tür negatif olmayan tutarlar kabul ederken alt tür yalnızca belirli bir tutarın üzerindeki işlemleri kabul edebilir.
• Üst tür başarılı işlem sonrasında kesin kayıt oluşturacağını vaat ederken alt tür sessizce işlemi atlayabilir.
• Üst tür belirli bir hata sözleşmesi sunarken alt tür ilgisiz bir istisna fırlatabilir.

Bu durumlarda Java’nın derleme zamanı kontrolleri her davranışsal uyumsuzluğu yakalayamaz.

Bu yüzden LSP’yi test ederken yalnızca metotların varlığını değil, sözleşmenin korunduğunu da doğrulamalıyız.

LSP ne zaman önem kazanır? Kalıtım veya arayüz polimorfizmi kullanan kodlarda somut uygulamaların istemci beklentilerini değiştirdiğini fark ediyorsanız LSP’yi inceleyin.

4. Interface Segregation Principle (ISP)

Interface Segregation Principle, Arayüz Ayrımı Prensibi olarak bilinir.

Bu ilke, istemcilerin ihtiyaç duymadıkları metotlara bağımlı hâle gelmemesini önerir.

Bir arayüz çok sayıda sorumluluk içerdiğinde onu uygulayan sınıflar gereksiz metotlar taşımak zorunda kalabilir.

ISP İhlali: Büyük Bir Raporlama Arayüzü

E-ticaret uygulamamız için rapor hazırlayan bir servis geliştirdiğimizi düşünelim.

interface ReportService {

    void generatePdf();

    void generateExcel();

    void sendEmail();

    void uploadToCloud();
}

Bir PDF raporlama servisi yalnızca PDF üretmek isteyebilir. Ancak arayüz bütün metotları uygulamasını zorunlu kılar.

class PdfReportService implements ReportService {

    @Override
    public void generatePdf() {
        System.out.println("PDF generated");
    }

    @Override
    public void generateExcel() {
        throw new UnsupportedOperationException();
    }

    @Override
    public void sendEmail() {
        throw new UnsupportedOperationException();
    }

    @Override
    public void uploadToCloud() {
        throw new UnsupportedOperationException();
    }
}

Bu tasarımda arayüz farklı yetenekleri gereksiz biçimde tek sözleşmede toplar.

ISP Çözümü: Küçük ve Odaklı Arayüzler

Rapor üretme işlemini veri formatı üzerinden ayıralım.

interface PdfGenerator {
    byte[] generatePdf();
}

interface ExcelGenerator {
    byte[] generateExcel();
}

Dağıtım yeteneklerini de ayrı tanımlayalım.

interface EmailSender {
    void send(String recipient, byte[] content);
}

interface CloudUploader {
    void upload(String key, byte[] content);
}

Artık PDF üreten bir servis yalnızca ihtiyacı olan sözleşmeyi uygulayabilir.

import java.nio.charset.StandardCharsets;

final class PdfReportGenerator implements PdfGenerator {

    @Override
    public byte[] generatePdf() {
        // Örnek veri: gerçek PDF üretimi değildir.
        return "PDF example"
                .getBytes(StandardCharsets.UTF_8);
    }
}

PDF oluşturma ve e-posta gönderme işlemlerini birleştiren servis ise her iki bağımlılığı dışarıdan alabilir.

import java.util.Objects;

final class ReportDeliveryService {

    private final PdfGenerator generator;
    private final EmailSender emailSender;

    ReportDeliveryService(
            PdfGenerator generator,
            EmailSender emailSender) {

        this.generator = Objects.requireNonNull(generator);
        this.emailSender = Objects.requireNonNull(emailSender);
    }

    void deliver(String recipient) {
        byte[] report = generator.generatePdf();
        emailSender.send(recipient, report);
    }
}

Bu tasarımda PDF üreticisini Excel üretmeye zorlamıyoruz. E-posta gönderme yeteneğini de rapor oluşturma sorumluluğuyla karıştırmıyoruz.

Her Metot İçin Ayrı Arayüz Açmalı mıyız?

Hayır.

ISP’nin amacı arayüzleri olabildiğince küçültmek değildir.

Birbiriyle anlamlı ilişki taşıyan metotlar aynı sözleşmede bulunabilir. Örneğin dosya okuma işlemlerini ele alan bir arayüzün read() ve close() davranışlarını birlikte sunması makul olabilir.

Asıl soru, arayüzü kullanan istemcilerin hangi yeteneklere ihtiyaç duyduğudur.

ISP ne zaman önem kazanır? Bir sınıf arayüz metotlarının büyük kısmına ihtiyaç duymuyorsa veya sık sık UnsupportedOperationException yazıyorsanız arayüzü yeniden tasarlayın.

5. Dependency Inversion Principle (DIP)

Dependency Inversion Principle, Bağımlılıkların Tersine Çevrilmesi Prensibi olarak bilinir.

Bu ilkeye göre üst seviye iş kuralları, alt seviye altyapı ayrıntılarına doğrudan bağımlı olmamalıdır.

Her iki taraf da uygun soyutlamalara dayanmalıdır.

Ayrıca soyutlamalar altyapı ayrıntılarına değil, ayrıntılar soyutlamaların sunduğu sözleşmelere uyum sağlamalıdır.

DIP İhlali: OrderService ve Veritabanı Bağımlılığı

Bir sipariş servisi doğrudan Oracle veritabanına erişen sınıfı oluşturuyor olsun.

class OracleOrderRepository {

    void save(Order order) {
        System.out.println("Saving to Oracle");
    }
}

Sipariş servisi:

class OrderService {

    private final OracleOrderRepository repository =
            new OracleOrderRepository();

    void createOrder(Order order) {
        repository.save(order);
    }
}

Bu yaklaşımda üst seviye iş akışı doğrudan belirli bir veritabanı bileşenine bağımlıdır.

Test ortamında farklı bir repository kullanmak istediğimizde OrderService koduna müdahale etmemiz gerekebilir.

Ayrıca bu somut bağımlılık, sipariş iş kuralları ile kalıcılık teknolojisi arasında gereksiz bağ oluşturur.

DIP Çözümü: Repository Soyutlaması

Sipariş yönetiminin ihtiyaç duyduğu sözleşmeyi tanımlayalım.

interface OrderRepository {

    void save(Order order);
}

Oracle adaptörü:

final class OracleOrderRepository
        implements OrderRepository {

    @Override
    public void save(Order order) {
        System.out.println(
                "Saving order to Oracle: " + order.id()
        );
    }
}

Sipariş servisi:

import java.util.Objects;

final class OrderService {

    private final OrderRepository repository;

    OrderService(OrderRepository repository) {
        this.repository = Objects.requireNonNull(repository);
    }

    void createOrder(Order order) {
        repository.save(order);
    }
}

Artık bağımlılığı uygulamayı başlatan kod üzerinden verebiliriz.

OrderRepository repository =
        new OracleOrderRepository();

OrderService service =
        new OrderService(repository);

Bu örnekte OrderService, Oracle’a özgü bir sınıfa bağımlı değildir.

Veritabanı erişim teknolojisini değiştirmek istediğimizde aynı OrderRepository sözleşmesine uygun başka bir implementasyon geliştirebiliriz.

DIP ile Dependency Injection Aynı Şey mi?

Hayır.

DIP bir tasarım prensibidir.

Dependency Injection ise nesnenin ihtiyaç duyduğu bağımlılıkları dışarıdan verme tekniğidir.

Constructor Injection kullanmak, DIP’yi uygulamayı kolaylaştırır. Ancak her constructor parametresi otomatik olarak doğru soyutlama anlamına gelmez.

Örneğin OrderService constructor üzerinden doğrudan OracleOrderRepository alıyorsa bağımlılığı dışarıdan veriyor olsak bile iş katmanını somut altyapı türüne bağlamaya devam ederiz.

Spring Boot ile DIP

Spring Framework, constructor injection yaklaşımını destekler.

@Service
public class OrderService {

    private final OrderRepository repository;

    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }

    public void createOrder(Order order) {
        repository.save(order);
    }
}

Bu örnekte @Service, Spring Framework’e ait bir annotation’dır. Projenin ilgili Spring bağımlılıklarını eklemesi gerekir.

Spring, uygun OrderRepository bean’ini uygulama bağlamından çözebilir. Birden fazla uygun bean bulunduğunda ise seçim için ek yapılandırma gerekebilir.

DIP’nin temel değeri Spring’in otomatik nesne oluşturması değildir. İş kurallarının altyapı ayrıntılarından bağımsız çalışabilmesidir.

DIP ne zaman önem kazanır? İş mantığınız doğrudan veritabanı sürücüsüne, HTTP istemcisine, mesaj aracısına veya üçüncü taraf SDK’ya bağımlıysa DIP’yi değerlendirin.

SOLID ve Java 17/21 Özellikleri

SOLID prensipleri Java’nın son sürümleriyle ortaya çıkmadı. Buna rağmen modern dil özellikleri bu prensipleri uygularken daha az kod yazmamıza yardımcı olabilir.

Record ile Veri Modellerini Sadeleştirmek

Java 17’de record, DTO ve değer taşıyan modeller için kullanışlıdır.

import java.math.BigDecimal;
import java.util.Objects;

public record Product(
        String id,
        String name,
        BigDecimal price) {

    public Product {
        Objects.requireNonNull(id);
        Objects.requireNonNull(name);
        Objects.requireNonNull(price);

        if (price.signum() < 0) {
            throw new IllegalArgumentException(
                    "Ürün fiyatı negatif olamaz"
            );
        }
    }
}

Bu örnekte derleyici constructor, accessor, equals(), hashCode() ve toString() gibi temel davranışları yönetir.

Record kullanmak tek başına SRP garantisi vermez. Ancak veri taşıma sorumluluğu bulunan modellerde gereksiz altyapı kodunu azaltır.

Sealed Interface ile Kapalı Tür Aileleri

Java 17 ile kalıcı hâle gelen sealed türleri, bir arayüzü hangi sınıfların uygulayabileceğini sınırlar.

sealed interface PaymentResult
        permits PaymentSuccess, PaymentFailure {
}

record PaymentSuccess(String transactionId)
        implements PaymentResult {
}

record PaymentFailure(String reason)
        implements PaymentResult {
}

Bu model, ödeme sonucunun iki temel varyasyonunu açıkça tanımlar.

Java 21 ile pattern matching for switch özelliğini kullanarak sonuçları işleyebiliriz.

final class PaymentResultHandler {

    static String describe(PaymentResult result) {

        return switch (result) {
            case PaymentSuccess success ->
                    "Payment OK: " + success.transactionId();

            case PaymentFailure failure ->
                    "Payment failed: " + failure.reason();
        };
    }
}

Derleyici kapalı tür ailesinin bütün üyelerini ele alıp almadığımızı kontrol edebilir.

Burada OCP açısından önemli bir tasarım tercihi bulunur.

Kapalı bir tür ailesi tanımladığımızda yeni bir ödeme sonucu türü eklemek mevcut switch ifadelerinin güncellenmesini gerektirebilir.

Dolayısıyla sealed interface, her durumda yeni davranışlara sınırsız genişletilebilirlik sunmaz.

Bu özellik, özellikle tür ailesini bilinçli olarak sınırlamak istediğimiz durumlarda değer kazanır.

Java 21 Her SOLID Problemini Çözmez

Modern Java, bazı teknik ayrıntıları azaltır. Ancak hangi sorumluluğun hangi bileşende bulunması gerektiğine derleyici karar vermez.

Record, yanlış sınıf sorumluluklarını düzeltmez.

Sealed interface, hatalı bir domain sözleşmesini kendiliğinden iyileştirmez.

Pattern matching ise bağımlılık yönünü otomatik olarak doğru hâle getirmez.

Dil özelliklerini mimari tasarımın yerine değil, tasarım kararlarını uygularken kullanmalıyız.

SOLID ile Tasarım Desenleri Arasındaki İlişki

SOLID, tasarım prensiplerini açıklar. Tasarım desenleri ise belirli problemler için çözüm yapıları sunar.

Bu iki kavramı aynı şey gibi değerlendirmek doğru olmaz.

Örneğin Strategy, OCP ve DIP açısından yarar sağlayabilir. Ancak kötü tasarladığımız bir Strategy arayüzü LSP’yi ihlal edebilir.

Bu nedenle bir tasarım desenini uygulamak tek başına SOLID’e uygun kod yazdığımız anlamına gelmez.

Java tasarım desenlerinin kategorilerini ve kullanım alanlarını daha geniş bir bakışla incelemek için serimizin ilk yazısı olan Java Tasarım Desenleri: Gerçek Hayat Örnekleri ve Modern Java rehberine göz atabilirsiniz.

SOLID Prensiplerini Uygularken Yapılan Hatalar

SOLID hakkında sık karşılaştığım bir sorun, geliştiricilerin prensipleri uygulamanın amacı yerine koymasıdır.

Kodun esnek olması önemlidir. Fakat hiçbir zaman ihtiyaç duymayacağımız varyasyonlar için büyük bir soyutlama ağı oluşturmak geliştirme maliyetini artırır.

Her Sınıf İçin Interface Oluşturmak

Bir sınıfın tek bir implementasyonu bulunuyorsa otomatik olarak interface açmak zorunda değilsiniz.

Interface, anlamlı bir sözleşme veya bağımlılık sınırı oluşturduğunda değer kazanır.

SRP’yi Tek Metot Kuralına Dönüştürmek

SRP, bir sınıfın yalnızca bir metoda sahip olmasını istemez.

Bir sipariş hesaplama bileşeni birden fazla ilişkili metot içerebilir. Önemli olan bu metotların aynı sorumluluk altında bulunmasıdır.

OCP’yi Hiç Kod Değiştirmemek Olarak Yorumlamak

Gerçek iş gereksinimleri değiştiğinde mevcut kodu güncellememiz normaldir.

OCP, bütün gelecekteki değişiklikleri önceden tahmin etmemizi beklemez.

Kalıtımı Her Durumda Tercih Etmek

Kalıtım güçlü bir mekanizmadır. Ancak bir sınıfın başka bir sınıftan davranış devralması her zaman doğru bir alt tür ilişkisi oluşturmaz.

Bazı durumlarda composition daha esnek bir çözüm sunar.

DIP’yi Yalnızca Spring Annotation’larına İndirgemek

@Autowired veya constructor injection kullanmak tek başına doğru mimari oluşturmaz.

İş kurallarının hangi katmanda bulunduğunu, hangi soyutlamaya bağımlı olduğunu ve bağımlılıkların hangi yönde ilerlediğini de incelemeliyiz.

SOLID Kodlarının Test Edilebilirliği

SOLID’in somut yararlarından biri, sınıfları gerçek altyapı servislerinden bağımsız test edebilmemizdir.

Örneğin DIP bölümündeki OrderService için gerçek Oracle bağlantısı kurmamıza gerek yok.

JUnit 5 ile küçük bir test yazabiliriz.

import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;

import java.math.BigDecimal;

class OrderServiceTest {

    @Test
    void shouldSaveOrder() {

        class FakeOrderRepository
                implements OrderRepository {

            Order savedOrder;

            @Override
            public void save(Order order) {
                savedOrder = order;
            }
        }

        FakeOrderRepository repository =
                new FakeOrderRepository();

        OrderService service =
                new OrderService(repository);

        Order order = new Order(
                "ORD-1001",
                "customer@example.com",
                new BigDecimal("250.00")
        );

        service.createOrder(order);

        assertEquals(order, repository.savedOrder);
    }
}

Bu testte veritabanı bağlantısı açmıyoruz.

Test, sipariş servisinin ilgili repository sözleşmesini doğru kullanıp kullanmadığını kontrol ediyor.

Elbette bu test Oracle veritabanına gerçekten kayıt yazabileceğimizi kanıtlamaz. Bunu doğrulamak için ayrıca entegrasyon testi geliştirmeliyiz.

Unit test ve integration test farklı riskleri ele alır.

SOLID burada yalnızca test yazmayı kolaylaştırır. Test stratejisini ve kapsamını yine geliştirici belirler.

SOLID Prensiplerini Uygulamak İçin Pratik Yaklaşım

Mevcut bir Java projesinde SOLID uygulamak istiyorsanız bütün sınıfları aynı anda yeniden tasarlamanızı önermem.

Bunun yerine küçük ve gözlemlenebilir adımlarla ilerleyin.

1. Önce değişiklik maliyeti yüksek sınıfları belirleyin.
2. Sınıfların neden değiştiğini ve hangi iş sorumluluklarını taşıdığını inceleyin.
3. Mevcut davranışı koruyan karakterizasyon testleri yazın.
4. Birden fazla sorumluluğu karıştıran kodları anlamlı bileşenlere ayırın.
5. Somut altyapı bağımlılıklarını değerlendirin.
6. Yeni davranışları eklerken değişiklik yapılan dosya sayısını ve kod karmaşıklığını gözlemleyin.
7. Gereksiz soyutlamaları kaldırmaktan çekinmeyin.

Özellikle eski kurumsal Java uygulamalarında büyük bir refactoring çalışmasını tek seferde yapmak ciddi regresyon riski doğurabilir.

Her değişikliği küçük adımlarla ilerletmek, testlerle doğrulamak ve sistem davranışını izlemek daha güvenli bir yaklaşım sunar.

Sık Sorulan Sorular

SOLID prensipleri sadece Java için mi geçerlidir?

Hayır. SOLID, nesne yönelimli yazılım tasarımına yönelik genel prensiplerden oluşur. Java dışında C#, Kotlin ve C++ gibi dillerde de kullanabilirsiniz.

SOLID prensiplerini hangi sırayla öğrenmeliyim?

SRP ile başlayabilir, ardından OCP ve LSP konularına geçebilirsiniz. ISP ve DIP ise arayüzler ve bağımlılık yönetimi konusunda daha derin düşünmenizi sağlar. Ancak prensipler birbirini tamamladığı için gerçek projelerde tek tek değil, birlikte değerlendirmek gerekir.

SOLID ile Clean Code aynı şey mi?

Hayır. Clean Code okunabilirlik, isimlendirme, kod organizasyonu ve bakım kolaylığı gibi geniş bir alanı kapsar. SOLID ise nesne yönelimli tasarım prensiplerine odaklanır.

SOLID ile Design Patterns arasındaki fark nedir?

SOLID, iyi tasarım için yol gösteren prensipler sunar. Design Patterns ise tekrar eden yazılım tasarım problemleri için çözüm modelleri önerir.

Java Record, SOLID prensiplerinin yerini alır mı?

Hayır. Record, veri odaklı sınıfları daha kısa yazmamıza yardımcı olur. Sorumluluk ayrımı ve bağımlılık yönetimi gibi mimari kararların yerini alamaz.

Spring Boot kullanırken SOLID bilmek gerekir mi?

Evet. Spring Boot, Dependency Injection ve farklı soyutlama mekanizmaları sunar. Ancak bu mekanizmaları hangi amaçla ve hangi mimari sınırlar içinde kullanacağımıza geliştirici karar verir.

SOLID her projede uygulanmalı mı?

SOLID prensiplerini değerlendirmek yararlıdır; ancak her sınıfa aynı soyutlama düzeyini uygulamak doğru değildir. Küçük bir uygulamanın gereksinimleriyle geniş bir kurumsal sistemin gereksinimleri farklıdır.

Sonuç: SOLID, Daha Fazla Sınıf Yazmak Demek Değildir

Java’da SOLID prensiplerini uygulamanın amacı mümkün olduğunca fazla interface veya sınıf oluşturmak değildir.

SRP, sorumlulukların neden değiştiğini anlamamıza yardımcı olur. OCP, yeni davranışları mevcut kod üzerinde gereksiz değişiklik yapmadan eklemeyi hedefler. LSP, alt türlerin davranışsal sözleşmeleri korumasını ister. ISP, arayüzleri istemcilerin gerçek ihtiyaçlarına göre şekillendirir. DIP ise iş kurallarını altyapı ayrıntılarından bağımsız tutmaya odaklanır.

Beş prensibin ortak hedefi, değişiklik maliyetini yönetilebilir seviyede tutmaktır.

Bir tasarım kararı verirken önce gerçek problemi anlamalıyız. Ardından bu problemi çözecek en basit ve sürdürülebilir yapıyı seçebiliriz.

Bazı durumlarda bir arayüz ve iki sınıf doğru çözümdür. Başka bir durumda tek bir record ve kısa bir metot aynı işi daha açık biçimde yapabilir.

İyi Java mimarisi, her tasarım prensibini görünür biçimde kullanmakla değil, hangi durumda hangi soyutlamanın değer kazandırdığını bilmekle başlar.

Serinin sonraki yazısı: Composition vs Inheritance: Java’da Hangisini Seçmeli? Bu makalede kalıtım ile nesne bileşimini Java üzerinden karşılaştıracak, LSP ve OCP ile ilişkilerini gerçek örnekler üzerinde inceleyeceğiz.

Kaynaklar ve İleri Okuma

1. Robert C. Martin — Agile Software Development, Principles, Patterns, and Practices, Prentice Hall, 2002.
2. Robert C. Martin — Clean Architecture: A Craftsman’s Guide to Software Structure and Design, Prentice Hall, 2017.
3. Barbara Liskov, Jeannette Wing — A Behavioral Notion of Subtyping, ACM Transactions on Programming Languages and Systems, 1994.
4. Joshua Bloch — Effective Java, Third Edition, Addison-Wesley, 2018.
5. Oracle — Java SE 21 Language Documentation: https://docs.oracle.com/en/java/javase/21/language/
6. OpenJDK — JEP 395: Records: https://openjdk.org/jeps/395
7. OpenJDK — JEP 409: Sealed Classes: https://openjdk.org/jeps/409
8. OpenJDK — JEP 441: Pattern Matching for switch: https://openjdk.org/jeps/441
9. Martin Fowler — Refactoring: https://refactoring.com/

Java’da SOLID Prensipleri: Gerçek Kod Örnekleriyle 5 Temel İlke yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Örneğin bir e-ticaret uygulaması düşünelim. İlk sürüm yalnızca kredi kartıyla ödeme kabul ediyor. Birkaç ay sonra ekip dijital cüzdan, banka transferi ve farklı ödeme sağlayıcıları eklemek istiyor. Geliştirici her ödeme yöntemi için aynı sınıfın içine yeni if-else koşulları eklerse sistem zamanla bakım açısından zorlaşır.

Strategy tasarım deseni bu soruna bir çözüm sunar. Ancak tek çözüm o değildir. Basit bir switch ifadesi de bazı projelerde aynı işi daha az kodla halledebilir.

Tasarım desenleri (Design Patterns), yazılım geliştiricilerin tekrar eden tasarım problemlerini çözmek için kullandığı, deneyimle şekillenmiş çözüm yaklaşımlarıdır. Bir desen hazır kod sunmaz. Geliştiriciye sorumlulukları nasıl ayıracağını, bağımlılıkları nasıl yöneteceğini ve değişiklikleri sistemin hangi noktalarında karşılayacağını gösterir.

Bu rehberde Java’nın en önemli tasarım desenlerini gerçek kullanım senaryolarıyla inceleyeceğiz. Java 17 ve Java 21 özelliklerinin klasik desenleri nasıl etkilediğini, hangi desenin ne zaman avantaj kazandırdığını ve hangi koşullarda gereksiz karmaşıklık yarattığını da ele alacağız.

Tasarım Desenleri (Design Patterns) Nedir?

Tasarım deseni, belirli bir yazılım tasarım problemine tekrar uygulanabilen genel bir çözüm modelidir.

Örneğin:

• Bir nesneden yalnızca tek örnek üretmek istiyorsanız Singleton desenini değerlendirebilirsiniz.
• Nesne oluşturma mantığını iş kurallarından ayırmak istiyorsanız Factory yaklaşımı yardımcı olur.
• Çok sayıda yapılandırma parametresi içeren nesneler oluşturuyorsanız Builder kullanabilirsiniz.
• Çalışma anında farklı algoritmalar arasında geçiş yapmak istiyorsanız Strategy uygundur.
• Bir olay gerçekleştiğinde birden fazla bileşenin haberdar olmasını istiyorsanız Observer kullanabilirsiniz.

Burada önemli bir ayrım var: Tasarım deseni ile yazılım mimarisi aynı şey değildir.

Clean Architecture bir uygulamanın katmanlarını ve bağımlılık yönlerini ele alırken Strategy, belirli bir davranış ailesini nasıl yöneteceğinize odaklanır. Bu iki yaklaşım birbirini tamamlayabilir.

Tasarım Desenleri Neden Önemlidir?

İyi seçilmiş bir tasarım deseni geliştiriciye birkaç somut avantaj kazandırır.

Değişikliklerin etkisini sınırlar. Bir ödeme sağlayıcısını değiştirmek için sipariş yönetimi kodunu yeniden yazmak zorunda kalmazsınız.

Test yazmayı kolaylaştırır. Bağımlılıkları arayüzler üzerinden yönettiğinizde gerçek servisler yerine test nesneleri kullanabilirsiniz.

Takım içi iletişimi güçlendirir. Bir geliştiricinin “burada Strategy kullanıyoruz” demesi, uzun bir sınıf diyagramını açıklamaktan daha hızlı olabilir.

Tekrarlanan tasarım kararlarını azaltır. Ekip, iyi anladığı çözümleri benzer problemlere tutarlı biçimde uygular.

Bununla birlikte her tasarım deseni yeni sınıflar, arayüzler veya ek soyutlamalar getirebilir. Küçük bir problemi çözmek için gereğinden fazla katman oluşturmak kod kalitesini artırmaz.

Java Tasarım Desenleri Kaç Kategoriye Ayrılır?

Gang of Four (GoF) yaklaşımı, 23 klasik tasarım desenini üç ana kategori altında inceler.

Bu ayrım, hangi deseni seçeceğinizi doğrudan söylemez. Önce problemin hangi sorumlulukla ilgili olduğunu anlamanız gerekir.

Nesne oluşturma koduyla mı uğraşıyorsunuz? Birden fazla sistemi mi bütünleştiriyorsunuz? Yoksa çalışma anında değişen iş kurallarını mı yönetiyorsunuz?

Bu sorular desen seçimini daraltır.

1. Singleton Pattern: Tek Bir Nesneyle Çalışmak

Singleton, bir sınıftan yalnızca tek bir örnek oluşturmayı ve bu örneğe merkezi bir erişim noktası sunmayı amaçlar.

Bir uygulamanın belirli bir süreç içinde ortak kullanacağı konfigürasyon nesnesi veya durum tutmayan bir yardımcı servis bu yaklaşım için aday olabilir.

Ancak Singleton ile global değişken kullanımı arasındaki sınır oldukça incedir.

Java’da Singleton Nasıl Uygulanır?

Java’da Singleton geliştirmek için farklı yöntemler bulunur. Bunlardan biri enum kullanmaktır.

public enum ApplicationConfig {
    INSTANCE;

    private final String environment = "production";

    public String getEnvironment() {
        return environment;
    }
}

Kullanım:

String environment =
        ApplicationConfig.INSTANCE.getEnvironment();

System.out.println(environment);

Java, her enum sabiti için tek bir örnek oluşturur. Bu yaklaşım standart Java serileştirme davranışıyla uyumludur ve ek bir synchronized mekanizması gerektirmeden güvenli örnek oluşturma sağlar.

Bununla birlikte enum Singleton, nesnenin içindeki değiştirilebilir verileri kendiliğinden thread-safe hâle getirmez.

Singleton Kullanırken Nelere Dikkat Etmelisiniz?

Bir Singleton başka sınıflar tarafından doğrudan çağrılıyorsa bağımlılıklar kodun içine gömülür.

Örneğin:

public class OrderService {

    public void createOrder() {
        String env =
                ApplicationConfig.INSTANCE.getEnvironment();
    }
}

OrderService artık konfigürasyon kaynağını kendisi seçer. Test ortamında bu bağımlılığı değiştirmek güçleşebilir.

Dependency Injection kullanan projelerde geliştirici çoğu zaman Singleton yerine uygulama kapsamındaki tek bir servis örneğini tercih eder.

Spring Framework içindeki varsayılan singleton bean kapsamı buna örnektir. Spring, ilgili uygulama bağlamında bir bean tanımı için ortak bir örnek yönetir. Bu davranış, JVM genelinde tek örnek garantisi veren klasik Singleton ile aynı değildir.

Ne zaman kullanmalı? Nesnenin süreç genelinde tek bir örnek olarak var olması gerçekten bir tasarım gereksinimiyse ve global erişimin getirdiği bağımlılıkları kabul ediyorsanız kullanın.

2. Factory Pattern: Nesne Oluşturma Mantığını Ayırmak

Bir uygulama farklı bildirim kanalları üzerinden mesaj gönderebilir: e-posta, SMS veya anlık bildirim.

Her iş servisi hangi sınıfı oluşturacağını kendisi seçerse aynı karar mantığı uygulamanın farklı noktalarına dağılır.

Factory yaklaşımı nesne oluşturma kararını merkezi bir bileşene taşır.

Burada terminolojiye dikkat etmek gerekir. Gündelik Java geliştirmesinde Factory Pattern olarak anılan basit statik fabrika yaklaşımı, GoF kitabındaki kalıtım temelli Factory Method deseniyle birebir aynı değildir.

Java 21 ile Factory Örneği

Önce bildirim modellerini tanımlayalım:

sealed interface Notification
        permits EmailNotification, SmsNotification {
}

record EmailNotification(String address)
        implements Notification {
}

record SmsNotification(String phoneNumber)
        implements Notification {
}

Ardından her kanal için farklı bir gönderici oluşturalım:

interface NotificationSender {
    void send(String message);
}

final class EmailSender implements NotificationSender {

    @Override
    public void send(String message) {
        System.out.println("Email: " + message);
    }
}

final class SmsSender implements NotificationSender {

    @Override
    public void send(String message) {
        System.out.println("SMS: " + message);
    }
}

Factory sınıfı:

final class NotificationFactory {

    private NotificationFactory() {
    }

    static NotificationSender create(
            Notification notification) {

        return switch (notification) {
            case EmailNotification email ->
                    new EmailSender();

            case SmsNotification sms ->
                    new SmsSender();
        };
    }
}

Kullanım:

Notification notification =
        new EmailNotification("user@example.com");

NotificationSender sender =
        NotificationFactory.create(notification);

sender.send("Siparişiniz onaylandı.");

Bu Tasarım Neden İşe Yarar?

NotificationFactory nesnenin somut türünü seçer. İstemci ise oluşturduğu nesneyle NotificationSender arayüzü üzerinden iletişim kurar.

Java 17 ile kalıcı hâle gelen sealed yapısı, hangi türlerin Notification arayüzünü uygulayabileceğini sınırlar.

Java 21 ile kalıcı hâle gelen switch pattern matching özelliği ise bu türler üzerinde kapsamlı bir eşleştirme yapar.

Yeni bir bildirim türünü permits kapsamına eklediğinizde derleyici, ilgili switch ifadesinin yeni türü de ele almasını isteyebilir.

Bu yaklaşımın bir sınırı var: Factory, yeni somut türler karşısında değişiklik gerektirir. Kapalı bir tür ailesi için bu davranış avantaj sağlar. Dinamik olarak genişleyen bir eklenti mimarisinde ise registry tabanlı bir fabrika veya Dependency Injection daha uygun olabilir.

Ne zaman kullanmalı? Nesne oluşturma kararı birden fazla yerde tekrar ediyorsa veya nesne oluştururken iş kurallarına bağlı seçim yapıyorsanız Factory yaklaşımını değerlendirin.

3. Builder Pattern: Karmaşık Nesneleri Adım Adım Oluşturmak

Bir API isteği düşünelim. Kullanıcı, rapor oluştururken tarih aralığı, format, dil, filtreler ve sıralama tercihi belirleyebiliyor.

Bütün parametreleri tek constructor üzerinden almak zamanla okunabilirliği azaltabilir.

Builder deseni, karmaşık bir nesnenin oluşturulma sürecini anlaşılır adımlara böler.

Java Builder Örneği

import java.time.LocalDate;
import java.util.Objects;

public final class ReportRequest {

    private final LocalDate startDate;
    private final LocalDate endDate;
    private final String format;

    private ReportRequest(Builder builder) {
        this.startDate = builder.startDate;
        this.endDate = builder.endDate;
        this.format = builder.format;
    }

    public static Builder builder() {
        return new Builder();
    }

    public static final class Builder {

        private LocalDate startDate;
        private LocalDate endDate;
        private String format = "PDF";

        public Builder startDate(LocalDate value) {
            this.startDate = value;
            return this;
        }

        public Builder endDate(LocalDate value) {
            this.endDate = value;
            return this;
        }

        public Builder format(String value) {
            this.format = value;
            return this;
        }

        public ReportRequest build() {
            Objects.requireNonNull(startDate);
            Objects.requireNonNull(endDate);
            Objects.requireNonNull(format);

            if (startDate.isAfter(endDate)) {
                throw new IllegalArgumentException(
                        "Başlangıç tarihi bitişten sonra olamaz."
                );
            }

            return new ReportRequest(this);
        }
    }
}

Kullanım:

ReportRequest request = ReportRequest.builder()
        .startDate(LocalDate.of(2026, 1, 1))
        .endDate(LocalDate.of(2026, 1, 31))
        .format("CSV")
        .build();

Builder, nesne oluşmadan önce alanları toplar ve build() aşamasında doğrulama yapar.

Bu sayede geçersiz tarih aralığına sahip bir ReportRequest nesnesi üretmeyiz.

Java Record, Builder Deseninin Yerini Alır mı?

Java 17 ile record kullanarak veri taşıyan sınıfları çok daha kısa yazabiliriz.

import java.time.LocalDate;
import java.util.Objects;

public record ReportFilter(
        LocalDate startDate,
        LocalDate endDate,
        String format) {

    public ReportFilter {
        Objects.requireNonNull(startDate);
        Objects.requireNonNull(endDate);
        Objects.requireNonNull(format);

        if (startDate.isAfter(endDate)) {
            throw new IllegalArgumentException(
                    "Geçersiz tarih aralığı"
            );
        }
    }
}

Üç alanlı basit bir veri modeli için bu çözüm yeterli olabilir.

Ancak çok sayıda isteğe bağlı parametre, birbirine bağımlı yapılandırma seçeneği veya aşamalı oluşturma süreci varsa Builder hâlâ değer taşır.

Record bileşenlerinin sonradan yeniden atanamaması da tek başına derin immutability garantisi vermez. Örneğin bir record içinde değiştirilebilir liste tutarsanız dış kod bu listenin içeriğini değiştirebilir.

Ne zaman kullanmalı? Constructor parametreleri anlamını kaybediyorsa, çok sayıda isteğe bağlı alan varsa veya nesne oluştururken tutarlı bir doğrulama akışı gerekiyorsa Builder tercih edin.

4. Adapter Pattern: Uyumsuz Arayüzleri Birleştirmek

Yazılım projelerinde her servisin aynı arayüzü kullanmasını bekleyemeyiz.

Örneğin bir ödeme sistemi farklı bankaların servisleriyle iletişim kurabilir. Bankalardan biri makePayment() metodunu, diğeri executeTransaction() metodunu sunabilir.

Bu farklılıkları iş katmanına taşımak, ödeme kodunu dış servislerin ayrıntılarına bağımlı hâle getirir.

Adapter deseni, farklı arayüzleri ortak bir sözleşmeye dönüştürür.

Java Adapter Örneği

Uygulamamızın ortak sözleşmesi:

import java.math.BigDecimal;

interface PaymentGateway {

    boolean pay(BigDecimal amount);
}

Harici bankanın sunduğu servis:

class LegacyBankClient {

    public String executeTransaction(
            BigDecimal amount) {

        return "SUCCESS";
    }
}

Adapter:

final class LegacyBankAdapter
        implements PaymentGateway {

    private final LegacyBankClient client;

    LegacyBankAdapter(LegacyBankClient client) {
        this.client = client;
    }

    @Override
    public boolean pay(BigDecimal amount) {
        String result =
                client.executeTransaction(amount);

        return "SUCCESS".equals(result);
    }
}

Kullanım:

PaymentGateway gateway =
        new LegacyBankAdapter(new LegacyBankClient());

boolean success =
        gateway.pay(new BigDecimal("149.90"));

Artık sipariş servisi hangi bankanın hangi metodunu kullandığını bilmek zorunda kalmaz.

Adapter Deseninin Mimari Avantajı

Adapter yalnızca metot isimlerini değiştirmez. Dış sistemlerin veri modellerini ve hata sözleşmelerini de uygulamanın kendi modeline dönüştürebilir.

Örneğin gerçek bir banka entegrasyonunda HTTP durum kodlarını, hata mesajlarını ve işlem referanslarını ortak bir sonuç nesnesine dönüştürmek isteyebilirsiniz.

Ancak ödeme gibi kritik işlemlerde "SUCCESS" dışındaki her sonucu doğrudan başarısızlık olarak yorumlamak yeterli değildir. Zaman aşımı, belirsiz işlem sonucu ve kesin ret birbirinden farklı durumlardır.

Bu ayrım olmadan aynı ödemeyi tekrar denemek çift tahsilat riski doğurabilir.

Ne zaman kullanmalı? Üçüncü taraf SDK, eski sistem veya farklı veri sözleşmesi kullanan bir servisle entegrasyon geliştirirken Adapter deseni güçlü bir seçenektir.

5. Decorator Pattern: Mevcut Davranışa Yeni Sorumluluklar Eklemek

Bir dış API istemciniz olduğunu düşünün.

İlk sürüm yalnızca HTTP isteği gönderiyor. Daha sonra her isteğin süresini ölçmek, log üretmek veya metrik toplamak istiyorsunuz.

Bütün bu sorumlulukları doğrudan HTTP istemcisinin içine eklemek, sınıfın kapsamını genişletir.

Decorator deseni, mevcut nesnenin etrafına yeni bir nesne yerleştirerek davranış eklemenize olanak tanır.

Java Decorator Örneği

Ortak arayüz:

interface ApiClient {

    String fetchData();
}

Temel istemci:

final class DefaultApiClient implements ApiClient {

    @Override
    public String fetchData() {
        return "API response";
    }
}

Zaman ölçen Decorator:

final class TimedApiClient implements ApiClient {

    private final ApiClient delegate;

    TimedApiClient(ApiClient delegate) {
        this.delegate = delegate;
    }

    @Override
    public String fetchData() {
        long start = System.nanoTime();

        try {
            return delegate.fetchData();
        } finally {
            long elapsed = System.nanoTime() - start;

            System.out.println(
                    "Duration(ns): " + elapsed
            );
        }
    }
}

Kullanım:

ApiClient client =
        new TimedApiClient(new DefaultApiClient());

System.out.println(client.fetchData());

TimedApiClient, gerçek istemcinin sorumluluğunu değiştirmez. Yalnızca işlem süresini ölçer.

Decorator zinciri kurarak farklı davranışları birleştirebilirsiniz. Örneğin ayrı bir Decorator metrik kaydı tutarken bir diğeri erişim kontrolü gerçekleştirebilir.

Decorator ile Inheritance Arasındaki Fark

Kalıtım, davranışı sınıf hiyerarşisi üzerinden genişletir. Decorator ise composition kullanır.

Bu fark, davranış kombinasyonları arttığında önem kazanır.

Her kombinasyon için alt sınıf üretmek yerine ihtiyacınız olan davranışları nesnelerin etrafına yerleştirebilirsiniz.

Yine de her çapraz kesen sorumluluk için elle Decorator yazmak zorunda değilsiniz. Spring AOP, interceptor veya filtre mekanizmaları bazı durumlarda daha uygun seçeneklerdir.

Ne zaman kullanmalı? Mevcut bir nesneye loglama, metrik, doğrulama veya önbellekleme gibi ek davranışlar kazandırmak istediğinizde değerlendirin.

6. Strategy Pattern: Değişebilen Algoritmaları Yönetmek

Strategy, gerçek projelerde en sık karşılaşılan davranışsal tasarım desenlerinden biridir.

Bir e-ticaret sisteminde farklı indirim hesaplama kuralları bulunduğunu düşünelim.

Standart müşteriler indirim almıyor. Premium müşteriler %10 indirim alıyor. Kurumsal müşteriler ise farklı bir fiyatlandırma kuralına tabi.

Bütün bu kuralları tek bir calculateDiscount() metodunda toplamak başlangıçta kolaydır. Ancak yeni kampanyalar geldikçe koşullar uzar.

Strategy, her algoritmayı ayrı bir davranış olarak ele alır.

Java Strategy Örneği

Önce ortak sözleşmeyi tanımlayalım:

import java.math.BigDecimal;

interface DiscountStrategy {

    BigDecimal calculate(BigDecimal amount);
}

Standart müşteri stratejisi:

final class StandardDiscount
        implements DiscountStrategy {

    @Override
    public BigDecimal calculate(BigDecimal amount) {
        return BigDecimal.ZERO;
    }
}

Premium müşteri stratejisi:

final class PremiumDiscount
        implements DiscountStrategy {

    private static final BigDecimal RATE =
            new BigDecimal("0.10");

    @Override
    public BigDecimal calculate(BigDecimal amount) {
        return amount.multiply(RATE);
    }
}

Stratejiyi kullanan servis:

final class PricingService {

    private final DiscountStrategy strategy;

    PricingService(DiscountStrategy strategy) {
        this.strategy = strategy;
    }

    BigDecimal calculateTotal(BigDecimal amount) {
        if (amount.signum() < 0) {
            throw new IllegalArgumentException(
                    "Tutar negatif olamaz"
            );
        }

        BigDecimal discount =
                strategy.calculate(amount);

        return amount.subtract(discount);
    }
}

Kullanım:

PricingService service =
        new PricingService(new PremiumDiscount());

BigDecimal total = service.calculateTotal(
        new BigDecimal("1000.00")
);

System.out.println(total); // 900.0000

Burada PricingService, indirimin nasıl hesaplandığını bilmez.

Yeni bir indirim politikası geldiğinde geliştirici mevcut servis mantığını değiştirmeden farklı bir DiscountStrategy uygulaması ekleyebilir.

Gerçek finansal uygulamalarda para birimini, yuvarlama kurallarını ve hesaplama hassasiyetini ayrıca tanımlamak gerekir. Örnekteki BigDecimal kullanımı yalnızca algoritma ayrımını göstermeyi amaçlar.

Strategy ile Open/Closed Principle İlişkisi

Open/Closed Principle, yazılım bileşenlerinin yeni davranışlarla genişleyebilmesini ve mevcut kodda gereksiz değişiklik ihtiyacının azalmasını hedefler.

Strategy bunu doğrudan destekler.

Fakat bütün koşullar altında mevcut kodu değiştirmeme garantisi vermez. Strateji seçimini yöneten bileşenin yeni türleri tanıması gerekebilir.

Her Strategy İçin Yeni Sınıf Gerekli mi?

Hayır.

Java’da tek soyut metot içeren arayüzleri lambda ifadeleriyle uygulayabilirsiniz.

DiscountStrategy campaignDiscount =
        amount -> amount.multiply(
                new BigDecimal("0.15")
        );

Basit ve durum tutmayan bir algoritma için lambda yeterli olabilir.

Buna karşılık bir strateji kendi konfigürasyonunu, bağımlılıklarını ve kapsamlı testlerini taşıyorsa ayrı sınıf kullanmak daha okunabilir bir çözüm sunar.

Ne zaman kullanmalı? Aynı işlemin farklı algoritmalarla gerçekleşmesi gerekiyorsa ve bu algoritmaları çalışma anında değiştirmek istiyorsanız Strategy kullanın.

7. Observer Pattern: Olay Tabanlı İletişim Kurmak

Bir sipariş tamamlandığında sistem birden fazla işlem başlatabilir.

Örneğin:

• Müşteriye bildirim gönderir.
• Analitik sistemine olay iletir.
• Sadakat puanı hesaplar.
• Denetim kaydı üretir.

Sipariş servisi bütün bu bileşenleri doğrudan çağırırsa zamanla çok sayıda bağımlılık taşımaya başlar.

Observer deseni, bir olay gerçekleştiğinde ilgili dinleyicilerin haberdar olmasını sağlar.

Java Observer Örneği

Önce olayı tanımlayalım:

record OrderCreatedEvent(String orderId) {
}

Dinleyici sözleşmesi:

interface OrderEventListener {

    void onOrderCreated(OrderCreatedEvent event);
}

Bildirim dinleyicisi:

final class EmailNotificationListener
        implements OrderEventListener {

    @Override
    public void onOrderCreated(
            OrderCreatedEvent event) {

        System.out.println(
                "Email notification: " + event.orderId()
        );
    }
}

Olayı yöneten sınıf:

import java.util.ArrayList;
import java.util.List;

final class OrderEventPublisher {

    private final List<OrderEventListener> listeners =
            new ArrayList<>();

    public void subscribe(OrderEventListener listener) {
        listeners.add(listener);
    }

    public void publish(OrderCreatedEvent event) {
        for (OrderEventListener listener : listeners) {
            listener.onOrderCreated(event);
        }
    }
}

Kullanım:

OrderEventPublisher publisher =
        new OrderEventPublisher();

publisher.subscribe(
        new EmailNotificationListener()
);

publisher.publish(
        new OrderCreatedEvent("ORD-1001")
);

Publisher yalnızca dinleyici arayüzünü bilir. Bildirim gönderme ayrıntılarını bilmez.

Observer ile Event-Driven Architecture Aynı Şey mi?

Hayır.

Observer, aynı uygulama içinde çalışan nesneler arasında olay bildirimi için kullanılabilir.

Event-Driven Architecture ise farklı servisler, mesaj aracıları, kalıcı olay akışları ve dağıtık iletişim gibi daha geniş konuları ele alır.

Örneğin Apache Kafka üzerinden bir olay yayınlamak, klasik uygulama içi Observer kullanımından farklı operasyonel gereksinimler getirir.

Bu örnekte publish() metodu senkron çalışır. Dinleyicilerden biri hata fırlatırsa sonraki dinleyiciler olayı alamayabilir.

Gerçek bir uygulamada hata izolasyonu, tekrar deneme, olay sıralaması ve teslimat garantileri için ayrıca tasarım kararı vermelisiniz.

ArrayList tabanlı abonelik yönetimi de eşzamanlı ekleme ve bildirim işlemleri için uygun değildir. Birden fazla thread dinleyici listesini değiştiriyorsa thread-safe bir yapı veya açık bir eşzamanlılık politikası seçmelisiniz.

Ne zaman kullanmalı? Bir olayın birden fazla bağımsız bileşeni ilgilendirdiği ve yayıncı ile dinleyiciler arasında doğrudan bağımlılık kurmak istemediğiniz durumlarda tercih edin.

8. State Pattern: Nesnenin Durumuna Göre Davranışını Değiştirmek

Bir siparişin farklı yaşam döngüsü durumları vardır:

CREATED, PAID, SHIPPED, DELIVERED, CANCELLED

Her durum aynı işlemlere izin vermez.

Örneğin kargoya çıkan bir siparişi doğrudan iptal etmek istemeyebilirsiniz. Teslim edilen sipariş ise farklı bir iade sürecine geçebilir.

Karmaşık yaşam döngülerinde State deseni her durumun davranışını ayrı bir nesneyle temsil eder.

Ancak Java 21, basit ve sınırlı durum makineleri için daha kısa bir seçenek de sunar.

Java 21 ile Sealed State Modeli

sealed interface OrderState
        permits Created, Paid, Shipped, Cancelled {
}

record Created() implements OrderState {
}

record Paid() implements OrderState {
}

record Shipped() implements OrderState {
}

record Cancelled() implements OrderState {
}

Durum geçişini modelleyelim:

final class OrderStateMachine {

    static OrderState cancel(OrderState state) {

        return switch (state) {

            case Created c -> new Cancelled();

            case Paid p -> new Cancelled();

            case Shipped s ->
                    throw new IllegalStateException(
                            "Kargodaki sipariş iptal edilemez"
                    );

            case Cancelled c ->
                    throw new IllegalStateException(
                            "Sipariş zaten iptal"
                    );
        };
    }
}

Bu kod Java 21’in sealed interface ve pattern matching özelliklerini kullanır.

Derleyici, tanımladığımız tür ailesi üzerinden switch kapsamını denetleyebilir.

Önemli bir mimari ayrım var: Bu örnek klasik nesne yönelimli State deseninin tam uygulaması değildir. Burada davranışları durum nesnelerine dağıtmak yerine merkezi bir durum geçiş fonksiyonunda topluyoruz.

Gerçek GoF State deseni, her durumun kendi geçiş ve davranış mantığını yönetmesine olanak tanır.

Hangi Yaklaşımı Seçmelisiniz?

Az sayıda durum ve birkaç geçiş içeren kapalı bir modelde sealed interface ile switch çoğu zaman yeterlidir.

Ancak her durum farklı iş servislerini çağırıyor, kendi kurallarını yönetiyor ve yeni davranışlar ekliyorsa klasik State yaklaşımı daha uygun olabilir.

Modern Java kullanmak, bütün tasarım desenlerini ortadan kaldırmaz. Bazı problemleri daha az soyutlamayla çözmemize yardımcı olur.

Java 17 ve Java 21 Tasarım Desenlerini Nasıl Etkiliyor?

Klasik tasarım desenleri, Java’nın bugünkü dil özelliklerinin büyük bir kısmından daha önce ortaya çıktı.

Bu nedenle eski kitaplarda gördüğünüz her sınıf hiyerarşisini güncel bir Java projesinde aynı şekilde uygulamak zorunda değilsiniz.

Virtual Threads bir tasarım deseni değildir. Java 21’in sunduğu bir eşzamanlılık özelliğidir. Ancak uygulamanın concurrency modelini tasarlarken verdiğiniz kararları etkileyebilir.

Aynı şekilde record da Builder deseninin birebir karşılığı değildir. Bir dil özelliğinin hangi problemi çözdüğünü anlamadan bir desenin yerine koymak doğru sonuç vermez.

Tasarım Desenleri ile SOLID Prensipleri Arasındaki İlişki

SOLID ve tasarım desenleri farklı konuları ele alır.

SOLID prensipleri sınıf ve modül tasarımına yönelik rehberlik sunar. Tasarım desenleri ise belirli problemlere çözüm yapıları önerir.

İkisi arasındaki ilişkiyi birkaç örnekle inceleyelim.

Single Responsibility Principle (SRP)

Bir sınıfın değişmesi için birden fazla bağımsız nedeni olmaması gerekir.

Decorator, bildirim gönderme ile performans ölçme sorumluluklarını farklı sınıflara ayırabilir.

Open/Closed Principle (OCP)

Strategy, mevcut algoritma kullanıcılarını değiştirmeden yeni algoritma uygulamaları eklemeyi kolaylaştırır.

Ancak desenin yanlış uygulanması hâlinde merkezi bir if-else zinciri aynı bağımlılık sorununu koruyabilir.

Liskov Substitution Principle (LSP)

Bir Strategy uygulaması, arayüzün belirlediği sözleşmeye uymalıdır.

Örneğin DiscountStrategy için negatif indirim değerleri yasaksa yeni bir stratejinin bu kuralı ihlal etmesi yerine geçebilirliği bozar.

Interface Segregation Principle (ISP)

Küçük, amaca odaklı arayüzler Adapter ve Strategy gibi desenlerle daha iyi çalışır.

Her davranışı kapsayan devasa bir servis arayüzü, uygulayan sınıflara gereksiz sorumluluk yükler.

Dependency Inversion Principle (DIP)

Üst seviye iş kurallarını somut teknoloji sınıflarına doğrudan bağımlı hâle getirmemelisiniz.

Örneğin PricingService, PremiumDiscount sınıfını doğrudan oluşturmak yerine DiscountStrategy arayüzünü kullanır.

Bu tercih, test edilebilirliği ve bağımlılıkların yönetimini iyileştirir.

Hangi Tasarım Deseni Ne Zaman Kullanılmalı?

Tasarım deseni seçerken sınıf isimlerinden önce değişiklik ihtiyacına odaklanın.

Bu tabloyu kesin seçim kuralları olarak değerlendirmeyin. Aynı problem farklı bağlamlarda farklı çözümler gerektirebilir.

Örneğin yalnızca iki seçenek içeren sabit bir algoritma için switch ifadesi yeterli olabilir. Yeni algoritmaların bağımsız ekipler tarafından geliştirildiği bir sistemde ise Strategy daha güçlü bir tercih hâline gelir.

Spring Boot Projelerinde Tasarım Desenleri

Spring Framework, birçok tasarım deseninin fikirlerini kendi altyapısında kullanır.

Bununla birlikte framework kullanmak, desenleri öğrenme ihtiyacını ortadan kaldırmaz.

Dependency Injection ve Strategy

Spring, aynı arayüzün farklı implementasyonlarını bean olarak yönetebilir.

Bir ödeme servisinde farklı PaymentStrategy sınıfları tanımlayıp uygun olanı çalışma anında seçebilirsiniz.

Ancak seçimin nerede gerçekleşeceğini açıkça tasarlamalısınız. Bir servisin Spring ApplicationContext üzerinden sürekli bean araması, gizli bağımlılıklar yaratabilir.

Constructor Injection çoğu durumda daha açık bir bağımlılık modeli sunar.

Spring Event Modeli ve Observer

Spring’in ApplicationEventPublisher mekanizması, uygulama içinde olay yayınlama yaklaşımını destekler.

@EventListener kullanan bileşenler ilgili olaylara tepki verebilir.

Fakat uygulama içi olay yayınlamak ile dağıtık mesajlaşma arasında teslimat ve dayanıklılık açısından önemli farklar bulunur.

Spring AOP ve Decorator

Spring AOP, belirli metot çağrılarına ek davranış bağlamayı kolaylaştırır.

Transaction yönetimi, metrik toplama ve bazı loglama senaryoları buna örnek olabilir.

Bu yapı klasik Decorator ile aynı uygulama tekniğini kullanmak zorunda değildir. Benzer sorumluluk ayrımı hedeflerine farklı mekanizmalarla ulaşabilir.

Spring’in sunduğu soyutlamalar, tasarım kararının neden gerekli olduğunu anlamadığınızda karmaşıklığı gizleyebilir. Bu nedenle framework mekanizmasını seçmeden önce çözmek istediğiniz bağımlılık problemini tanımlayın.

Tasarım Desenlerini Kullanırken Yapılan Yaygın Hatalar

Her Problem İçin Desen Aramak

Bir metot üç satırda anlaşılır biçimde çalışıyorsa onu beş sınıfa bölmek kod kalitesini otomatik olarak artırmaz.

Soyutlama maliyetini karşılayacak somut bir değişiklik ihtiyacı olmalı.

Gereksiz Singleton Kullanımı

Singleton, hızlı erişim sunduğu için cazip görünür. Ancak kontrolsüz global durum, özellikle paralel testlerde ve eşzamanlı işlemlerde sorun çıkarabilir.

Factory ile Dependency Injection’ı Karıştırmak

Factory nesne oluşturma sorumluluğunu ele alır.

Dependency Injection ise nesnenin ihtiyaç duyduğu bağımlılıkları dışarıdan almasına odaklanır.

Bir uygulama her iki yaklaşımı birlikte kullanabilir.

Observer ile Güvenilir Mesajlaşmayı Eşdeğer Görmek

Uygulama içindeki bir Observer mekanizması, olayları otomatik olarak kalıcı tutmaz.

Bir listener hata verdiğinde veya uygulama kapandığında ne olacağını ayrıca tasarlamanız gerekir.

Sırf Tasarım Deseni Kullanmak İçin Arayüz Açmak

Her somut sınıfın mutlaka bir arayüze ihtiyacı yoktur.

Arayüz, gerçek bir sözleşmeyi veya anlamlı bir değişkenlik noktasını temsil ediyorsa değer kazandırır.

Tek implementasyonu bulunan ve alternatif davranış ihtiyacı taşımayan bir sınıf için erken soyutlama gereksiz olabilir.

Tasarım Deseni Seçerken Sorulması Gereken Sorular

Kodun içine yeni bir desen yerleştirmeden önce şu sorulara yanıt verin:

1. Hangi somut problemle karşı karşıyayım?
2. Bu problem bugün gerçekten var mı, yoksa geleceğe ilişkin bir tahmin mi?
3. Mevcut kod değişikliklere hangi noktada direnç gösteriyor?
4. Daha basit bir Java dil özelliği aynı sorunu çözebilir mi?
5. Yeni soyutlama birim testleri kolaylaştıracak mı?
6. Bu tasarımı altı ay sonra okuyacak geliştirici niyetimi anlayabilecek mi?
7. Deseni kaldırırsam kod daha basit ve anlaşılır hâle gelir mi?

Bu sorular özellikle refactoring sırasında önemlidir.

Refactoring sürecinde önce değişiklik maliyetinin yüksek olduğu bölgeyi bulun. Sonra yeni yapının gerçekten bu maliyeti azaltıp azaltmadığını testlerle doğrulayın.

Sık Sorulan Sorular

Java’da en çok kullanılan tasarım desenleri hangileridir?

Strategy, Factory, Builder, Adapter, Observer ve Decorator, Java backend uygulamalarında sık karşılaşılan desenler arasındadır. Ancak kullanım sıklığı framework’e, mimariye ve projenin ihtiyaçlarına göre değişir.

Java’da tasarım deseni kullanmak zorunlu mu?

Hayır. Tasarım desenleri dilin zorunlu bileşenleri değildir. Geliştirici, kodun bakımını ve genişletilmesini kolaylaştırdığı durumlarda bu çözümleri tercih eder.

Factory ile Builder arasındaki fark nedir?

Factory hangi nesnenin oluşturulacağını veya nesne oluşturma sürecinin hangi bileşen tarafından yönetileceğini ele alır. Builder ise özellikle çok adımlı ve çok parametreli nesne oluşturma süreçlerine odaklanır.

Strategy ile State arasındaki fark nedir?

Strategy, aynı amaca yönelik farklı algoritmalar arasında seçim yapmayı hedefler.

State ise bir nesnenin kendi yaşam döngüsündeki mevcut durumuna bağlı davranışları yönetir.

İki desen benzer sınıf yapıları kullanabilir; ancak tasarım niyetleri farklıdır.

Java Record, Builder kullanımını gereksiz kılar mı?

Hayır. Record, veri odaklı sınıflarda tekrarlayan kodu azaltır. Builder ise karmaşık oluşturma süreçlerini ve çok sayıdaki isteğe bağlı parametreyi yönetmeye devam edebilir.

Java 21 ile klasik tasarım desenleri hâlâ gerekli mi?

Evet. Java 21’in sealed türleri ve pattern matching özellikleri bazı çözümleri sadeleştirir. Ancak nesnelerin sorumluluklarını ayırmak, bağımlılıkları yönetmek ve değişebilir davranışları modellemek hâlâ tasarım kararları gerektirir.

Sonuç: İyi Tasarım, Doğru Soyutlamayı Seçmekle Başlar

Java tasarım desenleri, geliştiriciye her problem için uygulanacak sabit kurallar sunmaz. Tekrar eden tasarım sorunlarını çözmek için ortak bir düşünme biçimi kazandırır.

Singleton nesne yaşam döngüsüne, Factory nesne oluşturma kararlarına, Builder karmaşık yapılandırmalara odaklanır. Adapter ve Decorator bileşenlerin birlikte çalışma biçimini düzenler. Strategy, Observer ve State ise davranışların nasıl değişeceğini ve bileşenlerin nasıl iletişim kuracağını ele alır.

Java 17 ve Java 21, bu kararları uygularken daha güçlü dil araçları sunuyor. Ancak kısa kod her zaman iyi tasarım anlamına gelmez; daha fazla sınıf da otomatik olarak daha iyi mimari oluşturmaz.

Bir deseni seçmeden önce kodun hangi nedenle değiştiğini, hangi bağımlılıkların sorun çıkardığını ve ekleyeceğiniz soyutlamanın gerçek faydasını değerlendirin.

İyi bir tasarım deseni, kodu karmaşık göstermek için değil, değişikliği daha kolay yönetmek için vardır.

Kaynaklar ve İleri Okuma

1. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.
2. Joshua Bloch — Effective Java, Third Edition, Addison-Wesley, 2018.
3. Robert C. Martin — Clean Architecture, Prentice Hall, 2017.
4. Oracle — Java SE 21 Language Documentation: https://docs.oracle.com/en/java/javase/21/language/
5. OpenJDK — JEP 395, Records: https://openjdk.org/jeps/395
6. OpenJDK — JEP 409, Sealed Classes: https://openjdk.org/jeps/409
7. OpenJDK — JEP 441, Pattern Matching for switch: https://openjdk.org/jeps/441
8. Refactoring.Guru — Design Patterns in Java: https://refactoring.guru/design-patterns/java

Java Tasarım Desenleri (Design Patterns): Gerçek Hayat Örnekleri ve Modern Java yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Agile yaklaşım, ekiplere değişime uyum sağlama yeteneği kazandırır. Ancak bir ekip yalnızca Scrum toplantıları düzenleyerek veya Jira üzerinde sprint oluşturarak çevik hale gelmez. Ekip aynı zamanda kod kalitesini, test otomasyonunu, sürekli entegrasyonu, kod incelemeyi, gözlemlenebilirliği ve teknik borç yönetimini günlük çalışma biçiminin bir parçası haline getirmelidir.

Başka bir ifadeyle Agile, yalnızca proje yönetimi metodolojisi değildir. Agile yaklaşım, ürün geliştirme kültürünü ve mühendislik disiplinini birlikte şekillendirir.

Bu yazıda Agile proje yönetimi ile yazılım mühendisliği pratiklerinin nasıl birlikte çalışması gerektiğini, ekiplerin hangi hataları yaptığını ve sürdürülebilir bir Agile geliştirme kültürünün nasıl kurulabileceğini detaylı şekilde inceleyeceğiz.

Agile Proje Yönetimi Nedir?

Agile proje yönetimi, büyük projeleri uzun süreli ve katı planlarla yönetmek yerine işi küçük parçalara ayırmayı ve düzenli geri bildirimlerle ilerlemeyi hedefler.

Geleneksel proje yönetiminde ekipler çoğunlukla şu akışı takip eder:

Gereksinim analizi → Tasarım → Geliştirme → Test → Canlıya geçiş

Bu yaklaşım bazı projelerde çalışabilir. Ancak yazılım projelerinde gereksinimler sıklıkla değişir. Kullanıcı beklentileri farklılaşır, teknik kısıtlar ortaya çıkar veya pazar koşulları yeni öncelikler doğurur.

Agile yaklaşım ise ekibin kısa geri bildirim döngüleri oluşturmasını sağlar.

Ekip:

• işi küçük parçalara böler,
• öncelikli işleri önce geliştirir,
• çalışan yazılım üretir,
• kullanıcıdan geri bildirim toplar,
• elde ettiği verilerle sonraki adımı belirler.

Böylece ekip aylar sonra büyük bir ürün teslim etmek yerine düzenli aralıklarla değer üretir.

Agile Olmak Scrum Kullanmak Anlamına Gelmez

Yazılım sektöründeki en yaygın hatalardan biri Agile ile Scrum kavramlarını aynı şey olarak değerlendirmektir.

Scrum, Agile prensiplerini uygulamak için kullanılan çerçevelerden biridir.

Ancak bir ekip şu etkinlikleri gerçekleştiriyor olabilir:

• Daily Scrum,
• Sprint Planning,
• Sprint Review,
• Retrospective,
• Backlog Refinement.

Buna rağmen ekip hâlâ çevik olmayabilir.

Örneğin yönetim ekibi bütün kararları önceden veriyorsa, geliştiriciler yalnızca kendilerine verilen görevleri uyguluyorsa ve ekip kullanıcı geri bildirimlerini dikkate almıyorsa yapılan Scrum toplantıları tek başına Agile kültürü oluşturmaz.

Agile yaklaşımın merkezinde toplantılar değil, hızlı geri bildirim ve sürekli değer üretimi bulunur.

Agile Proje Yönetimi Neden Mühendislik Pratiklerine İhtiyaç Duyar?

Bir ekip iki haftalık sprintler kullanabilir ve düzenli olarak backlog yönetebilir. Ancak ekip yeterli mühendislik disiplinine sahip değilse geliştirme hızı kısa sürede düşer.

Örneğin ekip sürekli yeni özellik geliştiriyor fakat otomatik test yazmıyorsa hata sayısı artar.

Kod inceleme süreci bulunmuyorsa kod kalitesi ekip üyelerine göre değişir.

Continuous Integration kullanılmıyorsa entegrasyon problemleri büyür.

Teknik borç kontrol edilmezse küçük değişiklikler bile zamanla büyük geliştirme maliyetlerine dönüşür.

Bu nedenle Agile proje yönetimi ekiplerin ne geliştireceğini ve hangi öncelikle geliştireceğini yönetirken mühendislik pratikleri ekibin yazılımı nasıl sürdürülebilir şekilde geliştireceğini belirler.

İki yaklaşım birlikte çalıştığında ekip hem hızlı hem de güvenilir yazılım üretebilir.

Başarılı Agile Ekiplerinin Kullandığı Mühendislik Pratikleri

1. Küçük ve Yönetilebilir İş Parçaları Oluşturun

Agile geliştirme sürecinde büyük işler belirsizliği artırır.

Örneğin ekip backlog’a şu şekilde bir iş ekleyebilir:

Ödeme sistemini geliştir.

Bu iş oldukça geniştir. Analiz, geliştirme ve test sırasında birçok bilinmeyen ortaya çıkabilir.

Bunun yerine ekip işi daha küçük parçalara bölebilir:

• kredi kartı ödeme ekranını oluştur,
• ödeme doğrulama servisini geliştir,
• başarısız ödeme akışını yönet,
• ödeme sonucunu kullanıcıya göster,
• işlem kayıtlarını oluştur.

Küçük işler ekiplerin daha doğru tahmin yapmasını ve daha hızlı geri bildirim almasını sağlar.

Ayrıca küçük değişiklikler kod inceleme sürecini kolaylaştırır.

2. Definition of Done Kullanın

Bir geliştiricinin “iş tamamlandı” demesi her zaman aynı anlama gelmez.

Bir geliştirici kodu yazınca işi tamamlanmış kabul edebilir. Başka bir geliştirici testler tamamlandığında işin bittiğini düşünebilir.

Bu farklılık ekip içinde belirsizlik yaratır.

Bu nedenle ekip açık bir Definition of Done oluşturmalıdır.

Örneğin bir iş ancak aşağıdaki koşullar gerçekleştiğinde tamamlanmış sayılabilir:

• geliştirme tamamlandı,
• unit testler yazıldı,
• gerekli integration testler çalışıyor,
• kod incelemesi tamamlandı,
• güvenlik kontrolleri geçti,
• CI pipeline başarılı oldu,
• gerekli dokümantasyon güncellendi,
• acceptance criteria karşılandı.

Definition of Done kalite konusunda ortak bir ekip standardı oluşturur.

3. Code Review Sürecini Standartlaştırın

Code review yalnızca hataları bulmak için kullanılmaz.

İyi bir kod inceleme süreci ekip üyeleri arasında bilgi paylaşımını artırır ve ortak kod standartları oluşturur.

Reviewer şu konuları değerlendirebilir:

• kod okunabilir mi?
• gereksiz karmaşıklık var mı?
• mevcut mimariye uygun mu?
• güvenlik problemi oluşturuyor mu?
• hata durumları yönetiliyor mu?
• testler yeterli mi?
• kod tekrarına neden oluyor mu?

Ancak code review sürecini bir onay mekanizmasına dönüştürmemek gerekir.

Amaç geliştiriciyi denetlemek değil, ürünün teknik kalitesini artırmaktır.

4. Continuous Integration Kullanın

Geliştiriciler kodlarını uzun süre ayrı branch’lerde tuttuğunda entegrasyon problemleri büyür.

Bu nedenle ekip mümkün olduğunca sık entegrasyon yapmalıdır.

Continuous Integration sürecinde geliştirici kodunu repository’ye gönderdiğinde otomatik süreçler çalışır.

Örneğin pipeline:

1. projeyi build eder,
2. unit testleri çalıştırır,
3. integration testleri çalıştırır,
4. static code analysis gerçekleştirir,
5. güvenlik kontrollerini çalıştırır,
6. gerekli kalite kontrollerini uygular.

Pipeline hata verirse ekip problemi hızlı şekilde çözer.

Böylece ekip entegrasyon hatalarını geliştirme sürecinin sonunda değil, ortaya çıktıkları anda yakalar.

5. Test Otomasyonuna Yatırım Yapın

Manuel test süreçları büyüyen yazılım projelerinde tek başına yeterli olmaz.

Her yeni özellik mevcut fonksiyonları etkileyebilir.

Bu nedenle ekip otomatik testlerden oluşan güçlü bir güvenlik ağı kurmalıdır.

Ekip farklı seviyelerde test kullanabilir:

• Unit Test
• Integration Test
• API Test
• Contract Test
• End-to-End Test

Ancak ekip yalnızca test sayısını artırmayı hedeflememelidir.

Testlerin gerçekten davranışı doğrulaması gerekir.

Örneğin yüzlerce anlamsız unit test yüksek test coverage değeri üretebilir ancak gerçek hataları yakalamayabilir.

Bu nedenle ekip coverage oranını tek başına kalite metriği olarak değerlendirmemelidir.

6. Teknik Borcu Backlog İçinde Yönetin

Teknik borç yazılım projelerinde tamamen ortadan kaldırılamaz.

Bazen ekip hızlı karar almak zorunda kalır. Bazen zaman baskısı nedeniyle ideal çözüm yerine daha basit bir çözüm uygular.

Problem teknik borcun oluşması değildir.

Problem teknik borcun görünmez hale gelmesidir.

Ekip teknik borcu backlog içinde takip etmelidir.

Örneğin:

• eski kütüphaneleri güncelle,
• tekrar eden kodları refactor et,
• yavaş çalışan sorguyu optimize et,
• eski API endpoint’lerini kaldır,
• kritik modül için otomatik test ekle.

Ürün yöneticisi ve mühendislik ekibi teknik borcun ürün üzerindeki etkisini birlikte değerlendirmelidir.

7. Refactoring İçin Ayrı Proje Beklemeyin

Bazı ekipler aylar boyunca yeni özellik geliştirir ve daha sonra büyük bir “refactoring projesi” başlatmayı planlar.

Bu yaklaşım genellikle başarısız olur.

Çünkü ürün geliştirme hiçbir zaman tamamen durmaz.

Bunun yerine ekip refactoring çalışmalarını günlük geliştirme sürecinin doğal bir parçası haline getirmelidir.

Geliştirici bir modülde değişiklik yaparken gerektiğinde:

• karmaşık metotları sadeleştirebilir,
• isimlendirmeleri düzeltebilir,
• kod tekrarlarını azaltabilir,
• testleri iyileştirebilir.

Küçük ve sürekli iyileştirmeler büyük refactoring projelerinin oluşmasını engeller.

8. Trunk-Based Development Yaklaşımını Değerlendirin

Uzun yaşayan feature branch’ler entegrasyon riskini artırabilir.

Branch haftalar boyunca açık kaldığında ana kod tabanı değişmeye devam eder. Daha sonra merge işlemi büyük çatışmalar oluşturabilir.

Trunk-Based Development yaklaşımı geliştiricilerin küçük değişiklikleri sık şekilde ana geliştirme hattına entegre etmesini teşvik eder.

Bu yaklaşımı desteklemek için ekip:

• küçük commitler oluşturabilir,
• kısa yaşayan branch’ler kullanabilir,
• feature flag mekanizması uygulayabilir,
• güçlü CI pipeline kurabilir.

Böylece ekip büyük entegrasyon problemlerini azaltabilir.

9. Feature Flag Kullanarak Deployment ile Release Sürecini Ayırın

Bir özelliğin production ortamına deploy edilmesi, kullanıcıların özelliği hemen kullanması gerektiği anlamına gelmez.

Feature flag yaklaşımı deployment ile release kavramlarını birbirinden ayırır.

Ekip yeni özelliği production ortamına gönderebilir ancak özelliği kapalı tutabilir.

Daha sonra özelliği:

• belirli kullanıcılara,
• belirli müşteri gruplarına,
• belirli ülkelere,
• küçük bir kullanıcı yüzdesine

açabilir.

Bu yaklaşım kontrollü yayın yapmayı kolaylaştırır ve operasyonel riski azaltır.

10. Observability Sistemlerini Geliştirme Sürecine Dahil Edin

Bir özelliğin production ortamına çıkması geliştirme sürecinin sonu değildir.

Ekip uygulamanın gerçek ortamda nasıl davrandığını takip etmelidir.

Bu nedenle ekip üç temel gözlemlenebilirlik kaynağını kullanabilir:

• Logs
• Metrics
• Traces

Bu veriler sayesinde ekip yalnızca “sistem çalışıyor mu?” sorusunu değil, “sistem neden bu şekilde davranıyor?” sorusunu da cevaplayabilir.

Örneğin bir API’nin cevap süresi yükseldiğinde ekip metric verileriyle problemi tespit edebilir, tracing ile çağrı zincirini inceleyebilir ve log kayıtlarıyla kök nedeni araştırabilir.

11. Güvenliği Sprint Sonuna Bırakmayın

Güvenlik kontrollerini geliştirme bittikten sonra gerçekleştirmek hem maliyeti hem de riski artırır.

Bu nedenle ekip güvenliği geliştirme yaşam döngüsünün başından itibaren ele almalıdır.

DevSecOps yaklaşımı bu noktada önemli avantaj sağlar.

CI/CD pipeline içinde örneğin şu kontroller çalışabilir:

• SAST,
• dependency scanning,
• secret scanning,
• container image scanning,
• IaC security scanning.

Bunun yanında ekip threat modeling ve secure coding pratiklerini geliştirme sürecine dahil edebilir.

Güvenlik ekibi yalnızca release öncesinde kontrol yapan bir kapı görevi görmemelidir. Güvenlik uzmanları yazılım ekipleriyle birlikte çalışmalıdır.

Agile Takımlarında Product Owner ve Teknik Ekibin İlişkisi

Başarılı Agile ekiplerinde ürün ve mühendislik birbirinden kopuk çalışmaz.

Product Owner genellikle şu konulara odaklanır:

• müşteri ihtiyacı,
• ürün değeri,
• iş öncelikleri,
• ürün hedefleri.

Mühendislik ekibi ise şu konulara odaklanır:

• teknik tasarım,
• mimari,
• performans,
• güvenlik,
• bakım maliyeti,
• teknik borç.

Ancak iki tarafın tamamen bağımsız karar vermesi doğru sonuç üretmez.

Örneğin Product Owner yalnızca özellik geliştirmeye odaklanır ve teknik borcu sürekli ertelerse geliştirme hızı zamanla düşebilir.

Aynı şekilde mühendislik ekibi iş değerini dikkate almadan sürekli teknik mükemmellik peşinde koşarsa ürün geliştirme maliyeti artabilir.

Bu nedenle ekip iş değeri ile teknik sürdürülebilirlik arasında denge kurmalıdır.

Agile Takımlarında Velocity Nasıl Kullanılmalı?

Velocity, bir ekibin sprint içinde tamamladığı iş miktarını anlamaya yardımcı olabilir.

Ancak yöneticiler velocity değerini performans metriğine dönüştürdüğünde ciddi problemler ortaya çıkar.

Örneğin:

Takım A: 40 story point

Takım B: 60 story point

Bu değerlerden yola çıkarak Takım B’nin daha üretken olduğunu söyleyemezsiniz.

Her takım story point değerlerini kendi bağlamında belirler.

Daha önemlisi ekip velocity değerinin hedef olduğunu düşündüğünde puanları yükseltmeye başlayabilir.

Sonuç olarak metrik anlamını kaybeder.

Velocity ekiplerin kapasite planlamasına yardımcı olabilir. Ancak bireysel veya ekip performansını ölçmek için kullanılmamalıdır.

Agile Projelerde Ölçülmesi Gereken Metrikler

Yazılım ekipleri yalnızca “kaç story tamamladık?” sorusuna odaklanmamalıdır.

Daha dengeli metrikler kullanmak gerekir.

Örneğin ekip şu göstergeleri takip edebilir:

Lead Time

Bir ihtiyacın ortaya çıkmasından kullanıcıya ulaşmasına kadar geçen süreyi gösterir.

Cycle Time

Ekibin bir iş üzerinde aktif olarak çalışmaya başlamasından işi tamamlamasına kadar geçen süreyi ölçer.

Deployment Frequency

Ekibin production ortamına ne sıklıkla deployment yaptığını gösterir.

Change Failure Rate

Production ortamına yapılan değişikliklerin ne kadarının hata veya incident oluşturduğunu ölçmeye yardımcı olur.

Mean Time to Restore

Bir problem oluştuğunda sistemin ne kadar hızlı normale döndüğünü anlamaya yardımcı olur.

Defect Escape Rate

Test süreçlerinden geçerek production ortamına ulaşan hataları takip etmeyi sağlar.

Bu metrikler birlikte değerlendirildiğinde ekip hem hız hem de kalite konusunda daha anlamlı sonuçlar elde eder.

Agile Takımlarının En Sık Yaptığı Hatalar

Agile’ı Toplantı Sistemine Dönüştürmek

Daily yapmak ekibi otomatik olarak Agile yapmaz.

Toplantılar iletişim aracıdır. Amaç değildir.

Her etkinlik ekip için gerçek bir değer üretmelidir.

Sprint İçinde Sürekli Yeni İş Eklemek

Sprint başladıktan sonra sürekli yeni işler eklemek ekip odağını bozar.

Gerçek acil durumlar dışında ekip planlanan sprint hedefini korumalıdır.

Teknik Borcu Sürekli Ertelemek

Her sprint yalnızca yeni özellik geliştirmek kısa vadede hızlı görünür.

Ancak teknik borç zamanla geliştirme hızını ciddi şekilde düşürebilir.

Geliştiricileri Story Point ile Karşılaştırmak

Story point bireysel performans metriği değildir.

Bir geliştiricinin 20 point, diğerinin 10 point tamamlaması ilk geliştiricinin iki kat üretken olduğunu göstermez.

Her Sorunu Yeni Bir Toplantıyla Çözmeye Çalışmak

Agile ekiplerin iletişim kurmasını teşvik eder fakat gereksiz toplantılar geliştirme zamanını azaltır.

Asenkron iletişim birçok durumda daha verimli olabilir.

Sprint’i Mini Waterfall’a Dönüştürmek

Bazı ekipler iki haftalık sprinti şu şekilde kullanır:

İlk hafta analiz ve geliştirme.

İkinci hafta test.

Bu yaklaşım sprint içinde küçük bir Waterfall modeli oluşturur.

Bunun yerine analiz, geliştirme ve test faaliyetleri sprint boyunca birlikte ilerlemelidir.

Etkili Bir Agile Yazılım Ekibi Nasıl Kurulur?

Güçlü bir Agile kültür oluşturmak için yalnızca süreçleri değiştirmek yeterli değildir.

Ekip çalışma biçimini de değiştirmelidir.

Başlangıç için şu yaklaşım uygulanabilir:

1. Ürün hedeflerini netleştirin.
2. Backlog’u iş değerine göre önceliklendirin.
3. Büyük işleri küçük parçalara bölün.
4. Definition of Done oluşturun.
5. Code review standardı belirleyin.
6. CI pipeline kurun.
7. Test otomasyonunu geliştirin.
8. Teknik borcu backlog içinde görünür hale getirin.
9. Deployment süreçlerini otomatikleştirin.
10. Production metriklerini takip edin.
11. Retrospective toplantılarında gerçek aksiyonlar belirleyin.
12. Belirlenen aksiyonların uygulanıp uygulanmadığını takip edin.

Burada en kritik nokta sürekli iyileştirmedir.

Agile dönüşüm bir proje değildir.

“Agile’a geçtik ve dönüşüm tamamlandı” yaklaşımı Agile felsefesine ters düşer.

Ekipler çalışma biçimlerini sürekli değerlendirmeli ve geliştirmelidir.

Agile Kültüründe Retrospective Neden Önemlidir?

Retrospective toplantısı birçok ekipte şu üç sorudan oluşur:

• Ne iyi gitti?
• Ne kötü gitti?
• Neyi geliştirebiliriz?

Ancak ekip yalnızca problemleri konuşuyor ve hiçbir aksiyon almıyorsa toplantı zamanla değerini kaybeder.

İyi bir retrospective sonunda ekip az sayıda fakat uygulanabilir aksiyon belirlemelidir.

Örneğin:

Problem: Pull Request’ler uzun süre bekliyor.

Aksiyon: Takım üyeleri günde iki kez açık Pull Request’leri kontrol edecek.

Bir sonraki retrospective toplantısında ekip bu aksiyonun işe yarayıp yaramadığını değerlendirebilir.

Bu yaklaşım retrospective toplantısını şikâyet toplantısından çıkararak sürekli iyileştirme mekanizmasına dönüştürür.

Agile Proje Yönetiminde Teknik Liderin Rolü

Teknik lider Agile ekip içinde yalnızca mimari karar veren kişi olmamalıdır.

İyi bir teknik lider:

• ekip üyelerinin karar süreçlerine katılmasını sağlar,
• teknik riskleri görünür hale getirir,
• mühendislik standartlarını geliştirir,
• teknik borcu yönetir,
• bilgi paylaşımını destekler,
• karmaşık problemlerde ekibe rehberlik eder.

Bununla birlikte teknik lider bütün kararları tek başına almamalıdır.

Ekibin teknik karar alma yeteneğini geliştirmek uzun vadede çok daha sürdürülebilir sonuç üretir.

Sonuç: Agile ile Mühendislik Disiplinini Birlikte Yönetin

Agile proje yönetimi ekiplerin değişime hızlı cevap vermesini ve müşteriye daha sık değer sunmasını sağlar. Ancak güçlü mühendislik pratikleri olmadan bu hız sürdürülebilir hale gelmez.

Başarılı yazılım ekipleri yalnızca sprint planlamaz.

Aynı zamanda:

• küçük değişiklikler geliştirir,
• kod incelemesi yapar,
• otomatik testler oluşturur,
• sürekli entegrasyon uygular,
• teknik borcu yönetir,
• güvenliği geliştirme sürecine dahil eder,
• production sistemlerini gözlemler,
• geri bildirimlerden öğrenir.

Dolayısıyla gerçek Agile yaklaşımı, proje yönetimi ile yazılım mühendisliğini birbirinden ayırmaz.

Agile süreç ekiplerin doğru işi geliştirmesine, mühendislik pratikleri ise bu işi doğru şekilde geliştirmesine yardımcı olur.

Bu iki disiplin birlikte çalıştığında ekip yalnızca daha hızlı yazılım üretmez. Aynı zamanda daha kaliteli, sürdürülebilir ve değişime daha dayanıklı ürünler geliştirir.

Agile Proje Yönetimi ve Mühendislik Pratikleri: Başarılı Yazılım Ekipleri Nasıl Çalışır? yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Açıkcası idle konumda olan bir bilgisayarın 6GB seviyelerinde RAM kullanımı benim için can sıkıcı bir durum. Üstelik tamamen debloat etmiş olmama rağmen bunu yaşamak baya canımı sıktı. Zaten debloat etmeden önce de arka planda toplanıp en uygun zamanda gönderilen telemetry verilerini yazmıyorum bile. Her ne kadar geri çekseler de Windows ReCall gibi bir ürün, kullanıcı için mide bulandırıcı.

Windows Recall, kullanıcının masaüstünün ekran görüntüsünü birkaç saniye aralıklarla alır ve ardından cihaz üzerinde çalışan büyük dil modellerini kullanarak kullanıcının daha önce ekranında bulunan öğeleri ve bilgileri geri getirmesini sağlar. Bu özellik, Mayıs 2024’te Microsoft tarafından, GPT-4o’nun Microsoft Copilot’a entegrasyonu ve Windows 11’deki yenilenmiş kullanıcı arayüzüyle birlikte duyuruldu. – Wikipedia

CachyOS Seçme Sebebim Neydi?

Arch Linux tabanlı olması ama Arch’a göre daha kolay kurulması bu sebeplerin başında geliyor. İkinci sebep ise oyun desteği. Bu başlı başına CachyOs’in bir özellliği olmasa da paket işlemlerini kurulumdan sonra kolayca halledebilmek cezbedici bir konuma koyuyor kendisini.

Peki asıl sebep oyun mu; tabii ki hayır. CachyOs güncel işlemcilere özel olarak derleniyor bu da performans konusunda bize ekstra bir avantaj sağlıyor.

Şu ana kadar da bahsi geçen diğer işletim sisteminin eksikliğini de gram hissetmedim. Ama özellikle oyun konusunda bir not da düşmek lazım. Benim oynadığım oyunların hiç birinde bir sorun yaşamadım. Bu oyunlara Microsoft Studios oyunu olan Age Of Empires 4’de dahil. Ama kernel based anti cheat kullanan bir oyun oynuyorsanız onları oynayamayacağınızı söyleyeyim.

Seçim sebeplerimin bazıları ise teknik olduğundan dolayı onları burada yazmak istemiyorum. Genel hatları ile yukarıda yazdığım sebepler diyebiliriz.

GNU/Linux’a geçeceğim, hangi dağıtımı kullanmalıyım?

Bu tamamen sizin kullanım amacınıza bağlı bir seçim. Türkiye’den çıkmış bir distro yani dağıtım kullanmak için buradaki dağıtımları inceleyebilirsiniz. Benim önerim ise Pardus ve Pisi Linux olacaktır. Yukarıda bağlantısını verdiğim DistroWatch üzerinden de incelemeler yapabilirsiniz.

Eğer ben hızlıca isteklerimi seçeyim de bana bir dağıtım önersin diyorsanız; Distro Pusulasına bakabilirsiniz.

Distro Pusulası Nedir?

Distro pusulası dört tane soru ile sizin kullanımınıza uygun olabilecek GNU/Linux dağıtımları öneriyor. Algoritması şu an yeterli olsa da daha ne kadar geliştirebilirim diye üzerinde çalışacağım. Üzerindeki çalışmam bittiğinde de açık kaynak olarak yayınlamayı düşünüyorum.

Şimdilik bu kadar yazdığım yeter. Zaten yeni tema ile birlikte yazı sürümleri de güncelleme yapılan tarih ile birlikte gösteriliyor. Eğer tamamlayabilirsem şu an bu yazıyı okuduğun temayı da açık kaynak olarak yayınlayacağım.

Hoş geldin CachyOS, Güle güle Windows yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Hizmet keşfi, yük dengeleme ve konfigürasyon yönetiminin hangi bölümü uygulamaya, hangi bölümü platforma ait olmalıdır?

Spring Cloud, Eureka ve Consul gibi çözümler bu sorumlulukları uygulama seviyesine yaklaştırır. Kubernetes DNS ve Kubernetes Service temel ağ yeteneklerini altyapı seviyesinde sunar. Istio gibi Service Mesh ürünleri ise merkezi trafik politikaları, gözlemlenebilirlik ve servisler arası güvenlik katmanı ekler.

Doğru seçim yalnızca servis sayısına bağlı değildir. Ekip sayısı, kullanılan programlama dilleri, dağıtım ortamı, güvenlik gereksinimleri ve organizasyonun platform işletme kapasitesi birlikte değerlendirilmelidir.

Kısa cevap: Hangi sorumluluk kime verilmeli?

Kubernetes üzerinde çalışan yeni sistemler için genel mimari öneri şöyledir:

• Hizmet keşfi: Kubernetes Service ve DNS
• Temel yük dengeleme: Kubernetes ağ katmanı
• Gelişmiş L7 trafik politikaları: İhtiyaç varsa Istio
• İş anlamı taşıyan retry, fallback ve idempotency: Uygulama
• Dağıtım konfigürasyonu: ConfigMap ve GitOps
• Dinamik uygulama konfigürasyonu: Gerekiyorsa Spring Cloud Config veya Consul
• Hassas bilgiler: KMS veya harici secret manager

Kubernetes dışında çalışan veya VM, container ve farklı veri merkezlerini birlikte kullanan hibrit sistemlerde Consul güçlü bir alternatiftir. Tamamen Java tabanlı daha küçük yapılarda Eureka da yeterli olabilir.

Aynı sorumluluğu hem Spring Cloud hem Kubernetes tarafında kalıcı olarak çözmek ise genellikle gereksiz karmaşıklık yaratır.

Service Discovery nedir?

Service discovery, bir servisin iletişim kuracağı diğer servislerin güncel ağ adreslerini bulmasını sağlar.

Mikroservis instance’ları ölçekleme, yeniden başlatma veya hata nedeniyle sürekli değişebilir. Bu nedenle uygulamaların sabit IP adreslerine bağlanması sürdürülebilir değildir. Bir servis kataloğu veya kararlı platform adresi gerekir.

Spring Cloud Eureka ile hizmet keşfi

Eureka modelinde uygulamalar açılırken kendilerini merkezi registry’ye kaydeder ve düzenli heartbeat gönderir. İstemciler, çağırmak istedikleri servisin instance listesini Eureka’dan alır.

Güncel Spring Cloud mimarisinde Eureka hizmet keşfini sağlarken istemci tarafı yük dengeleme Spring Cloud LoadBalancer tarafından gerçekleştirilir. Varsayılan seçim round-robin’dir; farklı seçim stratejileri de uygulanabilir. Spring Cloud Netflix, Spring Cloud LoadBalancer

Bu yaklaşım özellikle şu koşullarda anlamlıdır:

• Sistem ağırlıklı olarak Spring Boot kullanıyorsa
• Servisler VM veya bare metal üzerinde çalışıyorsa
• Kubernetes’e geçiş henüz tamamlanmadıysa
• Uygulama seviyesinde instance metadata’sına göre seçim gerekiyorsa

Eureka’nın temel dezavantajı, discovery bilgisini uygulama çalışma zamanının bir parçası hâline getirmesidir. Her servis registry istemcisi taşır; kütüphane sürümleri ve cache davranışları sistemin ağ davranışını etkiler.

Consul ile hizmet keşfi

Consul; servis kataloğu, sağlık kontrolleri, HTTP API ve DNS tabanlı keşif sunar. Spring Cloud Consul kullanan uygulamalar HTTP API üzerinden kayıt olabilirken Java dışındaki uygulamalar aynı kataloğa DNS aracılığıyla erişebilir. Spring Cloud Consul

Consul’un Eureka’ya göre en önemli avantajı platform ve dil bağımsızlığıdır. VM, container, Kubernetes ve farklı veri merkezlerinin birlikte bulunduğu yapılarda ortak bir servis kataloğu oluşturabilir.

Bunun karşılığında Consul cluster’ının yüksek erişilebilir biçimde kurulması, izlenmesi, yükseltilmesi ve güvenliğinin sağlanması gerekir.

Kubernetes Service Discovery

Kubernetes’te Pod IP adresleri geçicidir. Uygulamaların bağlandığı kararlı kimlik Service nesnesidir.

CoreDNS, Kubernetes servisleri için DNS kayıtları oluşturur. Kubernetes de bir servise bağlı güncel Pod listesini EndpointSlice nesneleri üzerinden takip eder. Böylece uygulama http://orders gibi kararlı bir servis adına bağlanabilir. Registry SDK’sı, heartbeat veya istemci tarafında instance listesi yönetmesi gerekmez. Kubernetes Service, Kubernetes DNS

Bu modelin başlıca avantajları şunlardır:

• Programlama dilinden bağımsızdır.
• Uygulamayı discovery kodundan arındırır.
• Pod yaşam döngüsü ile endpoint yönetimini aynı kontrol düzlemine bağlar.
• Platform genelinde standart servis adresleme modeli oluşturur.
• Kubernetes kullanılıyorsa ek registry işletme ihtiyacını ortadan kaldırır.

Bu nedenle Kubernetes üzerinde çalışan yeni bir sistemde yalnızca hizmet keşfi için Eureka kurmak çoğunlukla gereksizdir.

Spring Cloud LoadBalancer ve Kubernetes Service farkı

Spring Cloud LoadBalancer ile Kubernetes Service aynı sorunu farklı katmanlarda çözer.

İstemci tarafı yük dengeleme

Spring Cloud LoadBalancer modelinde uygulama:

1. Discovery sisteminden instance listesini alır.
2. Uygun instance’ı seçer.
3. İsteği doğrudan o instance’a gönderir.

Bu model, istemcinin metadata, bölge veya özel iş bağlamına göre hedef seçmesine olanak tanır. Buna karşılık seçim mantığı her uygulamanın içine dağılır.

Altyapı tarafı yük dengeleme

Kubernetes Service modelinde uygulama tek bir servis adresine bağlanır. Trafiğin uygun Pod’a aktarılması kube-proxy veya kullanılan ağ altyapısı tarafından gerçekleştirilir.

Bu yaklaşım uygulamayı sadeleştirir ve farklı dillerde yazılmış servisler arasında standart davranış sağlar. Ancak temel Kubernetes Service; HTTP header’ına göre yönlendirme, yüzdesel canary veya request-level circuit breaking gibi gelişmiş L7 politikaları sunmaz.

Ayrıca uzun süre açık kalan HTTP/2 veya gRPC bağlantıları dikkatle değerlendirilmelidir. DNS ya da endpoint kümesi değişse bile connection pool aynı backend’e trafik göndermeyi sürdürebilir.

Istio trafik yönetimine ne ekler?

Istio, Kubernetes service discovery mekanizmasının yerine geçmez. Kubernetes servis ve endpoint bilgisini kullanır; bunun üzerine programlanabilir bir trafik katmanı ekler.

Istio ile merkezi olarak şu politikalar uygulanabilir:

• Ağırlıklı ve sürüm bazlı yönlendirme
• Canary ve aşamalı dağıtım
• HTTP header veya path bazlı routing
• Timeout ve retry
• Circuit breaking
• Sağlıksız instance’ları havuzdan çıkarma
• Trafik yansıtma
• Servisler arası mTLS
• Kimlik tabanlı erişim politikaları
• Ortak trafik metriği ve erişim kayıtları

Istio’nun trafik modeli Envoy proxy’leri kullanır. Sidecar modelinde her Pod’un yanında bir proxy çalışır. Ambient modelde temel L4 işlevleri node seviyesinde sağlanabilir; L7 özellikleri gerektiğinde waypoint proxy devreye girer. Istio Traffic Management, Istio veri düzlemi modelleri

Istio’nun avantajları

• Farklı dillerdeki servisler için ortak ağ politikası sağlar.
• Trafik davranışı uygulama sürümünden bağımsız değiştirilebilir.
• Canary ve progressive delivery süreçlerini kolaylaştırır.
• mTLS ve servis kimliğini merkezi hâle getirir.
• Gözlemlenebilirlik standardı oluşturur.
• Politika yönetimini platform ekibinde toplar.

Istio’nun maliyetleri

• Yeni bir kontrol ve veri düzlemi işletilir.
• Proxy’ler CPU, bellek ve belirli ölçüde gecikme ekler.
• Hata ayıklama süreci daha karmaşık hâle gelir.
• Yanlış bir merkezi politika çok sayıda servisi etkileyebilir.
• Proxy ve kontrol düzlemi yükseltmeleri dikkatle yönetilmelidir.
• Platform ekibinde Service Mesh uzmanlığı gerekir.

Dolayısıyla Istio, “mikroservis kullanıyoruz” gerekçesiyle kurulacak bir bileşen değildir. Sağladığı merkezi politika değeri, işletme maliyetini geçtiğinde kullanılmalıdır.

Konfigürasyon yönetimi: Spring Cloud Config mi ConfigMap mi?

Konfigürasyon yönetimi, service discovery ve trafik yönetiminden ayrı ele alınmalıdır. Istio uygulamanın iş konfigürasyonunu yönetmez.

Spring Cloud Config

Spring Cloud Config, uygulama ayarlarını merkezi bir servis üzerinden sunar. Git deposu kullanıldığında değişiklik geçmişi, sürümleme ve ortam bazlı konfigürasyon yönetimi elde edilir.

Şu durumlarda güçlüdür:

• Uygulamalar Kubernetes dışında da çalışıyorsa
• Spring profile modeli yoğun kullanılıyorsa
• Uygulama ve ortam bazlı konfigürasyon hiyerarşisi gerekiyorsa
• Konfigürasyonun deployment’tan bağımsız yenilenmesi isteniyorsa

Dezavantajı, Config Server’ın uygulama başlangıcında ek bir bağımlılığa dönüşmesidir. Dinamik refresh sırasında bütün bean’lerin ve bağlantı havuzlarının yeni değerlerle güvenli biçimde çalışacağı da garanti değildir.

Consul Config

Spring Cloud Consul Config, Consul KV üzerinden uygulama ayarlarını yükleyebilir. Config Watch, ilgili değerlerde değişiklik algılandığında Spring refresh olayı oluşturabilir. Spring Cloud Consul Config

Discovery için zaten Consul kullanılan hibrit sistemlerde operasyonel açıdan çekici olabilir. Ancak aynı Consul cluster’ının hem discovery hem konfigürasyon için kullanılması hata alanını büyütür. Consul kesintisinin iki kritik fonksiyonu birden etkilemesi hesaba katılmalıdır.

Kubernetes ConfigMap

Kubernetes ConfigMap, hassas olmayan uygulama ayarlarını container imajından ayırır. Değerler ortam değişkeni veya volume içindeki dosyalar olarak Pod’a aktarılabilir.

Volume olarak bağlanan ConfigMap güncellemeleri zaman içinde Pod’a yansıtılabilir; fakat uygulamanın dosyayı yeniden okuması gerekir. Ortam değişkeni olarak verilen ConfigMap değerleri otomatik güncellenmez ve Pod yeniden başlatılmalıdır. Kubernetes ConfigMap

Birçok üretim sistemi için kontrollü rolling restart, dinamik context refresh’ten daha güvenlidir. Yeni konfigürasyon yeni Pod’larda doğrulanır; readiness kontrolü başarısız olursa rollout durdurulabilir.

Kubernetes Secret yeterli mi?

Kubernetes Secret nesnesi kullanmak tek başına güvenli secret yönetimi anlamına gelmez. Secret verileri varsayılan olarak etcd içinde şifrelenmeden saklanabilir.

Üretim ortamında şu kontroller gerekir:

• Encryption-at-rest
• Sıkı RBAC
• Secret erişim kayıtları
• Düzenli rotasyon
• Tercihen KMS veya harici secret manager entegrasyonu

Kubernetes Secret güvenlik önerileri

Retry ve circuit breaker uygulamada mı mesh’te mi olmalı?

Bu sorumluluk bütünüyle tek bir katmana verilemez.

Mesh şu teknik kararları üstlenebilir:

• Bağlantı kurulamazsa farklı endpoint denemek
• Belirli hata kodlarında sınırlı retry yapmak
• Sağlıksız instance’ı geçici olarak havuzdan çıkarmak
• Ağ seviyesinde timeout standardı uygulamak

Uygulamada kalması gereken kararlar ise şunlardır:

• Bir ödeme isteği güvenle tekrar edilebilir mi?
• İşlem idempotent mi?
• Hangi fallback iş açısından kabul edilebilir?
• Kısmi başarı nasıl yönetilmeli?
• Telafi işlemi gerekiyor mu?

Mesh, bir HTTP isteğinin teknik olarak tekrar edilebilir göründüğünü anlayabilir; fakat tekrarın ikinci kez tahsilat yaratıp yaratmayacağını bilemez.

Ayrıca uygulama ve mesh bağımsız retry yaptığında deneme sayıları çarpılır. Uygulamadaki üç deneme ile mesh’teki üç deneme, tek kullanıcı isteğini dokuz downstream çağrısına dönüştürebilir. Retry bütçesi uçtan uca tasarlanmalıdır.

Proje ölçeğine göre mimari tercih

Servis sayıları kesin sınır değildir. Ekip sayısı, teknoloji çeşitliliği, güvenlik gereksinimi ve dağıtım sıklığı daha belirleyicidir.

Küçük projeler: 1–2 ekip ve yaklaşık 3–10 servis

Kubernetes üzerinde çalışılıyorsa:

• Kubernetes DNS ve Service kullanın.
• ConfigMap ve kontrollü rolling deployment tercih edin.
• Istio kurmayın.
• Timeout, idempotency ve iş fallback’lerini uygulamada yönetin.

Bu ölçekte Service Mesh’in işletme ve öğrenme maliyeti genellikle faydasından büyüktür.

VM veya karma altyapıda çalışılıyorsa:

• Tamamen Java tabanlı sistemlerde Eureka kullanılabilir.
• Birden fazla dil veya çalışma ortamı varsa Consul tercih edilebilir.
• Discovery ihtiyacı tek başına Kubernetes’e geçiş gerekçesi olmamalıdır.

Orta ölçekli projeler: 3–8 ekip ve yaklaşık 10–50 servis

Kubernetes’i varsayılan discovery ve temel load-balancing katmanı yapın. Yeni servislerin ayrıca Eureka’ya kaydolmasını istemeyin.

Istio’yu şu ihtiyaçlar somutlaştığında değerlendirin:

• Takımlar arasındaki retry ve timeout farklılıkları üretim olaylarına yol açıyorsa
• Merkezi canary dağıtımı gerekiyorsa
• Servisler arası mTLS zorunluysa
• Polyglot yapı ortak ağ telemetrisi gerektiriyorsa
• Merkezi erişim politikaları yönetilecekse

Mesh’e geçiş kritik servis veya namespace’lerle kademeli olarak başlatılabilir.

Büyük projeler: 8’den fazla ekip, 50+ servis veya çoklu cluster

Bu ölçekte her uygulama ekibinin aynı ağ politikalarını farklı kütüphanelerle uygulaması sürdürülemez hâle gelebilir.

Önerilen sorumluluk dağılımı:

Mesh’in anlamlı olmasını sağlayan yalnızca servis sayısı değildir. Merkezi güvenlik, çoklu dil desteği, yüksek dağıtım sıklığı ve çapraz takım standardizasyonu operasyon maliyetini karşılayacak düzeye ulaşmalıdır.

Kaçınılması gereken yaklaşım: Çift sahiplik

Geçiş dönemi dışında şu kombinasyonlardan kaçınılmalıdır:

• Eureka ve Kubernetes’in paralel servis kataloğu olması
• Spring Cloud LoadBalancer ile Istio’nun bağımsız hedef seçmesi
• Uygulama, API gateway ve mesh’in ayrı ayrı retry uygulaması
• Timeout değerlerinin farklı katmanlarda çelişmesi
• Aynı ayarın Consul KV ve ConfigMap’te tutulması

Her teknik sorumluluk için tek bir birincil doğruluk kaynağı ve açık bir sahip belirlenmelidir.

Sonuç: Spring Cloud mu Kubernetes mi?

Spring Cloud ve Kubernetes birbirlerinin tam alternatifi değildir.

Spring Cloud uygulamaya discovery ve istemci davranışı kazandırır. Kubernetes temel platform bağlantısını ve servis yaşam döngüsünü yönetir. Istio ise ortak trafik, güvenlik ve gözlemlenebilirlik politikalarını uygulamadan ayırır.

Kubernetes kullanan yeni sistemlerde service discovery ve temel load balancing platforma bırakılmalıdır. Istio yalnızca servis sayısı arttığı için değil, ortak trafik ve güvenlik politikalarının uygulama ekipleri tarafından ayrı ayrı yönetilmesi sürdürülemez hâle geldiğinde eklenmelidir.

Kubernetes dışında veya ciddi hibrit altyapıda Consul güçlü bir seçimdir. Tamamen Java ve VM tabanlı küçük sistemlerde Eureka hâlâ yeterli olabilir. Kubernetes’e yerleşmiş bir platformda Eureka’yı kalıcı biçimde tutmak ise çoğunlukla aynı gerçeği iki kontrol düzleminde yönetmek anlamına gelir.

Sağlıklı sorumluluk ayrımı şöyledir:

• Platform, servisin nerede olduğunu bilir.
• Mesh, trafiğin teknik olarak nasıl akacağını bilir.
• Uygulama, isteğin iş açısından ne anlama geldiğini bilir.
• Konfigürasyon sistemi, uygulamanın hangi değerlerle çalışacağını bilir.

İyi mimari, bu sınırların açık olduğu ve aynı kararın birden fazla katmanda tekrar verilmediği mimaridir.

Sık sorulan sorular

Kubernetes kullanırken Eureka gerekli mi?

Çoğu yeni Kubernetes sistemi için hayır. Kubernetes Service, DNS ve EndpointSlice temel hizmet keşfi ihtiyacını karşılar. Eureka ancak Kubernetes dışındaki servislerle geçiş, özel metadata tabanlı seçim veya güçlü bir mevcut bağımlılık varsa geçici olarak anlamlı olabilir.

Kubernetes Service, Istio’nun yerini tutar mı?

Hayır. Kubernetes Service temel servis adresleme ve L4 yönlendirme sağlar. Istio ise canary, header tabanlı routing, mTLS, retry, circuit breaking ve ayrıntılı trafik gözlemlenebilirliği gibi gelişmiş politikalar ekler.

Küçük bir mikroservis projesinde Istio kullanılmalı mı?

Genellikle hayır. Birkaç servis ve tek ekipten oluşan sistemlerde operasyonel maliyet çoğu zaman kazanımdan yüksektir. Önce Kubernetes’in yerleşik özellikleri ve doğru uygulama timeout’ları kullanılmalıdır.

Consul mu Eureka mı daha uygun?

Tamamen Spring Boot kullanan sınırlı bir sistemde Eureka daha basit olabilir. Birden fazla dil, VM, container, veri merkezi veya hibrit altyapı söz konusuysa Consul daha geniş bir entegrasyon alanı sunar.

Konfigürasyon değişikliği için dinamik refresh mi rolling restart mı?

Çoğu üretim konfigürasyonu için rolling restart daha öngörülebilir ve geri alınabilir bir modeldir. Feature flag gibi anlık değişmesi gereken değerlerde kontrollü dinamik konfigürasyon tercih edilebilir.

Spring Cloud vs. Kubernetes: Service Discovery ve Trafik Yönetimi Kime Emanet Edilmeli? yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Yeni bir instance’ın JVM’i başlatması, sınıfları yüklemesi, framework context’ini oluşturması ve kodu optimize etmesi zaman alır. İstek trafiğinin olmadığı bir sürenin ardından fonksiyon yeniden oluşturuluyorsa kullanıcı bu maliyeti doğrudan “cold start” gecikmesi olarak hisseder.

GraalVM Native Image, Java uygulamasını dağıtım öncesinde makine koduna derleyerek bu denklemi değiştirir. Uygulama, çalışma anında JAR ve tam bir JVM başlatmak yerine işletim sistemi üzerinde doğrudan çalışan platforma özgü bir executable olarak açılır. GraalVM belgelerine göre native executable yalnızca erişilebilir uygulama ve JDK kodunu, gerekli çalışma zamanı bileşenlerini ve statik olarak bağlanan yerel kodu içerir; bunun sonucu milisaniyeler düzeyinde başlangıç, warm-up gerektirmeyen performans ve daha düşük kaynak tüketimidir. (GraalVM Native Image belgeleri)

Cold start neden oluşur?

Bir Java mikroservisinin ilk isteğe hazır hâle gelmeden önce tipik olarak şu işlemleri tamamlaması gerekir:

1. JVM süreci başlatılır.
2. Uygulama sınıfları ve bağımlılıklar yüklenir.
3. Bytecode doğrulanır ve yorumlanmaya başlanır.
4. Spring ApplicationContext oluşturulur.
5. Bean tanımları, koşullu konfigürasyonlar ve proxy’ler hazırlanır.
6. Sık çalışan kod yolları belirlenir ve JIT compiler tarafından optimize edilir.
7. Bağlantı havuzları ve harici servis istemcileri hazırlanır.

Uzun süre çalışan bir serviste bu maliyet yalnızca bir kez ödenir ve JIT optimizasyonları zaman içinde önemli throughput avantajı sağlar. Buna karşılık serverless platformlarda, scale-to-zero kullanan Kubernetes ortamlarında veya çok sık pod oluşturan sistemlerde başlangıç maliyeti tekrar tekrar ödenebilir.

Cold start yalnızca uygulamanın main metoduna ulaşma süresi değildir. Gerçek ölçüm, yeni instance’ın ilk isteğe doğru yanıt verebildiği ana kadar geçen süreyi kapsamalıdır.

JIT ve AOT arasındaki mimari fark

JIT: Çalışırken öğrenen optimizasyon

Geleneksel JVM modelinde Java kaynak kodu önce bytecode’a çevrilir:

Java kaynak kodu
        ↓
     Bytecode
        ↓
 JVM + Interpreter
        ↓
   JIT Compiler
        ↓
Optimize makine kodu

JIT, uygulamanın gerçek çalışma davranışını gözlemler. Hangi metotların sık çağrıldığını, dallanmaların hangi yönde ilerlediğini ve hangi kod yollarının “hot” olduğunu belirleyerek bu bölümleri çalışma sırasında optimize eder.

Bunun önemli bir avantajı vardır: Optimizasyon kararları gerçek trafik profilinden beslenir. Uzun süre çalışan ve CPU yoğun işlem yapan servislerde JVM, yeterli warm-up sonrasında çok yüksek tepe performansına ulaşabilir.

Bedeli ise JVM’in, derleyicinin, profil verilerinin ve sınıf metadata’sının bellekte bulunmasıdır. Uygulama ayrıca en iyi performansına hemen değil, belirli bir ısınma süresinden sonra ulaşır.

AOT: Çalışmadan önce tamamlanan derleme

GraalVM Native Image, bytecode’u build aşamasında analiz eder ve platforma özgü makine koduna dönüştürür:

Uygulama + bağımlılıklar + JDK sınıfları
                    ↓
      Erişilebilirlik analizi
                    ↓
       AOT optimizasyon ve derleme
                    ↓
 Kod + image heap + native runtime
                    ↓
        Native executable

Analiz main metodu gibi giriş noktalarından başlar. Erişilebilen sınıflar, metotlar ve alanlar tekrarlı biçimde bulunur; kullanılmadığı belirlenen parçalar native executable’a eklenmez. Derlemeden sonra yeni program elemanlarının çalışma anında sisteme eklenememesi “closed-world assumption”, yani kapalı dünya varsayımı olarak adlandırılır. (Native Image çalışma modeli)

Bazı sınıflar build sırasında initialize edilebilir. Oluşan nesneler ve statik durum “image heap” içerisine kaydedilir. Uygulama açıldığında bu işlerin yeniden yapılmaması startup süresini kısaltır.

AOT her durumda JIT’ten daha hızlı demek değildir. Native Image’ın temel avantajı başlangıç ve kaynak verimliliğidir. Uzun süre çalışan, CPU yoğun servislerde JIT’in çalışma zamanı profiline dayanan optimizasyonları daha yüksek throughput sağlayabilir. GraalVM’in Profile-Guided Optimization özelliği, temsilî trafikten profil toplayıp bunu AOT derlemeye taşıyarak aradaki farkı azaltabilir. (GraalVM optimizasyon belgeleri)

Startup süresi ve memory footprint üzerindeki etkisi

Native executable çalıştırılırken tam bir HotSpot JVM’in başlatılmasına ve uygulama kodunun JIT tarafından ısıtılmasına gerek kalmaz. Gereksiz sınıfların binary’ye alınmaması da class metadata, JIT code cache ve derleyici altyapısının çalışma zamanı maliyetlerini azaltır.

Cloud-native sistemlerde bu özellikler üç alanda değer üretir:

• Serverless fonksiyonlar ilk isteğe daha kısa sürede cevap verebilir.
• Kubernetes pod’ları daha hızlı hazır duruma gelerek scale-out gecikmesini azaltabilir.
• Aynı bellek bütçesi içerisinde daha fazla servis instance’ı çalıştırılabilir.

Ancak sonucu tek bir evrensel yüzdeyle ifade etmek doğru değildir. Kazanç; kullanılan framework’e, dependency sayısına, heap ayarlarına, GC seçimine, container limitlerine ve uygulamanın başlangıç sırasında yaptığı I/O işlemlerine bağlıdır.

Örneğin uygulama açılışta veritabanı migrasyonu çalıştırıyor veya uzak bir secret servisine bağlanıyorsa native executable bu ağ gecikmesini ortadan kaldırmaz. GraalVM kod başlatma maliyetini azaltır; dış sistemlerin gecikmesini sihirli biçimde çözmez.

Bu nedenle JVM ve native sürümleri aynı koşullarda karşılaştırın:

# JVM sürümü
/usr/bin/time -v java -jar target/cold-start-demo.jar

# Native sürüm
/usr/bin/time -v ./target/cold-start-demo

macOS üzerinde ayrıntılı süreç ölçümü için:

/usr/bin/time -l ./target/cold-start-demo

Yalnızca konsoldaki “Started” mesajını değil, aşağıdaki metrikleri kaydedin:

• Process başlangıcından readiness durumuna kadar geçen süre
• İlk isteğin p50, p95 ve p99 gecikmesi
• Warm request gecikmesi
• Peak RSS ve steady-state RSS
• CPU tüketimi
• Binary veya container image boyutu
• Native image build süresi
• Gerçek trafik altındaki throughput

GraalVM Native Image’ın zorlandığı alanlar

1. Reflection

Reflection kullanılan kodda çağrılacak sınıf veya metot adı çalışma anında bir konfigürasyondan gelebilir. Statik analiz bu ilişkiyi göremiyorsa ilgili sınıfın kullanılmadığını düşünerek onu binary dışında bırakabilir.

Sonuç olarak uygulama başarıyla derlense bile yalnızca belirli bir endpoint çağrıldığında hata verebilir. JSON serileştirme, ORM, dependency injection ve plugin tabanlı kütüphaneler bu açıdan özellikle test edilmelidir.

Spring Boot 3’ün AOT motoru controller dönüş tipleri, bean tanımları ve pek çok framework kullanımına ait hint’leri otomatik üretir. Otomatik çıkarımın yetmediği durumlarda @RegisterReflectionForBinding veya RuntimeHintsRegistrar kullanılabilir. (Spring Boot özel native hint rehberi)

Örneğin çalışma anında JSON’a dönüştürülecek bir sınıfı açıkça kaydetmek için:

import org.springframework.aot.hint.annotation.RegisterReflectionForBinding;
import org.springframework.context.annotation.Configuration;

@Configuration
@RegisterReflectionForBinding(PaymentRequest.class)
class NativeConfiguration {
}

2. Dynamic proxy

Spring AOP, declarative transaction yönetimi ve bazı HTTP client kütüphaneleri çalışma anında proxy oluşturabilir. JVM üzerinde ihtiyaç anında üretilebilen bu sınıfların native executable içinde önceden bilinmesi gerekir.

Spring AOT, kendi tanıyabildiği proxy’leri build sırasında üretir. Uygulamaya özgü bir JDK proxy için runtime hint eklenebilir:

import org.springframework.aot.hint.RuntimeHints;
import org.springframework.aot.hint.RuntimeHintsRegistrar;

class ApplicationRuntimeHints implements RuntimeHintsRegistrar {

    @Override
    public void registerHints(
            RuntimeHints hints,
            ClassLoader classLoader) {

        hints.proxies().registerJdkProxy(PaymentClient.class);
    }
}

Registrar’ı uygulamaya bağlayalım:

import org.springframework.context.annotation.ImportRuntimeHints;

@SpringBootApplication
@ImportRuntimeHints(ApplicationRuntimeHints.class)
public class PaymentApplication {

    public static void main(String[] args) {
        SpringApplication.run(PaymentApplication.class, args);
    }
}

Spring’in CGLIB tabanlı proxy’leri de JVM’de çalışma anında oluşturulurken native build sürecinde önceden üretilir. Oluşturulan proxy sınıfları Maven projelerinde target/spring-aot/main/classes altında incelenebilir. (Spring AOT proxy üretimi)

3. Classpath kaynakları

JSON şablonları, sertifikalar, SQL dosyaları, localization bundle’ları veya statik dosyalar Java kodu olmadığı için yalnızca erişilebilirlik analiziyle her zaman bulunamaz.

Bir kaynağı Spring runtime hints API ile eklemek mümkündür:

@Override
public void registerHints(
        RuntimeHints hints,
        ClassLoader classLoader) {

    hints.resources().registerPattern("templates/*.json");
    hints.resources().registerPattern("db/migration/**");
}

GraalVM ayrıca META-INF/native-image altındaki reachability-metadata.json dosyalarını okuyabilir:

{
  "resources": [
    {
      "glob": "templates/*.json"
    }
  ]
}

Native executable içine gömülen kaynaklar gerçek bir dosya sistemi yolu olmayabilir. Bu nedenle URL#getFile() yerine getResourceAsStream() veya URL#openStream() tercih edilmelidir. Gerekli metadata bulunmayan dinamik erişimler çalışma zamanı hatasına dönüşebilir. (GraalVM Reachability Metadata)

Spring Boot 3 ile native executable oluşturma

Aşağıdaki örnek Maven tabanlı bir Spring Boot 3 projesini temel alır.

Adım 1: Projeyi oluşturun

start.spring.io üzerinden şu seçimlerle bir proje oluşturabilirsiniz:

• Java 21 gibi desteklenen bir LTS sürümü
• Spring Boot 3.x
• Maven
• Spring Web
• GraalVM Native Support

Basit bir endpoint ekleyelim:

package com.example.coldstart;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@SpringBootApplication
public class ColdStartApplication {

    @GetMapping("/hello")
    String hello() {
        return "Hello from GraalVM Native Image";
    }

    public static void main(String[] args) {
        SpringApplication.run(ColdStartApplication.class, args);
    }
}

Adım 2: Maven plugin’lerini kontrol edin

Spring Boot parent’ın sağladığı native profilinden yararlanmak için build bölümünde şu plugin’ler bulunmalıdır:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>

        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Spring AOT işlemi ApplicationContext’i build aşamasında analiz eder; bean tanımlarına ve kapalı dünya varsayımına uygun optimize edilmiş kod ile GraalVM hint dosyaları üretir. Maven çıktıları target/spring-aot altında incelenebilir. (Spring Boot AOT belgeleri)

Adım 3: Yerel native executable üretin

Makinede kullandığınız Java sürümüyle uyumlu bir GraalVM dağıtımı ve gerekli native toolchain kurulu olmalıdır. Ardından:

./mvnw -Pnative native:compile

Executable varsayılan olarak target dizininde oluşur:

./target/cold-start-demo

Servisi doğrulayın:

curl http://localhost:8080/hello

Gradle kullanan projelerde GraalVM Native Build Tools plugin’i uygulandıktan sonra eşdeğer komutlar şunlardır:

./gradlew nativeCompile
./build/native/nativeCompile/cold-start-demo

Adım 4: Buildpack ile native container image oluşturun

Yerel GraalVM kurulumu yerine Docker ve Cloud Native Buildpacks kullanabilirsiniz:

./mvnw -Pnative spring-boot:build-image

Oluşan image’ı çalıştırın:

docker run --rm -p 8080:8080 \
  docker.io/library/cold-start-demo:0.0.1-SNAPSHOT

Gradle karşılığı:

./gradlew bootBuildImage

Spring Boot, Maven ve Gradle üzerinden Paketo buildpack ile JVM içermeyen native container image üretilmesini destekler. (Spring Boot native uygulama rehberi)

Native Image doğrudan cross-compilation yapmadığından executable hedef işletim sistemi ve CPU mimarisi için üretilmelidir. Örneğin Linux AMD64 ile Linux ARM64 artefact’larını ayrı runner’larda veya uygun multi-platform build altyapısında oluşturmak gerekir.

Adım 5: Native test çalıştırın

Normal JVM testleri hızlı geri bildirim sağlar; ancak kapalı dünya varsayımından kaynaklanan sorunları yakalamak için native test de CI sürecine eklenmelidir:

./mvnw -Pnative native:test

Gradle için:

./gradlew nativeTest

Özellikle şu yolları test edin:

• JSON serialization ve deserialization
• Reflection kullanan kod
• AOP ve transaction proxy’leri
• Dosya, template ve resource bundle erişimi
• SSL ve güvenlik sağlayıcıları
• ORM entity’leri
• Dinamik olarak seçilen implementasyonlar

Adım 6: Eksik metadata’yı tracing agent ile bulun

Spring’in otomatik hint üretiminin yetmediği eski veya uyumsuz bir kütüphanede uygulamayı önce JVM üzerinde tracing agent ile çalıştırabilirsiniz:

java -Dspring.aot.enabled=true \
  -agentlib:native-image-agent=config-output-dir=target/native-agent \
  -jar target/cold-start-demo.jar

Uygulamanın kritik akışlarını çalıştırdıktan sonra oluşan metadata’yı inceleyin. Gerekli dosyalar kontrollü biçimde src/main/resources/META-INF/native-image/ altına taşınabilir.

Tracing agent yalnızca çalıştırılan yolları görür. Eksiksiz test kapsamı yoksa gerekli metadata’nın bir kısmı yine atlanabilir; üretilen dosyaları körlemesine kabul etmek yerine sadeleştirmek ve doğrulamak gerekir. GraalVM’in agent’ı reflection, proxy, JNI ve resource erişimlerini kaydedebilir. (GraalVM tracing agent rehberi)

Üretim ortamı için mimari öneriler

GraalVM Native Image özellikle şu iş yüklerinde güçlü bir seçenektir:

• Trafiği düzensiz serverless fonksiyonlar
• Scale-to-zero kullanan servisler
• Çok hızlı yatay ölçeklenmesi gereken API’ler
• Düşük bellek limitli container’lar
• CLI uygulamaları ve kısa ömürlü batch işler
• Edge veya yoğun çoklu servis ortamları

Buna karşılık aşağıdaki durumlarda geleneksel JVM seçeneğini ayrıca benchmark etmek gerekir:

• Günlerce çalışan CPU yoğun servisler
• Yoğun dinamik class loading veya plugin mimarisi
• Native desteği zayıf üçüncü taraf kütüphaneler
• Çok sık değişen runtime bean yapıları
• Derleme süresi ve CI kaynak maliyetinin kritik olduğu projeler

İyi bir cloud-native strateji bütün servisleri zorunlu olarak native’e çevirmek değildir. Cold start ve bellek baskısı yaşayan sınır servislerini native executable olarak çalıştırırken, uzun ömürlü ve throughput odaklı servisleri JVM üzerinde bırakmak daha dengeli olabilir.

Sonuç

GraalVM Native Image, Java’nın serverless ve mikroservis mimarilerindeki en görünür dezavantajlarından ikisini doğrudan hedefler: cold start gecikmesi ve yüksek memory footprint.

AOT derleme; erişilebilir kodu, gerekli runtime bileşenlerini ve belirli başlangıç durumlarını build aşamasında native executable içine taşır. Böylece uygulama hızlı açılır, warm-up ihtiyacı azalır ve daha küçük bir çalışma zamanı belleğiyle hizmet verebilir.

Bu kazanımın karşılığında closed-world assumption nedeniyle reflection, dynamic proxy, serialization ve classpath kaynaklarının daha bilinçli yönetilmesi gerekir. Spring Boot 3’ün AOT altyapısı bu işin büyük bölümünü otomatikleştirir; RuntimeHints, reachability metadata, tracing agent ve native testler ise kalan boşlukları kapatır.

Doğru karar için son adım her zaman aynıdır: JVM ve native sürümü gerçek trafik profiliniz, hedef container limitleriniz ve ölçeklenme modeliniz altında ölçün. Cold start kritikse GraalVM Native Image çoğu zaman yalnızca bir optimizasyon değil, doğrudan mimari bir avantajdır.

Sık Sorulan Sorular

GraalVM Native Image tamamen JVM’siz mi çalışır?

Üretilen executable’ın yanında ayrı bir HotSpot JVM bulunmaz. Ancak binary; garbage collector, thread desteği ve gerekli çalışma zamanı servisleri gibi Native Image runtime bileşenlerini içerir.

Native Image her Java uygulamasında daha hızlı mıdır?

Hayır. Başlangıç süresi genellikle çok daha iyidir; fakat uzun süre çalışan ve CPU yoğun uygulamalarda JIT daha yüksek tepe throughput sağlayabilir. Karar benchmark sonucuna göre verilmelidir.

Spring Boot 3 reflection sorunlarını otomatik çözer mi?

Spring AOT birçok yaygın kullanım için gerekli hint’leri otomatik üretir. Uygulamaya özel reflection, dinamik proxy veya üçüncü taraf kütüphane kullanımlarında ek runtime hint gerekebilir.

Native executable bir kez üretilip her platformda çalıştırılabilir mi?

Hayır. Binary hedef işletim sistemi ve CPU mimarisine özeldir. Linux, macOS, AMD64 ve ARM64 hedefleri için uygun ortamlarda ayrı build alınmalıdır.

GraalVM Native Image serverless maliyetini azaltır mı?

Daha hızlı startup ve düşük bellek tüketimi, platformun fiyatlandırma modeline bağlı olarak süre ve kaynak maliyetini azaltabilir. Kesin kazanç ancak gerçek provider, trafik ve bellek ayarlarıyla yapılan ölçüm sonucunda belirlenebilir.

GraalVM Native Image ile Serverless ve Mikroservislerde Cold Start Sorununu Çözmek yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Özellikle onlarca veya yüzlerce gigabaytlık heap kullanan sistemlerde ortalama GC süresine bakmak yeterli değildir. Kullanıcı deneyimini ve servis seviyesi hedeflerini çoğunlukla p99, p99.9 ve p99.99 gecikmeleri belirler. Bu nedenle doğru soru “Hangi GC daha hızlı?” değil, “Bu iş yükünün gecikme, throughput ve kaynak tüketimi hedefleri için hangi GC daha uygun?” olmalıdır.

G1 GC, dengeli throughput ve öngörülebilir duraklamalar sağlamayı amaçlayan genel kullanıma yönelik bir collector’dır. ZGC ise daha fazla işi uygulamayla eş zamanlı yürüterek çok büyük heap’lerde dahi ultra düşük duraklama sürelerini hedefler.

Oracle’ın güncel sınıflandırmasına göre G1 “mostly concurrent”, ZGC ise “fully concurrent” bir collector’dır. Oracle, yanıt süresinin en yüksek öncelik olduğu sistemlerde ZGC’yi başlangıç seçeneği olarak önermektedir. Bununla birlikte ZGC’nin düşük duraklama avantajı, iş yüküne bağlı CPU ve bellek maliyetleriyle birlikte değerlendirilmelidir. Oracle Java 25 GC seçim rehberi

Kısa cevap: G1 GC mi, ZGC mi?

Aşağıdaki yaklaşım pratik bir başlangıç noktasıdır:

• Dengeli throughput, makul bellek tüketimi ve yüzlerce milisaniyenin altında tutulmak istenen GC duraklamaları için G1 GC güçlü bir varsayılan seçimdir.
• Onlarca ya da yüzlerce gigabaytlık heap, yüksek canlı veri miktarı ve tek haneli milisaniyelik uçtan uca gecikme hedefleri varsa ZGC öncelikli adaydır.
• CPU kapasitesi sınırlıysa veya en önemli hedef maksimum işlem hacmiyse, ZGC’nin concurrent çalışma maliyeti mutlaka ölçülmelidir.
• GC değişikliği sentetik mikro benchmark sonucuyla değil, üretime benzeyen yük, veri dağılımı ve allocation profiliyle doğrulanmalıdır.

ZGC düşük gecikme için güçlü bir mimari avantaj sağlar; fakat gerçek zamanlı bir collector değildir ve uygulama için kesin bir SLA garantisi vermez. İşletim sistemi zamanlaması, safepoint işlemleri, JIT derlemesi, disk erişimi, sayfa hataları, kilit rekabeti ve dış servisler de tail latency üretebilir.

G1 GC nasıl çalışır?

Garbage-First Garbage Collector, heap’i eşit büyüklükte bölgelere ayırır. Bu bölgeler sabit biçimde Eden, Survivor veya Old olarak ayrılmış değildir; ihtiyaç oldukça farklı roller üstlenebilir.

G1; generational, bölge tabanlı, evacuating ve çoğunlukla eş zamanlı çalışan bir collector’dır. Global canlılık analizi gibi pahalı işlerin bir bölümünü uygulama thread’leri çalışırken gerçekleştirir. Buna karşılık canlı nesnelerin seçilmiş bölgelerden başka bölgelere kopyalanması ağırlıklı olarak Stop-The-World duraklamaları içinde yapılır.

Oracle’ın tanımına göre G1, belirlenen pause-time hedefine yüksek olasılıkla ulaşmaya çalışır; ancak bu hedef her GC duraklaması için kesin bir üst sınır değildir. Oracle G1 GC mimarisi

G1 GC döngüsü

G1’in çalışma modeli iki ana dönem halinde düşünülebilir.

1. Young-only dönemi

Yeni nesilde biriken nesneler young collection ile toplanır. Yaşamaya devam eden nesneler Survivor bölgelerine veya yaşlarına göre Old Generation’a taşınır.

Young collection sırasında uygulama thread’leri durdurulur. G1, bir sonraki young generation boyutunu geçmiş duraklama sürelerinden ve kopyalanan canlı nesne miktarından yararlanarak hesaplar.

2. Concurrent marking ve space-reclamation dönemi

Old Generation doluluğu Initiating Heap Occupancy eşiğine ulaştığında G1 concurrent marking döngüsünü başlatır:

1. Bir Concurrent Start young collection yapılır.
2. Old Generation içindeki erişilebilir nesneler uygulamayla eş zamanlı işaretlenir.
3. Remark duraklamasında işaretleme sonuçlandırılır.
4. Cleanup aşamasında bölgelerin canlılık oranları hesaplanır.
5. Mixed collection’larda young bölgelerle birlikte seçilmiş old bölgeler de boşaltılır.

“Garbage-First” adı, collector’ın önce en fazla çöp içeren ve en verimli biçimde geri kazanılabilecek bölgeleri seçmesinden gelir.

G1’in pause-time modeli

-XX:MaxGCPauseMillis bir zaman sınırı değil, ergonomik bir hedeftir. G1, collection set’e eklenecek bölgelerin sayısını ve young generation büyüklüğünü bu hedefe göre ayarlamaya çalışır.

Örneğin 100 milisaniyelik hedef vermek, hiçbir GC duraklamasının 100 milisaniyeyi geçmeyeceği anlamına gelmez. Çok yüksek canlı nesne oranı, ani allocation artışı, reference processing, remembered set taraması veya humongous object yoğunluğu hedefin aşılmasına neden olabilir.

Remembered set ve card table maliyeti

G1, bölgeler arasındaki referansları bulabilmek için card table ve remembered set yapılarından yararlanır. Uygulama bir referans alanını değiştirdiğinde write barrier ilgili kartı işaretler. Böylece young collection sırasında bütün Old Generation’ın taranması gerekmez.

Bu mekanizma toplama işini sınırlar; ancak uygulama thread’lerine barrier maliyeti, ek metadata tüketimi ve remembered set bakım yükü getirir. Nesne grafiğinde çok yoğun bölge geçişleri bulunan sistemlerde bu maliyet görünür hale gelebilir.

Evacuation ve Full GC riski

G1, canlı nesneleri seçilmiş bölgelerden boş alanlara taşıyarak belleği sıkıştırır. Taşıma için yeterli boş bölge kalmazsa evacuation failure oluşabilir.

Concurrent marking allocation hızına yetişemez ve yeterli alan geri kazanılamazsa G1, son çare olarak Stop-The-World Full GC gerçekleştirebilir. Büyük heap’lerde bu durum saniyelere ulaşabilen ciddi latency sıçramaları oluşturabilir.

Humongous object davranışı

Boyutu bir G1 bölgesinin yarısından büyük olan nesneler “humongous” olarak değerlendirilir ve ardışık bölgelerde tutulur. Büyük byte dizileri, sıkıştırılmış mesajlar, cache blokları ve büyük JSON payload’ları bu kategoriye girebilir.

Humongous allocation:

• Heap parçalanmasını artırabilir.
• Concurrent marking döngüsünü erken başlatabilir.
• Ardışık boş bölge ihtiyacı doğurabilir.
• Full GC ve hatta OutOfMemoryError riskini yükseltebilir.

GC loglarında humongous region sayısı yüksekse ilk çözüm JVM bayrağı eklemek değil, büyük allocation kaynaklarını uygulama seviyesinde incelemek olmalıdır.

ZGC nasıl çalışır?

ZGC, ölçeklenebilir ve düşük gecikme odaklı, concurrent bir collector’dır. Marking, reference processing ve nesne relocation gibi pahalı işlerin büyük bölümünü uygulama thread’leri çalışırken gerçekleştirir.

Oracle’ın güncel rehberine göre ZGC’nin duraklama süreleri kullanılan heap boyutundan bağımsızdır ve collector birkaç yüz megabayttan 16 TB’a kadar heap’lerde çalışabilir. JDK 25 dokümantasyonu maksimum duraklamaları bir milisaniyenin altında hedefleyen çalışma modelini açıklamaktadır. Oracle ZGC rehberi

Buradaki kritik ifade “heap boyutundan bağımsız” olmasıdır. Bu, heap büyüdükçe concurrent toplam iş miktarının hiç artmadığı anlamına gelmez. Artan canlı veri daha fazla CPU zamanı ve daha uzun concurrent cycle gerektirebilir. Mimari avantaj, pahalı işin Stop-The-World penceresine taşınmamasıdır.

Generational ZGC ve JDK sürümü

ZGC’nin nesilleri kullanan sürümü JDK 21 ile kullanıma sunuldu. Generational ZGC, çoğu nesnenin genç yaşta öldüğü gözleminden yararlanarak young ve old nesilleri farklı sıklıklarda toplar.

Sürüm davranışı önemlidir:

• JDK 21 ve 22’de generational mod -XX:+ZGenerational ile etkinleştirilir.
• JDK 23’te generational mod varsayılan hale gelmiştir.
• JDK 24 itibarıyla non-generational ZGC kaldırılmış ve ZGenerational seçeneğine ihtiyaç kalmamıştır.

Dolayısıyla internetten kopyalanan eski bir JVM başlangıç satırı yeni JDK’da geçersiz olabilir. Bayraklar hedef JDK dağıtımı ve sürümü üzerinde doğrulanmalıdır. Oracle JDK 21 değişiklikleri ve Oracle JDK 24 değişiklikleri

Colored pointers

ZGC’nin temel yapı taşlarından biri colored pointer yaklaşımıdır. Nesne referansları yalnızca bellek adresi taşımaz; marking ve relocation durumuyla ilgili metadata da içerir.

Bu bilgi sayesinde JVM bir referansın:

• Geçerli GC görünümüne ait olup olmadığını,
• İşaretleme işlemi gerektirip gerektirmediğini,
• Nesnenin taşınmış olup olmadığını,
• Referansın güncellenmesi gerekip gerekmediğini

kontrol edebilir.

Colored pointer yaklaşımı, ZGC’nin nesneleri uygulama thread’leri çalışırken taşıyabilmesinin önemli nedenlerinden biridir.

Load ve store barrier’lar

Uygulama bir nesne referansını okuduğunda veya güncellediğinde JIT tarafından üretilen barrier kodu devreye girebilir. Barrier, referansın GC açısından güvenli ve güncel olmasını sağlar.

Bir nesne concurrent relocation sırasında başka bir konuma taşınmışsa barrier doğru konumu bulabilir ve referansı düzeltebilir. Bu nedenle bütün uygulama thread’lerini durdurup heap genelindeki tüm referansları tek seferde güncellemek gerekmez.

Generational ZGC ayrıca young ve old nesiller arasındaki referansları verimli biçimde izlemek için optimize edilmiş barrier mekanizmaları kullanır. Bunun karşılığı, uygulamanın normal nesne erişim yollarında belirli bir CPU maliyetidir.

Concurrent marking

ZGC, erişilebilir nesneleri uygulama çalışırken işaretler. Kısa Stop-The-World evreleri temel olarak kök durumunu güvenli biçimde yakalamak ve bazı faz geçişlerini koordine etmek için kullanılır.

Duraklamalarda bütün canlı nesne kümesini dolaşmak yerine sınırlı ve heap boyutuna doğrudan bağlı olmayan işler yapılması, large heap sistemlerde ZGC’nin en önemli avantajıdır.

Concurrent relocation

ZGC, seçilen bölgelerdeki canlı nesneleri uygulama çalışırken taşıyabilir. Uygulama eski konumu gösteren bir referansla karşılaştığında barrier mekanizması erişimi doğru adrese yönlendirir.

Böylece:

• Heap concurrent biçimde sıkıştırılabilir.
• Uzun bir Stop-The-World compaction aşaması önlenebilir.
• Büyük canlı veri kümelerinde pause süresinin heap boyutuyla büyümesi engellenebilir.
• Ayrı ve uzun süren klasik Full GC ihtiyacı ortadan kaldırılabilir.

Large heap sistemlerde ZGC’nin mimari avantajları

1. Duraklama süresi heap boyutuyla ölçeklenmez

G1’de concurrent marking heap genelinde çalışsa da canlı nesnelerin tahliyesi ve collection set işleme gibi önemli işler Stop-The-World aşamalarında yapılır. Heap ve canlı veri büyüdükçe bu aşamaların kuyruk gecikmesine etkisi artabilir.

ZGC’de pahalı marking ve relocation işleri concurrent yürütüldüğü için 32 GB’tan 256 GB’a geçiş, GC pause süresini aynı oranda büyütmez. Büyük in-memory cache, risk hesaplama motoru, fiyatlama sistemi, oyun sunucusu veya gerçek zamanlı analitik platformlarında bu özellik belirleyicidir.

2. Concurrent compaction

Low-pause collector’ların yalnızca erişilemeyen nesneleri bulması yetmez; fragmentation sorununu da uzun duraklama üretmeden çözmesi gerekir. ZGC’nin concurrent relocation yaklaşımı bellek sıkıştırmayı uygulama çalışırken gerçekleştirebilir.

3. Daha düşük tail-latency riski

Ortalama yanıt süresi iyi olsa bile uzun bir Full GC p99.9 değerini bozabilir. ZGC’nin tasarımı bu tür büyük GC kaynaklı sıçramaları azaltmaya yöneliktir.

Bununla birlikte “GC pause düştü” sonucu, uçtan uca latency’nin otomatik olarak düştüğü anlamına gelmez. Concurrent GC thread’leri CPU üzerinde uygulamayla rekabet ederse servis süresi artabilir. Bu nedenle GC pause, CPU utilization ve request latency birlikte izlenmelidir.

4. Allocation spike’larına karşı heap headroom

ZGC concurrent çalıştığı için GC bir cycle’ı tamamlayana kadar uygulama yeni nesne ayırmaya devam eder. Maksimum heap; canlı veri kümesini, cycle boyunca yapılacak allocation’ları ve trafik sıçramalarını karşılayacak boşluğu içermelidir.

Örneğin canlı veri kümesi 40 GB olan bir servise yalnızca 42 GB heap vermek, teorik olarak yeterli görünse de yüksek allocation rate altında allocation stall yaratabilir. ZGC tuning’in en önemli parametresi çoğu zaman karmaşık bir bayrak değil, doğru -Xmx ve yeterli headroom’dur.

5. Adaptif generational yönetim

Modern ZGC, generational yapıda nesil boyutlarını, GC thread sayısını ve tenuring eşiklerini iş yüküne göre dinamik biçimde ayarlar. Bu nedenle başlangıç yaklaşımı az sayıda bayrak kullanmak ve yalnızca ölçüm sonucunda müdahale etmek olmalıdır.

G1 GC ve ZGC çalışma mekanizmalarının karşılaştırması

Prod ortamında GC seçim kriterleri

Temel JVM bayrakları ve tuning örnekleri

Aşağıdaki değerler doğrudan üretime kopyalanacak reçeteler değildir. Heap büyüklüğü, CPU sayısı, NUMA yapısı, container limitleri ve allocation profili test edilmeden kesinleştirilmemelidir.

G1 GC için güvenli başlangıç profili

java \
  -XX:+UseG1GC \
  -Xms32g \
  -Xmx32g \
  -XX:MaxGCPauseMillis=100 \
  -XX:+AlwaysPreTouch \
  -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100M \
  -jar application.jar

Bayrakların amacı:

• -XX:+UseG1GC: G1 collector’ı etkinleştirir.
• -Xms32g -Xmx32g: Heap resizing ve çalışma anındaki sayfa tahsis sürprizlerini azaltır.
• -XX:MaxGCPauseMillis=100: G1’e 100 ms’lik ergonomik pause hedefi verir.
• -XX:+AlwaysPreTouch: Heap sayfalarını başlangıçta fiziksel belleğe dokundurur; açılışı uzatabilir fakat runtime latency varyansını azaltabilir.
• -Xlog:gc*,safepoint: GC ve safepoint davranışını analiz etmeyi sağlar.

G1 için young generation’ı -Xmn ile sabitlemek genellikle önerilmez. G1, pause hedefine ulaşmak için young generation boyutunu adaptif biçimde kullanır; sabit young generation bu kontrol mekanizmasını zayıflatabilir. Oracle’ın önerisi, önce yalnızca heap boyutu ve gerekiyorsa pause hedefiyle başlamaktır. Oracle G1 tuning rehberi

G1’de Full GC riski görülüyorsa

GC loglarında Pause Full (G1 Compaction Pause) veya evacuation failure görülmesi durumunda aşağıdaki seçenekler kontrollü olarak değerlendirilebilir:

-XX:G1ReservePercent=20
-XX:ConcGCThreads=8

G1ReservePercent, allocation ve evacuation için daha fazla güvenlik alanı bırakabilir. ConcGCThreads, marking’in allocation hızına yetişemediği doğrulandıysa artırılabilir. Her ikisi de maliyetsiz değildir: kullanılabilir heap alanını veya uygulamaya kalan CPU’yu azaltabilir.

Adaptive IHOP tahminleri iş yükündeki ani değişikliklere yetişemiyorsa, son çare olarak işaretlemenin daha erken başlatılması denenebilir:

-XX:-G1UseAdaptiveIHOP
-XX:InitiatingHeapOccupancyPercent=30

Bu ayar statik davranış üretir. Sezonsal veya burst karakterli iş yüklerinde adaptif mekanizmadan daha kötü sonuç verebileceği için uzun süreli karşılaştırmalı test gerektirir.

Çok sayıda yinelenen String için

Heap dump ve profiler, yüksek miktarda yinelenen String bulunduğunu gösteriyorsa:

-XX:+UseStringDeduplication

Bu seçenek bellek tüketimini azaltabilir; ancak concurrent deduplication işleminin CPU maliyeti vardır. Kanıt olmadan varsayılan tuning listesine eklenmemelidir.

JDK 24+ ZGC düşük gecikme profili

java \
  -XX:+UseZGC \
  -Xms64g \
  -Xmx64g \
  -XX:+AlwaysPreTouch \
  -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100M \
  -jar application.jar

-Xms ile -Xmx değerlerinin eşitlenmesi:

• Heap’in çalışma sırasında büyüme ihtiyacını azaltır.
• ZGC’nin belleği işletim sistemine iade etmesini fiilen sınırlar.
• Commit/uncommit ve page fault kaynaklı latency varyansını azaltabilir.
• Başlangıç süresini ve kalıcı bellek tüketimini artırır.

Ultra düşük gecikme hedeflerinde bu değiş tokuş çoğu zaman anlamlıdır; bellek yoğunluğu öncelikli ortamlarda ise esnek heap daha uygun olabilir.

Esnek bellek kullanan ZGC profili

java \
  -XX:+UseZGC \
  -Xms16g \
  -Xmx64g \
  -XX:SoftMaxHeapSize=48g \
  -XX:ZUncommitDelay=300 \
  -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100M \
  -jar application.jar

SoftMaxHeapSize, ZGC’nin normal koşullarda altında kalmaya çalışacağı yumuşak sınırdır. Collector, allocation stall riskini azaltmak için gerekirse -Xmx değerine kadar büyüyebilir.

Örnekte ZGC 48 GB altında kalmaya çalışır; ancak trafik sıçramasında 64 GB’a kadar çıkabilir. Bu, bellek maliyetiyle burst dayanıklılığı arasında kullanışlı bir denge sağlar.

JDK 21 ve 22’de Generational ZGC

java \
  -XX:+UseZGC \
  -XX:+ZGenerational \
  -Xms64g \
  -Xmx64g \
  -XX:+AlwaysPreTouch \
  -jar application.jar

Bu örnekteki -XX:+ZGenerational yalnızca ilgili eski sürüm davranışı için kullanılmalıdır. JDK 24 ve sonrasında bu seçenek kaldırılmıştır.

ZGC’de thread sayısını değiştirmek

ZGC, GC thread sayısını adaptif olarak ayarlayabilir. Bu nedenle -XX:ConcGCThreads başlangıç profilinde sabitlenmemelidir.

GC allocation hızına yetişemiyor, allocation stall oluşuyor ve sistemde boş CPU bulunuyorsa kontrollü bir deney yapılabilir:

-XX:ConcGCThreads=12

Değer çok düşükse collector geride kalabilir. Çok yüksekse GC, uygulama thread’lerinin CPU’sunu tüketerek request latency ve throughput’u bozabilir.

Explicit large pages

Büyük ve sabit heap’lerde, işletim sistemi önceden doğru biçimde hazırlanmışsa:

-XX:+UseLargePages

Large pages, TLB baskısını azaltarak throughput ve latency’ye yardımcı olabilir. Ancak host üzerinde yeterli sayıda sayfa ayrılmadan yalnızca JVM bayrağını eklemek yeterli değildir.

Transparent Huge Pages ile explicit large pages aynı şey değildir. Oracle, latency-sensitive ZGC sistemlerinde Transparent Huge Pages kullanımının istenmeyen latency sıçramaları oluşturabileceğini belirtmektedir. Bu nedenle kernel ayarı, JVM konfigürasyonu ve gerçek workload birlikte test edilmelidir. Oracle ZGC large pages açıklaması

GC loglarında hangi sinyaller izlenmeli?

Collector seçiminden bağımsız olarak aşağıdaki metrikler birlikte değerlendirilmelidir:

• GC pause p50, p95, p99 ve maksimum değerleri
• Young, mixed, old ve full collection sayısı
• GC cycle süresi ve cycle sıklığı
• Allocation rate
• Promotion rate
• Collection sonrası heap occupancy
• Canlı veri kümesi büyüklüğü
• Allocation stall sayısı ve süresi
• Application throughput
• CPU kullanımı ve CPU throttling
• Container memory limiti ile toplam RSS farkı
• Safepoint süresi ve safepoint’e ulaşma gecikmesi
• Reference processing süresi
• G1 humongous region ve evacuation failure sayısı

Yalnızca “GC toplam süresi” metriğini izlemek yanıltıcıdır. ZGC’de kısa duraklamalara rağmen concurrent GC CPU maliyeti artabilir. G1’de toplam GC süresi makul görünürken tek bir Full GC tail-latency SLO’sunu ihlal edebilir.

Üretime geçiş için önerilen test yöntemi

GC değişimi kontrollü bir performans mühendisliği çalışması olarak ele alınmalıdır:

1. Mevcut collector ile temel ölçüm alın.
2. Aynı JDK dağıtımı, heap ve CPU limitleriyle ikinci collector’ı test edin.
3. Gerçekçi canlı veri kümesini test başlamadan önce oluşturun.
4. JVM ısınması ve JIT derlemesi tamamlandıktan sonra ölçüm alın.
5. Ortalama yükün yanı sıra trafik sıçraması ve uzun süreli soak test uygulayın.
6. p99.9 latency, throughput, CPU ve RSS değerlerini birlikte karşılaştırın.
7. Heap dump, JFR ve GC loglarını allocation kaynakları açısından inceleyin.
8. Canary deployment ile sınırlı üretim trafiğinde doğrulayın.
9. Otomatik rollback eşiğini GC pause yerine uçtan uca servis SLO’suna bağlayın.

Konteyner ortamında yalnızca -Xmx değerini pod bellek limitine eşitlemeyin. Metaspace, code cache, thread stack’leri, direct buffer’lar, JNI kütüphaneleri ve JVM’nin native yapıları da RSS tüketir. Heap dışında yeterli güvenlik payı bırakılmalıdır.

Hangi senaryoda hangi GC seçilmeli?

G1 GC tercih edin:

• Gecikme hedefi yüzlerce milisaniye ölçeğindeyse,
• Throughput, ultra düşük pause süresinden daha önemliyse,
• CPU limiti sıkıysa,
• Heap orta veya büyük olsa da canlı veri kümesi yönetilebiliyorsa,
• Operasyon ekibi yerleşik ve yaygın bir collector istiyorsa,
• Gerçek workload altında G1 Full GC veya evacuation problemi üretmiyorsa.

ZGC tercih edin:

• p99.9 ve üzeri tail-latency kritikse,
• Tek haneli milisaniyelik servis hedefleri bulunuyorsa,
• Heap onlarca veya yüzlerce gigabaytsa,
• Canlı veri kümesi büyükse,
• Uzun G1 evacuation ya da Full GC duraklamaları görülüyorsa,
• Concurrent GC için CPU kapasitesi ayrılabiliyorsa,
• Heap’e yeterli allocation headroom verilebiliyorsa.

Sonuç

G1 GC ve ZGC arasında evrensel bir kazanan yoktur. G1 GC, yüksek throughput ile nispeten kısa ve tahmin edilebilir duraklamalar arasında güçlü bir denge sağlar. Bu nedenle çoğu kurumsal Java servisi için hâlâ iyi bir başlangıç noktasıdır.

ZGC’nin ayrıştığı alan, büyük heap ve katı tail-latency hedefleridir. Colored pointers, barrier mekanizmaları, concurrent marking ve concurrent relocation sayesinde pahalı GC işlemlerinin büyük bölümünü uygulamayı durdurmadan gerçekleştirir. Böylece heap büyüklüğünün Stop-The-World süresine etkisini önemli ölçüde azaltır.

Bunun karşılığında ZGC’ye yeterli CPU ve heap headroom sağlanmalıdır. Collector seçimi yalnızca maksimum GC pause karşılaştırmasına indirgenmemeli; throughput, p99.9 yanıt süresi, allocation rate, CPU tüketimi, RSS ve altyapı maliyeti birlikte değerlendirilmelidir.

Kurumsal üretim ortamı için en güvenilir yaklaşım şudur: Önce sade bir JVM konfigürasyonu kurun, ölçüm alın, üretime benzeyen yük altında G1 ve ZGC’yi karşılaştırın ve yalnızca gözlemlenmiş bir problemi çözen bayrağı ekleyin.

Garbage Collector Seçimi ve Akort Edilmesi: G1 GC vs. ZGC yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.