Thread alapok

A Java szálalapok azt jelentik, hogy megérted, hogyan kötődik a munka egy threadhez, hogyan indul el és áll le, és hogy az interrupt, a daemon viselkedés és a thread ownership hogyan hat a helyes működésre. Interjún ez a téma mutatja meg, hogy valaki túl tud-e lépni a puszta szintaxison.

1. Definíció

Mi az a thread?

A Java thread egy önálló végrehajtási útvonal, amelyet a JVM kezel.

A legtöbb gyakorlati környezetben ezt egy operációs rendszer szintű thread támogatja.

Ez azt jelenti, hogy a thread nem csak egy Java objektum.

A Thread példány a Java-oldali fogantyú.

A valódi futási viselkedést emellett befolyásolja:

• a JVM és az ütemező kapcsolata
• az operációs rendszer schedulerje
• a blokkoló I/O
• a lock contention
• a Java Memory Model
• a GC és a safepointok hatása

Konkurencia és párhuzamosság

A konkurencia azt jelenti, hogy több munkaegység egymástól függetlenül tud haladni.

A párhuzamosság azt jelenti, hogy ezek ténylegesen egyszerre futnak több magon.

Egy szerver lehet erősen concurrent akkor is, ha kevés valódi parallel munka történik, például amikor sok thread I/O-ra vár.

Ez interjúban fontos különbség.

A jó válasz kimondja, hogy:

• a concurrency inkább szerkezeti és koordinációs kérdés
• a parallelism inkább egyidejű végrehajtási kérdés

Miért fontos ez a téma?

Ha a munkát közvetlenül egy raw threadhez kötöd, akkor a lifecycle rögtön üzemeltetési kérdéssé válik.

Ekkor már számít:

• az indulási stratégia
• a leállítási stratégia
• a hibatűrés
• a naming
• a cleanup
• a shutdown garancia

Ezért a thread basics több, mint egy egyszerű start() hívás.

2. Alapfogalmak

2.1 `Thread` versus `Runnable` versus `Callable`

A Thread osztály öröklése összeköti a feladatot és a végrehajtási mechanizmust.

A Runnable implementálása szétválasztja a munkát attól a threadtől, amely futtatja.

A Callable ehhez hozzáad egy visszatérési értéket és egy checked exception csatornát.

Valódi rendszerekben ezért írjuk le a feladatot inkább Runnable vagy Callable formában, és az executor dönti el, hogyan fusson.

2.1.1 Kifejezések és szerződések, amiket érdemes név szerint kimondani

Ebben a témában ezek a kulcsszavak teherhordók:

• Thread — JVM-szintű végrehajtási fogantyú
• Runnable — task contract visszatérési érték nélkül
• Callable — task contract eredménnyel és exception csatornával
• start() — új végrehajtási szál indítása
• run() — a thread által futtatott metódustest
• join() — várakozás egy másik thread befejeződésére
• interrupt() — kooperatív leállítási jelzés
• isInterrupted() — interrupt flag ellenőrzése törlés nélkül
• Thread.interrupted() — ellenőrzés és törlés egyben
• daemon thread — háttérszál, amely nem tartja életben a JVM-et
• UncaughtExceptionHandler — kezeletlen szálhibákhoz tartozó hook
• ThreadLocal — per-thread állapottárolás
• thread dump — diagnosztikai pillanatkép a szálak stackjeiről és állapotáról

Ezek egyszerre interjúkulcsszavak és production diagnosztikai fogalmak.

2.2 Lifecycle és állapotok

A Java thread állapotai többek között a következők:

• NEW
• RUNNABLE
• BLOCKED
• WAITING
• TIMED_WAITING
• TERMINATED

A RUNNABLE nem feltétlenül azt jelenti, hogy a thread éppen CPU-n fut.

Azt jelenti, hogy futásra kész.

Az is lehet, hogy még ütemezésre vár.

A BLOCKED gyakran azt jelenti, hogy a szál egy synchronized monitorba próbál belépni.

A WAITING és TIMED_WAITING megjelenhet például ezeknél:

• Object.wait()
• Thread.sleep()
• Thread.join()
• LockSupport.park()

2.3 Interrupt mint leállítási mechanizmus

Az interrupt a Java kooperatív cancellation mechanizmusa.

Az interrupt() hívás nem öli meg erőszakosan a threadet.

Csak beállít egy interrupt flaget.

Bizonyos blokkoló API-k erre InterruptedException dobásával reagálnak.

A helyes kód ilyenkor vagy:

• továbbadja az interruption eseményt
• vagy visszaállítja a flaget a Thread.currentThread().interrupt() hívással

Az interruption lenyelése klasszikus concurrency bug.

