Wie man Ressourcen mit Defer in einer Schleife freigibt: Der beste Ansatz
In Kontexten mit Datenbankabfragen innerhalb einer Schleife stellt sich die Frage wie folgt zur optimalen Platzierung von Verzögerungsanweisungen, um eine ordnungsgemäße Ressourcenfreigabe sicherzustellen. Betrachten Sie die folgende Schleife:
for rows.Next() { fields, err := db.Query(.....) if err != nil { // ... } defer fields.Close() // do something with `fields` }
Es ergeben sich zwei Optionen für die verzögerte Platzierung:
Verzögerung innerhalb des Schleifenkörpers:
for rows.Next() { fields, err := db.Query(.....) if err != nil { // ... } // do something with `fields` } defer fields.Close()
Verzögern nach der Schleife body:
for rows.Next() { fields, err := db.Query(.....) if err != nil { // ... } // do something with `fields` defer fields.Close() }
Defer-Ausführung verstehen
Um den besten Ansatz auszuwählen, müssen wir zunächst das Verhalten von defer verstehen. Zurückgestellte Funktionen werden nicht nur verzögert, bis die umgebende Funktion zurückkehrt, sondern werden auch dann ausgeführt, wenn die Funktion aufgrund einer Ausnahme (z. B. Panik) abrupt beendet wird. Dies dient als wesentlicher Mechanismus, um die Ressourcenfreigabe auch in Ausnahmesituationen sicherzustellen.
Potenzielle Probleme bei der Platzierung von Verzögerungen
Die Platzierung von Verzögerungen innerhalb der Schleife kann die Ressourcenfreigabe bei Schleifenbeendigung behindern . Wenn die Schleife aufgrund eines in der Schleife behandelten Fehlers vorzeitig beendet wird, wird der verzögerte Aufruf von Fields.Close() nicht ausgeführt.
Umgekehrt garantiert die Platzierung von „defer“ nach dem Schleifenkörper, dass Ressourcen unabhängig von der Art und Weise freigegeben werden Die Schleife wird beendet. Dieser Ansatz verzögert jedoch die Ressourcenbereinigung, bis die gesamte Schleife abgeschlossen ist, was möglicherweise nicht in allen Szenarien wünschenswert ist.
Optimale Lösung: Anonymer oder benannter Funktions-Wrapper
Zu Um beide Probleme zu lösen, besteht die empfohlene Lösung darin, die Ressourcenzuweisung und -freigabe in einer anonymen oder benannten Funktion zu kapseln. Auf diese Weise kann die Verzögerung innerhalb der Funktion verwendet werden, um die Ressourcenfreigabe bei Funktionsrückkehr sicherzustellen.
Zum Beispiel:
// Anonymous function wrapper for rows.Next() { func() { fields, err := db.Query(...) if err != nil { // Handle error and return return } defer fields.Close() // do something with `fields` }() } // Named function wrapper func foo(rs *db.Rows) { fields, err := db.Query(...) if err != nil { // Handle error and return return } defer fields.Close() // do something with `fields` } for rows.Next() { foo(rs) }
Dieser Ansatz ermöglicht die Ressourcenfreigabe, sobald sie nicht mehr vorhanden sind auch in Ausnahmefällen erforderlich. Wenn das Ziel außerdem darin besteht, die Schleife beim ersten Fehler zu beenden, kann der Fehler von der Wrapper-Funktion zurückgegeben und entsprechend behandelt werden:
func foo(rs *db.Rows) error { fields, err := db.Query(...) if err != nil { return fmt.Errorf("db.Query error: %w", err) } defer fields.Close() // do something with `fields` return nil } for rows.Next() { if err := foo(rs); err != nil { // Handle error and return return } }
Fehlerbehandlung mit Rows.Close()
Es ist wichtig zu beachten, dass Rows.Close() einen Fehler zurückgibt. Um diesen Fehler zu behandeln, kann eine anonyme Funktion mit einem verzögerten Aufruf von Rows.Close() verwendet werden:
func foo(rs *db.Rows) (err error) { fields, err := db.Query(...) if err != nil { return fmt.Errorf("db.Query error: %w", err) } defer func() { if err = fields.Close(); err != nil { err = fmt.Errorf("Rows.Close() error: %w", err) } }() // do something with `fields` return nil }
Das obige ist der detaillierte Inhalt vonWo sollte ich „defer'-Anweisungen in einer Schleife platzieren, um Ressourcen in Go ordnungsgemäß freizugeben?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!