Go では、defer キーワードはリソースを管理し、関数の終了時にクリーンアップ アクションが確実に実行されるようにする強力なツールです。遅延関数は、周囲の関数が正常に戻るか、エラーまたはパニックによって戻るかに関係なく、周囲の関数が戻るときに実行されます。これにより、関数の終了方法に関係なくクリーンアップ コードが確実に実行され、リソース管理がよりシンプルかつ信頼性の高いものになります。
Go では、関数内の複数の defer ステートメントは、出現順に 逆 の順序で実行されます。これは、複数のクリーンアップ タスクを管理し、関数の終了時に確実に特定の順序で実行されるようにするのに役立ちます。
func exampleFunction() {
fmt.Println("Start of function")
defer fmt.Println("First defer: executed last")
defer fmt.Println("Second defer: executed second")
defer fmt.Println("Third defer: executed first")
fmt.Println("End of function")
}
出力:
Start of function End of function Third defer: executed first Second defer: executed second First defer: executed last
defer の最も一般的な使用法の 1 つは、ファイルなどのリソースが不要になった後に確実に適切に閉じられるようにすることです。
func processFile(fileName string) error {
file, err := os.Open(fileName)
if err != nil {
return err // Return the error if opening the file fails
}
defer file.Close() // Ensure the file is closed when the function exits
// Process the file...
return nil
}
os.File は io.ReadCloser を実装しているため、ここで defer を使用すると、ファイルが適切に閉じられ、リソース リークが防止されます。
同時実行性を使用する場合、デッドロックを防ぐためにロックを解放することが重要です。 defer は、ミューテックスを効果的に管理するのに役立ちます。
var mu sync.Mutex
func criticalSection() {
mu.Lock()
defer mu.Unlock() // Ensure the mutex is unlocked when the function exits
// Critical section...
}
mu.Unlock() を延期することで、ミューテックスが常に解放されるようになり、コードが理解しやすくなり、エラーが発生しにくくなります。
データベース接続が不要になった場合は、リソースを解放するためにデータベース接続を閉じる必要があります。
func queryDatabase() error {
db, err := sql.Open("driver", "database=example")
if err != nil {
return err
}
defer db.Close() // Ensure the database connection is closed when the function exits
// Query the database...
return nil
}
作業ディレクトリを変更する場合は、元の状態に戻すことが重要です。
func changeDirectory() error {
oldDir, err := os.Getwd()
if err != nil {
return err
}
err = os.Chdir("/tmp")
if err != nil {
return err
}
defer os.Chdir(oldDir) // Restore the working directory when the function exits
// Work in /tmp...
return nil
}
遅延を使用すると、元のディレクトリを自動的に簡単に復元できます。
defer を使用すると、パニックから回復し、エラーを適切に処理できます。
func safeFunction() {
defer func() {
if r := recover(); r != nil {
log.Println("Recovered from panic:", r)
}
}()
// Code that might panic...
}
パニックを処理する関数を延期することで、予期しないエラーが発生した場合でもアプリケーションの堅牢性を確保できます。
defer は、実行時間の測定や関数の終了時のログ記録に役立ちます。
func measureTime() {
start := time.Now()
defer func() {
duration := time.Since(start)
log.Printf("Execution time: %v", duration)
}()
// Code to measure...
}
このアプローチにより、タイミング コードが簡素化され、関数の完了時に継続時間が確実に記録されます。
すべてのデータが確実に書き出されるように、バッファリングされた I/O 操作をフラッシュする必要があります。
func bufferedWrite() {
buf := bufio.NewWriter(os.Stdout)
defer buf.Flush() // Ensure the buffer is flushed when the function exits
buf.WriteString("Hello, World!")
}
ここで defer を使用すると、関数が完了する前にバッファリングされたデータが書き込まれることが保証されます。
HTTP リクエストボディは io.ReadCloser を実装しているため、リソースを解放してリークを避けるために、使用後にリクエストボディを閉じることが重要です。
func handleRequest(req *http.Request) error {
// Ensure that the request body is closed when the function exits
defer func() {
if err := req.Body.Close(); err != nil {
log.Println("Error closing request body:", err)
}
}()
body, err := io.ReadAll(req.Body)
if err != nil {
return err
}
// Process the body...
fmt.Println("Request body:", string(body))
return nil
}
req.Body.Close() を延期することで、読み取り中または処理中にエラーが発生した場合でも、ボディが適切に閉じられるようになります。
Go でファイルまたはその他のリソースを開くときは、リソースが不要になったら確実に適切に閉じることが重要です。ただし、遅延を使用せずにエラー チェック後にリソースを閉じようとすると、コードにリスクが生じる可能性があります。
file, err := os.Open(fileName)
if err != nil {
return err // Handle error
}
// Risk: If something goes wrong before this point, the file might never be closed
// Additional operations here...
file.Close() // Attempt to close the file later
Not using defer to close resources in Go can lead to unintended consequences, such as attempting to close a resource that was never successfully opened, resulting in unexpected behavior or panics. Additionally, if an error occurs before the explicit Close() call, the resource might remain open, causing leaks and exhausting system resources. As the code becomes more complex, ensuring all resources are properly closed becomes increasingly difficult, raising the likelihood of overlooking a close operation.
In Go, it's crucial to place a defer statement after verifying that a resource, like a file, was successfully opened.
Placing defer before the error check can introduce several risks and undesirable behavior.
file, err := os.Open(fileName)
defer file.Close() // Incorrect: This should be deferred after the error check
if err != nil {
return err // Handle error
}
// Additional operations here...
Placing defer file.Close() before checking if os.Open succeeded can cause several issues. If the file wasn't opened and is nil, attempting to close it will lead to a runtime panic since Go executes all deferred functions even when an error occurs. This approach also makes the code misleading, implying that the file was successfully opened when it might not have been, which complicates understanding and maintenance. Furthermore, if a panic does occur, debugging becomes more challenging, especially in complex codebases, as tracing the issue back to the misplaced defer can take additional effort.
The defer keyword in Go simplifies resource management and enhances code clarity by ensuring that cleanup actions are performed automatically when a function exits. By using defer in these common scenarios, you can write more robust, maintainable, and error-free code.
以上がGo での defer の使用: ベスト プラクティスと一般的な使用例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
