Régi IO (java.io)

A klasszikus I/O a Java régi, de máig alapvető modellje bájtok és karakterek olvasására, illetve írására. Ebből érthető meg a bináris és szöveges adat különbsége, a charset kezelés jelentősége, a pufferelés hatása és a helyes erőforrás-életciklus.

1. Definíció

Mi a klasszikus IO?

A klasszikus Java I/O a java.io csomag stream-orientált API-ja.

Az alapötlet az, hogy az adat olyan objektumokon keresztül áramlik, amelyek olvasnak egy forrásból vagy írnak egy célba.

Ez a modell két nagy családra bontja a problémát:

• bájtalapú API-k nyers adathoz
• karakteralapú API-k szöveghez

Ez az egyik első valódi mérnöki határ a Java-ban.

Ha ezt figyelmen kívül hagyod, az eredmény lehet karaktertorzulás, adatkorruptció vagy csak bizonyos környezetben megjelenő bug.

Miért fontos még mindig?

Újabb Java kódban gyakran Path, Files, frameworkök vagy magasabb szintű könyvtárak jelennek meg.

De ezek közül sok a háttérben még mindig stream-alapú I/O-ra épül.

A klasszikus I/O azért marad fontos, mert megmagyarázza:

• miért kell külön modellezni a szöveget és a nyers bájtokat
• miért helyességi kérdés az explicit charset
• miért változtatja meg a pufferelés a teljesítményt
• miért része a cleanup a korrekt működésnek

Mit tartalmazzon egy erős interjúválasz?

Egy erős válasz összeköti az API neveket a valós döntésekkel.

Például:

• mikor kell InputStream a Reader helyett
• miért létezik az InputStreamReader
• miért gyakori jó default a BufferedReader vagy a BufferedOutputStream
• mikor számít a flush() a close() előtt
• miért alapminta a try-with-resources

2. Alapfogalmak

2.1 Byte stream kontra character stream

Az InputStream és az OutputStream nyers bájtokkal dolgozik.

Ez a helyes absztrakció például:

• képekhez
• ZIP fájlokhoz
• PDF-ekhez
• hálózati payloadokhoz
• titkosított vagy tömörített adatokhoz

A Reader és a Writer karakterekkel dolgozik.

Ez a helyes absztrakció például:

• szövegfájlokhoz
• CSV-hez
• logokhoz
• konfigurációs állományokhoz
• konzolos szöveghez

Ha az adat szemantikailag szöveg, a karakteres API többnyire tisztább.

Ha az adat bináris, a karakteres API sokszor hibás.

2.1.1 Kulcsszavak és szerződések, amelyeket itt explicit módon ki kell mondani

Ez a téma nem teljes, ha a fő kifejezéseket és a mögöttük álló szerződést nem nevezed néven:

• InputStream — nyers bájtokat olvas a forrásból
• OutputStream — nyers bájtokat ír a célba
• Reader — dekódolt karaktereket olvas
• Writer — kódolt karaktereket ír
• InputStreamReader — charsettel hidat képez a byte és a karakter között
• OutputStreamWriter — karaktereket alakít bájttá charset alapján
• BufferedInputStream / BufferedOutputStream — byte oldali pufferelést ad
• BufferedReader / BufferedWriter — karakter oldali pufferelést ad
• flush() — a pufferelt kimenetet továbbnyomja a következő réteg felé
• close() — lezárja az erőforrást, és a wrappereket tipikusan előbb flush-olja
• EOF — fájl- vagy stream-vég, amit sok API -1-gyel jelez
• IOException — sok I/O művelet checked hibája
• try-with-resources — automatikus cleanup minta AutoCloseable erőforrásokra
• charset — bájtok és karakterek közti leképezés
• default charset — környezetfüggő kódolási választás, amire nem szabad vakon támaszkodni

Ezek nem pusztán szószedeti szavak.

Helyességi határvonalakat jelölnek.

Ha rossz API-családot vagy rossz charsetet választasz, maga az adat sérülhet.