2.4 Daemon threadek

A daemon thread nem tartja életben a JVM-et.

Ha már csak daemon threadek maradnak, a JVM kiléphet.

Ezért ezek jók lehetnek best-effort háttérfeladatokra.

De veszélyesek olyan munkához, amelynek garantáltan végig kell futnia.

3. Gyakorlati használat

Mikor elfogadható a raw thread?

Raw thread akkor elfogadható, ha:

• az alapokat tanítod
• nagyon explicit ownership kell
• low-level API integráció történik
• a háttérmunka szűk és jól behatárolt

Még ilyenkor is érdemes tisztázni:

• legyen értelmes threadnév
• daemon vagy non-daemon legyen-e
• kell-e UncaughtExceptionHandler
• hogyan fog leállni

Kooperatív stop logika

A hosszú életű ciklusok ne abból induljanak ki, hogy örökké futnak.

Időnként ellenőrizniük kell az interruptot.

A blokkoló kód lehetőleg interrupt-barát API-kat használjon.

Egy jó thread loop általában:

• addig dolgozik, amíg nincs megszakítva
• gyorsan reagál az interruptionre
• felszabadítja az erőforrásokat
• tisztán kilép

Thread naming és diagnosztika

A threadnév nem kozmetikai részlet.

Megjelenik:

• thread dumpokban
• profiler outputban
• logokban
• monitoring felületeken

A Thread-47 sokkal kevesebbet ér, mint például az invoice-writer-1.

`ThreadLocal` használat

A ThreadLocal hasznos lehet például:

• request korrelációhoz
• per-thread formatter helperhez
• szűk scope-ú cache-ekhez

De thread pool mellett könnyen átfolyhat állapot egyik logikai kérésből a másikba, ha elmarad a remove().

4. Kód példák

1. példa: helyes thread indítás és interrupt kezelés

Thread worker = new Thread(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        try {
            System.out.println("processing batch");
            Thread.sleep(500);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
    System.out.println("worker stopped cleanly");
}, "inventory-sync-1");

worker.setUncaughtExceptionHandler((thread, ex) ->
    System.err.println(thread.getName() + " failed: " + ex.getMessage()));

worker.start();
worker.interrupt();
worker.join();

Kulcspontok:

• a start() valódi konkurens végrehajtást hoz létre
• az interrupt() kooperatív leállítás
• a join() megvárja a tiszta leállást
• a catch blokk visszaállítja az interrupt flaget

2. példa: daemon helper explicit stop logikával

class HeartbeatService {
    private final AtomicBoolean running = new AtomicBoolean();
    private Thread thread;

    void start() {
        if (!running.compareAndSet(false, true)) {
            return;
        }
        thread = new Thread(this::runLoop, "heartbeat-daemon");
        thread.setDaemon(true);
        thread.start();
    }

