Antwoord op de vraag

Swift implementeert de defer-verklaring via een door de compiler gegenereerde stapel van closure-thunks die aan elke lexicale scope zijn gekoppeld. Wanneer de compiler een defer-blok tegenkomt, haalt hij de code in een closure en registreert deze met het opruimrecord van de huidige scope. Bij het verlaten van de scope—zij het via normale stroom, return, throw of break—voert de runtime deze closures uit in Last-In-First-Out (LIFO) volgorde. Deze stapeldiscipline zorgt ervoor dat later verworven middelen als eerste worden vrijgegeven, waardoor afhankelijkheidsketens worden behouden zonder handmatige boekhouding.

Geschiedenis van de vraag

Middelenopruiming heeft historisch gezien afhankelijkheid gehad van ofwel deterministische destructors ofwel uitgebreide uitzonderingafhandeling. C++ koppelt opruiming aan objectlevenscycli via RAII, terwijl Java en C# expliciete try-finally-blokken vereisen die de opruimlogica van de verwervingscode scheiden. Go introduceerde de defer-verklaring om op basis van scope opruiming te bieden zonder de overhead van objectgeoriënteerd ontwerp, wat de ontwerp van Swift heeft beïnvloed. Swift nam defer aan in versie 2.0 als aanvulling op zijn foutafhandelingsmodel, en bood een declaratieve alternatieve oplossing voor finally die naadloos integreert met guard-verklaringen en vroege returns.

Het probleem

Complexe functies met meerdere uitgangspaden—zoals bestandshandelingen met authenticatie, logging en netwerktransmissie—vereisen zorgvuldige middelenbeheer. Ontwikkelaars moeten ervoor zorgen dat elke return of throw-locatie alle eerder verworven middelen vrijgeeft, van bestandsdescriptors tot beveiligingsgecalibreerde bladwijzers. Het missen van een enkele opruimlocatie leidt tot lekken of deadlocks, terwijl onjuiste volgorde (het sluiten van een database voordat de transactie-log is geleegd) leidt tot gegevenscorruptie. Handmatige opruiming wordt onbeheersbaar naarmate de complexiteit van de functie toeneemt, waardoor er behoefte is aan automatische, deterministische en geordende middelenafvoer die aan scopegrenzen is gekoppeld.

De oplossing

De Swift-compiler transformeert defer-verklaringen in een stapel van functiepunten die in het activeringsrecord van de omhulde scope zijn opgeslagen. Elke defer-verklaring duwt zijn thunk op deze door de compiler beheerde stapel tijdens de uitvoering. Wanneer de controleflow de sluitingshaak van de scope bereikt of een uitgangsverklaring tegenkomt, doorloopt de geïnjecteerde epiloogcode de stapel in omgekeerde volgorde en voert elke thunk uit. Dit mechanisme integreert met de foutafhandeling van Swift door te garanderen dat alle uitstaande defer-blokken worden uitgevoerd voordat een fout naar een externe catch-scope wordt doorgegeven, wat ervoor zorgt dat opruiming plaatsvindt ongeacht het uitgangspad.

Situatie uit het leven

Overweeg een iOS-toepassing die versleutelde gebruikersgegevens exporteert. Het proces verwerft een beveiligings-gecalibreerde resource-URL, opent een FileHandle, schrijft versleutelde bytes en uploadt het resultaat. Elke stap kan falen en vereist strikte opruiming om te voorkomen dat bestandsdescriptoren of persistente resource-bladwijzers lekken.

Oplossing 1: Handmatige opruiming bij elk uitgangspunt.

Ontwikkelaars zouden fileHandle.close() en url.stopAccessingSecurityScopedResource() kunnen dupliceren vóór elke return of throw. Deze aanpak is fragiel; het toevoegen van een nieuwe foutcontrole vereist het bijwerken van meerdere locaties, en beoordelaars moeten verifiëren dat de opruimvolgorde de verwervingsvolgorde weerspiegelt. Het risico op lekken neemt toe met elk nieuw uitgangspunt dat tijdens onderhoud wordt toegevoegd.