2.2 Híd a bájt és a szöveg között

A szöveg valahol mindig bájtokként létezik.

Ezért olvasáskor dekódolni kell.

Íráskor pedig kódolni.

Ezért létezik az InputStreamReader és az OutputStreamWriter.

Ezek kötik össze a byte streamet a karakteres API-val.

A kulcsdöntés itt a charset.

Production szintű kódban ezt a választást többnyire explicit módon kell megtenni.

Tipikus default:

• StandardCharsets.UTF_8

2.3 Pufferelés

A pufferelés csökkenti a drága I/O hívások számát.

Ahelyett, hogy a program nagyon apró egységeket olvasna vagy írna folyamatosan, a pufferelt wrapper több adatot kezel egyszerre.

Ez gyakran jelentősen javítja az áteresztőképességet.

A pufferelés ugyanakkor a láthatósági szemantikát is módosítja.

Kimenetnél az adat lehet már memóriában, miközben a fájl, socket vagy fogadó folyamat még nem látja.

Ezért fontos a flush().

2.4 Életciklus és hibakezelés

Az I/O erőforrások szűkös operációs rendszer szintű handle-ök.

Ha elfelejted lezárni őket, a folyamat descriptorokat, puffereket vagy lockokat szivárogtathat.

A preferált minta a try-with-resources.

Ez determinisztikussá teszi a cleanupot.

Arra is figyel, hogy ha a fő blokk és a cleanup is hibázik, a lezárási hiba suppressed exceptionként megmaradjon.

Ez senior hibakeresésben különösen fontos részlet.

3. Gyakorlati használat

Default gyakorlati döntések

Bináris fájlmásoláshoz válassz byte streamet.

Szövegolvasáshoz válassz Reader-alapú API-t explicit UTF-8-cal.

Ismétlődő I/O-hoz tegyél pufferelést.

Cleanuphoz használj try-with-resources-t.

Tipikus use-case-ek

• UTF-8 konfigurációs fájl olvasása
• PDF vagy ZIP másolása
• szöveges output írása hosszan élő streamre
• konzol input soronkénti feldolgozása
• CSV export BufferedWriter-rel

Döntési útmutató

Használj byte streamet, ha:

• a payload bináris
• a nyers bájtokat pontosan meg kell őrizni
• a dekódolást egy másik réteg végzi

Használj character streamet, ha:

• a payload szöveg
• a sor-alapú olvasás kényelmes
• ebben a rétegben kell kezelni a charsetet

Használj pufferelést, ha:

• sok apró read vagy write történne
• számít a throughput
• szükséged van kényelmes line API-ra, például readLine()-ra

Légy különösen óvatos, ha:

• PrintWriter-t használsz, mert a write hibák könnyen észrevétlenek maradnak
• azt hiszed, a flush() fizikai tartósságot garantál
• platform default charsetre támaszkodsz

Interjús megfogalmazás

Egy interjúképes válasz így hangzik:

“Először eldöntöm, hogy az adat bináris vagy szöveges.

Utána kiválasztom a megfelelő stream családot.

Szöveghez expliciten megadom a charsetet.

Ismétlődő műveletekhez pufferelést adok.

És a cleanupot try-with-resources-szel oldom meg.”

4. Kód példák

1. példa: UTF-8 szöveg helyes olvasása

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

public class ReadConfigExample {
  public static void main(String[] args) throws IOException {
    Path path = Path.of("config.txt");

    try (BufferedReader reader = new BufferedReader(
        new InputStreamReader(Files.newInputStream(path), StandardCharsets.UTF_8))) {
      String line;
      while ((line = reader.readLine()) != null) {
        System.out.println(line);
      }
    }
  }
}

Miért jó:

• explicit, hogy szöveggel dolgozol
• explicit, hogy UTF-8 a charset
• biztonságosan zárja az erőforrást
• a pufferelés gyakorlati hatékonyságot ad

2. példa: Bináris adat biztonságos másolása