    private void runLoop() {
        while (running.get() && !Thread.currentThread().isInterrupted()) {
            try {
                sendHeartbeat();
                Thread.sleep(1_000);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
    }

    void stop() throws InterruptedException {
        running.set(false);
        if (thread != null) {
            thread.interrupt();
            thread.join(2_000);
        }
    }

    private void sendHeartbeat() {}
}

Kulcspontok:

• a daemon nem helyettesíti az explicit stop logikát
• a lifecycle továbbra is tervezési kérdés
• a shutdown része az interrupt is

3. példa: `ThreadLocal` cleanup

class RequestContextHolder {
    private static final ThreadLocal<String> REQUEST_ID = new ThreadLocal<>();

    static void handle(String requestId) {
        REQUEST_ID.set(requestId);
        try {
            process();
        } finally {
            REQUEST_ID.remove();
        }
    }

    private static void process() {}
}

Kulcspont:

• poololt threadeknél a thread-local állapotot explicit módon takarítani kell

5. Trade-offok

Gyakorlati trade-off elemzés

A raw thread kontrollt ad.

De nem ad:

• poolt
• admission controlt
• strukturált shutdown logikát sok task esetén
• automatikus result propagationt

Ezért fontosak a thread basics alapjai, de általános task dispatchre többnyire executor kell.

A senior szemlélet:

• használj raw threadet, ha az ownership szűk és egyértelmű
• ne ez legyen az általános task dispatch stratégia

6. Gyakori hibák

1. hiba: `run()` hívása `start()` helyett

A run() közvetlen hívása a hívó threadjén fut.

Helyes megközelítés:

• ha valódi concurrency kell, start()-ot kell hívni

2. hiba: `InterruptedException` lenyelése

A puszta logolás és folytatás gyakran tönkreteszi a shutdown viselkedést.

Helyes megközelítés:

• add tovább vagy állítsd vissza a flaget

3. hiba: azt hinni, hogy a `sleep()` elengedi a lockot

Nem engedi el.

Ha egy thread synchronized blokkon belül alszik, továbbra is fogja a monitort.

Helyes megközelítés:

• ne aludj kritikus szakaszban, hacsak nem érted pontosan a következményt

4. hiba: daemon thread félrehasználata

Csapatok néha daemonra állítanak egy threadet csak azért, hogy elfedjék a shutdown hibákat.

Helyes megközelítés:

• a lifecycle ownership hibát javítsd meg, ne daemon szemantikával takard el

5. hiba: elmaradó `ThreadLocal.remove()`

Ez állapotszivárgáshoz és olykor memory retentionhöz vezet.

Helyes megközelítés:

• finally blokkban takarítsd el a thread-local értéket

6. hiba: kontrollálatlan thread létrehozás

Ha terhelés alatt ciklusban gyártasz threadeket, scheduler thrashing és memória-nyomás jelentkezhet.

Helyes megközelítés:

• dinamikusan növekvő taskmennyiségnél használj executort

7. Mélymerülés

7.1 Miért diagnosztikai eszköz a thread state?

A thread state nem csak elmélet.

Segít a thread dumpok olvasásában.

Sok BLOCKED állapot gyakran monitor contentionre utal.

Sok TIMED_WAITING utalhat például:

• sleep-alapú pollingra
• backoff logikára
• idle poolokra

Sok RUNNABLE magas CPU-val utalhat:

• spin loopra
• CPU-intenzív munkára
• native blokkolásra, amely mégis runnable-ként látszik

7.2 Az interrupt policy az API része

Egy threadnek nem csak munka-logikára van szüksége.

Cancellation contractra is szüksége van.

Ennek választ kell adnia arra, hogy:

• hogyan áll le a loop?
• milyen gyorsan reagál a blokkoló rész?
• milyen cleanup fut interruption után?
• a hívó látja-e a cancellationt?

Ezért az interruption nem mellékes részlet.

Ez a komponens szerződésének része.

7.3 Daemon szemantika és megbízhatóság

A daemon thread hasznos lehet:

• metrics helperhez
• best-effort housekeepinghez
• opcionális háttérfrissítéshez

Rosszul illik viszont ehhez:

• kritikus írásokhoz
• kötelező shutdown flushhoz
• garantáltan befejezendő üzleti workflowhoz

7.4 Raw thread és modern Java

A modern Java virtual threadeket is ad.

De a thread basics ettől még fontos marad.

Továbbra is érteni kell:

• interruption
• naming
• cancellation
• ownership
• failure handling

Az absztrakciók változnak, de az alapinvariánsok megmaradnak.

8. Interjúkérdések

1. Mi a különbség a `start()` és a `run()` között?

A start() új végrehajtási szálat indít.

A run() közvetlen hívása csak egy normál metódushívás.

2. Mi a különbség a concurrency és a parallelism között?

A concurrency függetlenül haladó feladatokról szól.

A parallelism tényleges egyidejű futásról szól több magon.

3. Mit csinál az interrupt?

Kooperatív cancellation jelzést ad.

Nem öli meg erőszakosan a threadet.

4. Miért veszélyes lenyelni az `InterruptedException`-t?

Mert szétveri a cancellation és shutdown koordinációt.

5. Mi az a daemon thread?

Olyan háttérszál, amely nem tartja életben a JVM-et.

6. Miért kockázatos a `ThreadLocal` poolokkal?

Mert a fizikai worker thread újra felhasználódik több logikai requesthez.

7. Elengedi-e a `sleep()` a monitor lockot?

Nem.

8. Miért legyen értelmes threadnév?

Mert a dumpokban, logokban és profilerekben sokkal jobb diagnosztikát ad.

9. Mikor elfogadható a raw thread?

Amikor az ownership szűk és egyértelmű, vagy amikor low-level alapokat mutatsz be.

10. Mi a senior szintű tanulság?

Threadet indítani könnyű.

A thread lifecycle megtervezése a valódi mérnöki feladat.

9. Szószedet

10. Gyorsreferencia

• a start() hoz létre concurrencyt, a run() önmagában nem
• a Runnable szétválasztja a taskot a threadtől
• a Callable eredménycsatornát is ad
• az interrupt kooperatív cancellation, nem forced stop
• ha elkapod az InterruptedException-t, általában állítsd vissza a flaget
• a sleep() nem engedi el a lockot
• a join() interruption-érzékeny várakozás
• a daemon thread csak best-effort háttérmunkára való
• poololt környezetben takarítsd a ThreadLocal értéket
• interjún nevezd meg a start(), run(), interrupt(), daemon thread és ThreadLocal trade-offjait