Golang Defer: Heap-zugewiesener, Stack-zugewiesener, offen codierter Defer

Dies ist ein Auszug aus dem Beitrag; Der vollständige Beitrag ist hier verfügbar: Golang Defer: From Basic To Trap.

Die Defer-Anweisung ist wahrscheinlich eines der ersten Dinge, die wir ziemlich interessant finden, wenn wir anfangen, Go zu lernen, oder?

Aber es steckt noch viel mehr dahinter, das viele Menschen stutzig macht, und es gibt viele faszinierende Aspekte, die wir bei der Verwendung oft nicht ansprechen.

Heap-zugewiesen, Stapelzugewiesen, Open-coded defer

Zum Beispiel hat die Defer-Anweisung tatsächlich drei Typen (ab Go 1.22, obwohl sich das später ändern könnte): Open-Coded Defer, Heap-Allocated Defer und Stack-Allocated. Jedes hat eine unterschiedliche Leistung und verschiedene Szenarien, in denen es am besten eingesetzt wird. Das ist gut zu wissen, wenn Sie die Leistung optimieren möchten.

In dieser Diskussion werden wir alles von den Grundlagen bis zur fortgeschritteneren Verwendung behandeln und uns sogar ein wenig, nur ein wenig, mit einigen internen Details befassen.

Was ist Aufschieben?

Werfen wir einen kurzen Blick auf „Aufschieben“, bevor wir zu tief tauchen.

Defer ist in Go ein Schlüsselwort, das verwendet wird, um die Ausführung einer Funktion zu verzögern, bis die umgebende Funktion abgeschlossen ist.

func main() {
  defer fmt.Println("hello")
  fmt.Println("world")
}

// Output:
// world
// hello

In diesem Snippet plant die Defer-Anweisung die Ausführung von fmt.Println("hello") ganz am Ende der Hauptfunktion. Daher wird fmt.Println("world") sofort aufgerufen und "world" zuerst gedruckt. Da wir „defer“ verwendet haben, wird danach „Hallo“ als letzter Schritt gedruckt, bevor der Hauptschritt abgeschlossen ist.

Es ist so, als würde man eine Aufgabe einrichten, die später ausgeführt wird, kurz bevor die Funktion beendet wird. Dies ist sehr nützlich für Bereinigungsaktionen, wie das Schließen einer Datenbankverbindung, das Freigeben eines Mutex oder das Schließen einer Datei:

func doSomething() error {
  f, err := os.Open("phuong-secrets.txt")
  if err != nil {
    return err
  }
  defer f.Close()

  // ...
}

Der obige Code ist ein gutes Beispiel, um zu zeigen, wie Defer funktioniert, aber es ist auch eine schlechte Art, Defer zu verwenden. Darauf gehen wir im nächsten Abschnitt ein.

"Okay, gut, aber warum nicht f.Close() am Ende einfügen?"

Dafür gibt es ein paar gute Gründe:

• Wir platzieren die Aktion „Schließen“ in der Nähe der Aktion „Öffnen“, damit es einfacher ist, der Logik zu folgen und zu vermeiden, dass das Schließen der Datei vergessen wird. Ich möchte bei einer Funktion nicht nach unten scrollen, um zu prüfen, ob die Datei geschlossen ist oder nicht; es lenkt mich von der Hauptlogik ab.
• Die verzögerte Funktion wird aufgerufen, wenn die Funktion zurückkehrt, auch wenn eine Panik (Laufzeitfehler) auftritt.

Wenn eine Panik auftritt, wird der Stapel abgewickelt und die verzögerten Funktionen werden in einer bestimmten Reihenfolge ausgeführt, die wir im nächsten Abschnitt behandeln.

Verzögerungen werden gestapelt

Wenn Sie mehrere Defer-Anweisungen in einer Funktion verwenden, werden diese in einer „Stapel“-Reihenfolge ausgeführt, was bedeutet, dass die letzte verzögerte Funktion zuerst ausgeführt wird.

func main() {
  defer fmt.Println(1)
  defer fmt.Println(2)
  defer fmt.Println(3)
}

// Output:
// 3
// 2
// 1

Jedes Mal, wenn Sie eine Defer-Anweisung aufrufen, fügen Sie diese Funktion an den Anfang der verknüpften Liste der aktuellen Goroutine hinzu, wie folgt:

Goroutine-Verzögerungskette

Und wenn die Funktion zurückkehrt, durchläuft sie die verknüpfte Liste und führt jede einzelne in der im Bild oben gezeigten Reihenfolge aus.