import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class BinaryCopyExample {
  public static void main(String[] args) throws IOException {
    Path source = Path.of("input.pdf");
    Path target = Path.of("copy.pdf");

    try (BufferedInputStream in = new BufferedInputStream(Files.newInputStream(source));
       BufferedOutputStream out = new BufferedOutputStream(Files.newOutputStream(target))) {

      byte[] buffer = new byte[8192];
      int bytesRead;

      while ((bytesRead = in.read(buffer)) != -1) {
        out.write(buffer, 0, bytesRead);
      }
    }
  }
}

Miért jó:

• byte streamet használ bináris payloadra
• elkerüli a karakteres dekódolási hibát
• bulk műveleteket használ egyenkénti byte olvasás helyett
• profitál a pufferelésből

3. példa: Szöveg írása explicit láthatósággal

import java.io.BufferedWriter;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

public class WriteLogExample {
  public static void main(String[] args) throws IOException {
    Path path = Path.of("app.log");

    try (BufferedWriter writer = Files.newBufferedWriter(path, StandardCharsets.UTF_8)) {
      writer.write("started");
      writer.newLine();
      writer.flush();
    }
  }
}

Miért számít itt a flush():

• az adat a végső close előtt is láthatóvá válik
• a hosszan élő writer-eknél gyakran kell köztes láthatósági pont
• nem minden use-case várhat a lezárásig

4. példa: Hibás absztrakciós döntés

PNG, ZIP vagy más bináris fájlhoz ne használj Writer-t.

Ilyenkor a karakteres réteg kódolási szabályokat alkalmaz a bináris adatra.

Ennek eredménye adatkorruptció lehet.

Ez nem kis implementációs hiba.

Ez maga a rossz absztrakció.

5. Trade-offok

Gyakorlati trade-off elemzés

A klasszikus I/O nagyon jól rétegezhető.

Ez rugalmasságot ad.

Ugyanakkor a rossz kombinációkat is megkönnyíti.

Tipikus rossz döntések:

• character API bináris adathoz
• default charset hordozható rendszerben
• egyenkénti byte olvasás forró útvonalon
• IOException lenyelése
• dupla buffering, amikor nincs valódi haszna

Másik fontos trade-off az absztrakciós szint.

A BufferedReader kényelmesebb sor-alapú szövegre.

Az InputStream alacsonyabb szintű és általánosabb.

A jó választást az adat szemantikája dönti el, nem a megszokás.

6. Gyakori hibák

1. hiba: Default charset vak használata

Ez sokszor működik a fejlesztő gépén.

Majd más OS-en, locale-on vagy container képen elromlik.

Helyes megközelítés:

• explicit UTF-8 vagy a domain által megkívánt charset

2. hiba: Bináris adat szövegként kezelése

Ez adatkorruptcióhoz vezet.

Helyes megközelítés:

• a bináris payload maradjon byte streamen

3. hiba: Cleanup elfelejtése

Ez resource leakhez és instabil működéshez vezet.

Helyes megközelítés:

• try-with-resources

4. hiba: `flush()` elfelejtése hosszan élő outputnál

Ez különösen számít:

• socketnél
• pipe-nál
• interaktív process kommunikációnál
• hosszan nyitva tartott writer esetén

Helyes megközelítés:

• üzenet- vagy láthatósági határoknál flush-olj

5. hiba: Egyenkénti byte olvasás forró útvonalon

Ez túl sok drága hívást eredményez.

Helyes megközelítés:

• használj pufferelést és bulk read-et

6. hiba: `IOException` lenyelése

Ez tönkreteszi a diagnosztizálhatóságot.

Helyes megközelítés:

• ott kezeld, ahol valódi helyreállás lehetséges
• egyébként add tovább kontextussal

7. Mélyebb magyarázat

7.1 Miért segít a pufferelés?

Az I/O gyakran átlépi a JVM kód és az operációs rendszer erőforrásai közti határt.

Ez jóval drágább, mint a sima memóriaművelet.

A pufferelés csökkenti ezeket az átlépéseket.

