DispatchQueue: mi ez, a GCD sor és a több szálas feldolgozás alapjai

Mi az a DispatchQueue és Grand Central Dispatch

DispatchQueue a Grand Central Dispatch (GCD) keretrendszer egy objektuma, amely a feladatok végrehajtását kezeli rendszer- vagy egyéni szálsorokban. A Grand Central Dispatch egy alacsony szintű Apple könyvtár, amely iOS 4 és macOS 10.6 óta elérhető, és teljesen elvonatkoztatja a szálkezelést a fejlesztőtől. A GCD az operációs rendszer szálkészletét használja, és automatikusan méretezi a szálak számát az eszköz terhelése alatt.

A fejlesztőnek nem kell kézzel létrehoznia és megsemmisítenie a szálakat — a GCD átveszi ezt a feladatot, egyszerű API-t biztosítva a DispatchQueue-n keresztül. A feladat closure (lezárás) formájában kerül a sorba a sync vagy async metódusokon keresztül. Az első esetben a hívó szál blokkolódik a feladat befejezéséig, a másodikban azonnal folytatja a végrehajtást.

Az Apple (2026) adatai szerint a GCD a rendszer szálkészletét használja, amely alkalmazkodik a processzormagok számához és az aktuális terheléshez. A concurrent sor nem hoz létre új szálat minden feladathoz — a GCD újrafelhasználja a szálakat a készletből, minimalizálva a szálak létrehozásának többletköltségét.

A GCD architektúrája

A Grand Central Dispatch három kulcskomponensből áll: a sorból (DispatchQueue), a csoportból (DispatchGroup) és a szemaforból (DispatchSemaphore). A sor az alapvető elem, amely kódblokkok formájában fogadja a feladatokat. A DispatchGroup szinkronizálja több feladat végrehajtását, a DispatchSemaphore pedig korlátozza a hozzáférést egy megosztott erőforráshoz meghatározott számú szálra.

Minden GCD sor egy adott QoS (Quality of Service) osztályhoz van kapcsolva, amely tájékoztatja a rendszert a feladat fontosságáról. A rendszer a QoS-t használja a processzoridő elosztására a sorok között, előnyben részesítve a kritikusabb feladatokat — például a UI frissítését vagy a felhasználói érintések feldolgozását.

Serial és Concurrent sorok: összehasonlítás

Serial sor szigorúan egymás után hajtja végre a feladatokat, egyesével. Ha három feladat kerül egy serial sorba, a második csak az első teljes befejezése után indul. A serial sorokat a megosztott erőforrásokhoz való hozzáférés szinkronizálására használják — például egy tömbhöz, amelyet a kód több részéből módosítanak.

Concurrent sor egyszerre több feladatot futtat, elosztva azokat a rendszerkészlet elérhető szálai között. A concurrent sorban lévő feladatok érkezési sorrendben (FIFO) indulnak, de tetszőleges sorrendben fejeződnek be, ha a végrehajtási idejük eltérő. Concurrent sor nem garantálja a befejezés sorrendjét — csak az indítás sorrendjét.

Mikor válasszunk serial sort

A serial sor ideális a megosztott állapotot módosító feladatokhoz — fájlba írás, adatmodell frissítése vagy Core Data-val való munka. A serial sor használata garantálja, hogy a kód két része nem módosítja egyszerre ugyanazokat az adatokat, kiküszöbölve a versenyhelyzetet további zárolások nélkül.

Mikor válasszunk concurrent sort

Concurrent sor alkalmas az egymástól független feladatokhoz: több kép betöltése, párhuzamos hálózati kérések vagy adatok kötegelt feldolgozása. A GCD automatikusan dönti el, hány feladat fusson egyszerre, a processzormagok száma és a rendszer aktuális terhelése alapján.

Quality of Service: feladatvégrehajtás prioritásai

QoS (Quality of Service) — a GCD mechanizmusa, amely tájékoztatja az operációs rendszert a feladat fontosságáról és sürgősségéről. A rendszer a QoS-t használja a szálak ütemezéséhez: a magasabb QoS-sel rendelkező feladatok több processzoridőt kapnak és korábban indulnak. A QoS értéket a sor létrehozásakor vagy egy adott feladat elküldésekor adják meg.

A GCD-ben öt QoS osztály érhető el. .userInteractive — a legmagasabb prioritás a UI-hoz kapcsolódó feladatokhoz. .userInitiated — a felhasználó által kezdeményezett feladatokhoz. .utility — háttérfeladatokhoz a folyamatjelző megjelenítésével. .background — a felhasználó számára nem látható feladatokhoz. .default — köztes szint a userInitiated és utility között, alapértelmezés szerint használt.

Az Apple (2026) adatai szerint a QoS helytelen megválasztása a teljesítmény problémák gyakori oka. Háttérletöltés futtatása QoS .userInteractive értékkel elvonja az erőforrásokat a UI-tól, mikro-akadásokat okozva az animációkban. Javasolt a legalacsonyabb QoS-t választani, amely még elfogadható végrehajtási időt biztosít.