Oplossing 2: Wrapper-objecten met deinit.

Het creëren van een ScopeManager-klasse die opruiming uitvoert in zijn deinit is afhankelijk van ARC. Echter, ARC garandeert geen onmiddellijke vrijgave bij het verlaten van de scope; objecten kunnen aanhouden totdat de autoreleasepool is geleegd of de variabele wordt overschreven. In langlopende lussen vertraagt dit de vrijgave van middelen, wat "te veel open bestanden"-systeemfouten veroorzaakt die moeilijk te reproduceren zijn.

Oplossing 3: defer-blokken.

Het team verklaarde defer-blokken onmiddellijk na het verwerven van elke bron:

func exportData() throws {
    let url = try acquireResource()
    defer { url.stopAccessingSecurityScopedResource() }
    
    let fileHandle = try FileHandle(forWritingTo: url)
    defer { fileHandle.close() }
    
    let encrypted = try encrypt(data)
    try fileHandle.write(encrypted)
    try upload(fileHandle)
}

Wanneer een versleutelfout een throw veroorzaakte, sloot de runtime automatisch de bestandsbehandelaar en stopte het de toegang tot de bron, waardoor de juiste omgekeerde volgorde werd gehandhaafd. Deze oplossing werd gekozen vanwege zijn determinisme en localiteit—opruimcode verschijnt naast verwervingscode.

Resultaat:

De exportfunctie doorstond stress-testen met 10.000 gelijktijdige bewerkingen zonder lekken van bestandsdescriptoren. Codebeoordeling onthulde nul gemiste opruimlocaties, en profilering toonde onmiddellijke vrijgave van middelen in vergelijking met de deinit-aanpak.

Wat kandidaten vaak missen

Vraag 1: Voert een defer-blok uit als de functie beëindigt via fatalError of een oneindige lus?

Nee. defer wordt alleen uitgevoerd wanneer de controleflow het einde van zijn omhulde scope bereikt. Als fatalError wordt aangeroepen, beëindigt het proces onmiddellijk zonder de scopes af te winden of opruimblokken uit te voeren. Evenzo verhindert een oneindige while-lus dat de scope wordt verlaten; defer-blokken binnen het luslichaam worden alleen uitgevoerd wanneer de iteratie is voltooid, maar een while true-lus op de functieniveau activeert nooit de functieniveau defer-blokken.

Vraag 2: Hoe handelt defer variabele vastlegging af wanneer de variabele wordt gewijzigd nadat de defer is gedeclareerd?

defer legt variabelen standaard per referentie en niet per waarde vast. Bijvoorbeeld:

var count = 0
defer { print("Deferred: \(count)") }
count = 5
// Print 5, niet 0

Om de waarde op het moment van declaratie vast te leggen, moeten ontwikkelaars een expliciete vastleglijst gebruiken: defer { [value = currentValue] in ... }. Kandidaten gaan vaak ervan uit dat defer een momentopname vastlegt op het moment van declaratie, wat leidt tot logische fouten in lussen of muterende algoritmen.

Vraag 3: Wat is de uitvoeringsvolgorde wanneer defer-blokken genest zijn binnen voorwaardelijke takken versus de bovenliggende scope?

defer-blokken zijn gekoppeld aan de lexicale scope waarin ze verschijnen, niet de functiegroep. Een defer binnen een if-blok wordt uitgevoerd wanneer dat if-blok verlaat, niet wanneer de functie retourneert. Als er meerdere defer-blokken bestaan op verschillende nestniveaus, wordt de defer van de binnenste scope als eerste uitgevoerd bij het verlaten van dat specifieke blok. Dit leidt tot tegenintuïtieve ordening wanneer ontwikkelaars verwachten dat alle defer-blokken worden uitgevoerd bij het verlaten van de functie, vooral wanneer ze defer mengen met guard-verklaringen die vroege sub-scope exits creëren.