Ezért lesz sokszor lényegesen gyorsabb a sok apró read és write pufferrel.

7.2 A `flush()` nem azonos a fizikai tartóssággal

A flush() tipikusan azt jelenti, hogy az adat kimegy a Java oldali pufferből a következő réteg felé.

Ez nem azonos azzal, hogy a fizikai eszköz már tartósan ki is írta a bájtokat.

Ez a különbség loggingnál, hálózatnál és storage garanciáknál fontos.

7.3 Decorator-szerű dizájn

A klasszikus I/O wrapper-kompozícióra épül.

Példák:

• BufferedInputStream(new FileInputStream(...))
• BufferedReader(new InputStreamReader(..., UTF_8))

Ez decorator-szerű megközelítés.

Minden réteg plusz viselkedést ad anélkül, hogy megváltoztatná az alatta lévő forrás vagy cél fogalmát.

7.4 `mark()` és `reset()`

Néhány input stream és reader képes visszatérni egy korábban megjelölt ponthoz.

Erre való a mark() és a reset().

Ez a támogatás nem univerzális.

Ha számít, ellenőrizd a markSupported() eredményét.

7.5 Suppressed exception és cleanup

try-with-resources esetén a fő blokk hibája marad az elsődleges exception.

A cleanup közbeni hibák suppressed exceptionként kapcsolódnak hozzá.

Ez több diagnosztikai információt őriz meg, mint egy naiv finally blokk, amely felülírja az eredeti hibát.

8. Interjúkérdések

1. Miért van `Reader` és `Writer`, ha az `InputStream` és `OutputStream` már adatot kezel?

Mert a szöveg dekódolást és kódolást igényel.

A karakterek szemantikája több, mint a nyers bájtoké.

2. Mikor kötelező a `flush()`?

Amikor a kimenet láthatósága a close előtt is fontos.

Tipikus példa a socket, pipe, interaktív protokoll vagy hosszan élő writer.

3. Miért veszélyes a default charset?

Mert a futási környezettől függ.

Ugyanaz a fájl másik gépen másképp dekódolódhat.

4. Miért hasznos a `BufferedReader.readLine()`?

Kényelmes sor-alapú szövegolvasást ad, a puffereléssel együtt.

5. Miért nem használunk `Reader`-t bináris fájlokra?

Mert a karakteres réteg dekódolási szabályokat alkalmaz és károsíthatja a nem szöveges adatot.

6. Miért jobb a `try-with-resources`, mint a kézi close finally-ban?

Rövidebb, biztonságosabb, és helyesen megőrzi a suppressed exceptionöket.

7. Feleslegessé teszi-e a `close()` a `flush()`-t?

Sok esetben a close flush-ol is.

De ha korábbi láthatóság kell nyitva maradó erőforrás mellett, a flush() továbbra is szükséges.

8. Mi a gyakori production bug ezen a területen?

Az egyik leggyakoribb finom adatkorruptciós hiba a charset mismatch.

9. Miért lesz a buffered wrapper sokszor default jó választás?

Mert csökkenti a drága I/O hívásokat és kis kódköltséggel javítja a throughputot.

10. Milyen szerződést kommunikál az EOF?

Azt, hogy a normál olvasási folyamat elérte a rendelkezésre álló adat végét.

9. Szószedet

10. Gyorsreferencia

• Bináris adat → InputStream / OutputStream
• Szöveg → Reader / Writer
• Szöveg byte forrásból → InputStreamReader / OutputStreamWriter
• Szöveghez többnyire explicit StandardCharsets.UTF_8
• Ismétlődő kis műveletekhez általában kell pufferelés
• A read(...) elemszámot vagy EOF-nál -1-et ad
• A flush() láthatóságról szól, nem feltétlen fizikai tartósságról
• try-with-resources az alap cleanup minta
• Bináris payloadra ne használj character API-t
• Production szövegkezelésnél kerüld a default charsetet
• Ne nyeld le az IOException-t
• Interjún említsd a pufferelést, a charsetet, a cleanupot és a binary-vs-text különbséget