Példa a QoS alkalmazására

Kép betöltésekor azonnali megjelenítéshez használjon .userInitiated értéket — a felhasználó eredményt vár. A következő képernyő előzetes betöltéséhez .utility elegendő. A háttér-szinkronizáció a szerverrel .background értékkel történik, minimalizálva a hatást az aktív feladatokra.

DispatchGroup és szemaforok: feladatok szinkronizálása

DispatchGroup lehetővé teszi egy feladatcsoport befejezésének nyomon követését. Amikor a csoport összes feladata befejeződött, a GCD meghívja a notify kezelőt a megadott soron. Ez különösen hasznos több független erőforrás — profiladatok, barátlista és beállítások — betöltésekor, amikor a felületet csak az összes adat megérkezése után kell frissíteni.

A DispatchGroup támogatja a szinkron hívást wait(), amely blokkolja az aktuális szálat az összes feladat befejezéséig. Ez akkor kényelmes, amikor a kód nem folytatódhat a csoport eredményei nélkül. Az aszinkron változat — notify() — a megadott soron hívja meg a closure-t az összes feladat befejezése után, anélkül hogy blokkolná a hívó szálat.

DispatchSemaphore a párhuzamosság korlátozásához

DispatchSemaphore vezérli a hozzáférést egy erőforráshoz, korlátozva az egyidejű hozzáférések számát. A 3 kezdőértékű szemafor legfeljebb három párhuzamos feladat futtatását teszi lehetővé. A wait() hívásakor a számláló csökken, a signal() hívásakor nő. Ha a számláló nulla, a szál blokkolódik az erőforrás felszabadulásáig.

Kódpéldák DispatchQueue-val Swift-ben

Vizsgáljunk meg három gyakorlati példát a DispatchQueue használatára Swift-ben. Az első egy alapvető async hívást mutat be visszatéréssel a fő szálra, a második — szinkronizálást serial soron keresztül, a harmadik — DispatchGroup-t párhuzamos kérésekhez.

Alapvető async hívás visszatéréssel a main-re

DispatchQueue.main a fő szál serial sora, kizárólag UI műveletekre fenntartva. Mindig ezt használja a felület frissítéséhez a háttérmunka befejezése után.

let queue = DispatchQueue.global(qos: .userInitiated)
queue.async {
    let data = self.fetchData()
    DispatchQueue.main.async {
        self.updateUI(with: data)
    }
}

Serial sor a megosztott erőforrás védelmére

Egyedi azonosítóval rendelkező saját serial sor létrehozása szinkronizálja a hozzáférést egy változtatható tömbhöz. Minden olvasási és írási művelet egy soron halad át, kiküszöbölve a versenyhelyzetet.

let serialQueue = DispatchQueue(label: "com.app.items")
var items: [Int] = []

serialQueue.async {
    items.append(1)
}
serialQueue.async {
    let last = items.last
    DispatchQueue.main.async {
        print("Last item: \(last)")
    }
}

DispatchGroup párhuzamos kérésekhez

DispatchGroup lehetővé teszi több feladat futtatását egy concurrent soron, és értesítést kapni az összes befejezéséről. Ez hasznos a profilképernyő adatainak betöltésekor.

let group = DispatchGroup()
let worker = DispatchQueue.global()

worker.async(group: group) { self.loadProfile() }
worker.async(group: group) { self.loadFriends() }
worker.async(group: group) { self.loadSettings() }

group.notify(queue: DispatchQueue.main) {
    self.showCompleteUI()
}

Gyakori hibák a DispatchQueue használatakor

Deadlock sync híváskor egy serial soron — a leggyakoribb hiba. Ha egy serial soron lévő feladat queue.sync-et hív ugyanazon a soron, a szál örökre blokkolódik. A sor vár az aktuális feladat befejezésére, a feladat pedig vár a sync hívás befejezésére — klasszikus kölcsönös blokkolás.

UI frissítése háttérszálról

Minden UIKit műveletet a fő szálon kell végrehajtani. Az Xcode Debug módban észleli ezeket a hibákat a Main Thread Checker segítségével. Release build-ben kiszámíthatatlan viselkedéshez vezetnek: az animációk nem indulnak el, a UI nem frissül, crash-ek lehetségesek.

Túlzott egyéni sorok létrehozása

Több száz egyéni sor létrehozása a globális sorok helyett — antiminta. Minden sor rendszererőforrásokat fogyaszt. A legtöbb feladathoz elegendőek a globális concurrent sorok különböző QoS-sel és egy-két serial sor a megosztott adatok szinkronizálásához.

Az autoreleasepool figyelmen kívül hagyása ciklusokban

Erőforrás-igényes ciklikus feladatok végrehajtásakor háttérsoron autoreleasepool nélkül a memória a teljes ciklus végéig nő. Az ARC csak az autorelease pool elhagyásakor szabadítja fel az objektumokat. Csomagolja a ciklus iterációit autoreleasepool { }-be az időben történő memóriafelszabadításhoz.