Aber denken Sie daran, dass nicht alle Verzögerungen in der verknüpften Liste von Goroutine ausgeführt werden, sondern nur die Verzögerungen in der zurückgegebenen Funktion ausgeführt werden, da unsere verknüpfte Verzögerungsliste viele Verzögerungen von vielen verschiedenen Funktionen enthalten kann.

func B() {
  defer fmt.Println(1)
  defer fmt.Println(2)
  A()
}

func A() {
  defer fmt.Println(3)
  defer fmt.Println(4)
}

Es werden also nur die verzögerten Funktionen in der aktuellen Funktion (oder dem aktuellen Stapelrahmen) ausgeführt.

Goroutine-Verzögerungskette

Aber es gibt einen typischen Fall, in dem alle verzögerten Funktionen in der aktuellen Goroutine verfolgt und ausgeführt werden, und dann kommt es zu Panik.

Aufschieben, Panik und Wiederherstellen

Neben Kompilierzeitfehlern gibt es auch eine Reihe von Laufzeitfehlern: Division durch Null (nur Ganzzahlen), außerhalb der Grenzen, Dereferenzierung eines Nullzeigers und so weiter. Diese Fehler führen dazu, dass die Anwendung in Panik gerät.

Panik ist eine Möglichkeit, die Ausführung der aktuellen Goroutine zu stoppen, den Stapel abzuwickeln und die verzögerten Funktionen in der aktuellen Goroutine auszuführen, was zum Absturz unserer Anwendung führt.

Um unerwartete Fehler zu behandeln und einen Absturz der Anwendung zu verhindern, können Sie die Wiederherstellungsfunktion innerhalb einer verzögerten Funktion verwenden, um die Kontrolle über eine in Panik geratene Goroutine zurückzugewinnen.

func main() {
  defer func() {
    if r := recover(); r != nil {
      fmt.Println("Recovered:", r)
    }
  }()

  panic("This is a panic")
}

// Output:
// Recovered: This is a panic

Normalerweise geben die Leute einen Fehler in die Panik ein und fangen ihn mit „recover(..)“ ab, aber es kann alles sein: ein String, ein Int usw.

In the example above, inside the deferred function is the only place you can use recover. Let me explain this a bit more.

There are a couple of mistakes we could list here. I’ve seen at least three snippets like this in real code.

The first one is, using recover directly as a deferred function:

func main() {
  defer recover()

  panic("This is a panic")
}

The code above still panics, and this is by design of the Go runtime.

The recover function is meant to catch a panic, but it has to be called within a deferred function to work properly.

Behind the scenes, our call to recover is actually the runtime.gorecover, and it checks that the recover call is happening in the right context, specifically from the correct deferred function that was active when the panic occurred.

"Does that mean we can’t use recover in a function inside a deferred function, like this?"

func myRecover() {
  if r := recover(); r != nil {
    fmt.Println("Recovered:", r)
  }
}

func main() {
  defer func() {
    myRecover()
    // ...
  }()

  panic("This is a panic")
}

Exactly, the code above won’t work as you might expect. That’s because recover isn’t called directly from a deferred function but from a nested function.

Now, another mistake is trying to catch a panic from a different goroutine:

func main() {
  defer func() {
    if r := recover(); r != nil {
      fmt.Println("Recovered:", r)
    }
  }()

  go panic("This is a panic")

  time.Sleep(1 * time.Second) // Wait for the goroutine to finish
}

Makes sense, right? We already know that defer chains belong to a specific goroutine. It would be tough if one goroutine could intervene in another to handle the panic since each goroutine has its own stack.

Unfortunately, the only way out in this case is crashing the application if we don’t handle the panic in that goroutine.

Defer arguments, including receiver are immediately evaluated

I've run into this problem before, where old data got pushed to the analytics system, and it was tough to figure out why.

Here’s what I mean:

func pushAnalytic(a int) {
  fmt.Println(a)
}

func main() {
  a := 10
  defer pushAnalytic(a)

  a = 20
}

What do you think the output will be? It's 10, not 20.

That's because when you use the defer statement, it grabs the values right then. This is called "capture by value." So, the value of a that gets sent to pushAnalytic is set to 10 when the defer is scheduled, even though a changes later.

There are two ways to fix this.

...

Full post is available here: Golang Defer: From Basic To Trap.

Das obige ist der detaillierte Inhalt vonGolang Defer: Heap-zugewiesener, Stack-zugewiesener, offen codierter Defer. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!