Goではリソース管理にプラグマティックなアプローチが採用されています。他の言語でおなじみのtry-finallyの代わりに、ここではdeferが導入されています。これは、"遅延"関数を保持し、スコープを抜ける際にそれを実行する組み込みメカニズムです。このツールは、リソース（ファイル、ネットワーク接続など）の自動解放に頻繁に使用されます。
ファイルや接続のCloseを呼び出すのを忘れると、リソースのリークやブロッキングが発生する可能性があります。これはサーバーアプリケーションやファイルアプリケーションにおいて非常に重要です。deferによる遅延呼び出しは、エラーやpanicが発生した場合でも終了関数の呼び出しを保証します。しかし、deferの誤用がエラーを引き起こす特別なケースもあります。例えば、ループ内でdeferを呼び出したり、不正なオブジェクトを渡したり、大量のdeferを使用することはオーバーヘッドを引き起こす可能性があります。
リソースを正常に開いた直後に**defer f.Close()**を常に呼び出して、忘れた閉鎖を避けてください。非常に多くのファイルを開く場合は、パフォーマンスとメモリの節約のために、密なループ内でdeferを使用しないでください。ファイル/リソースを開く処理を関数にラップし、スコープを最小化するように努力してください。
コード例:
file, err := os.Open("data.txt") if err != nil { log.Fatal(err) } defer file.Close() // 確実な閉鎖 // ... ファイルでの作業
主な特徴:
deferはいつ実行され、そのパラメータはどのように計算されますか？
deferでの関数のパラメータは、deferが実行される際ではなく、deferが宣言される時点で計算されます。
コード例:
func main() { a := 1 defer fmt.Println(a) // 1を記憶します a = 42 } // 1が出力されます
deferを使用すると、メモリリークやパフォーマンスの低下を引き起こす可能性がありますか？
はい。ループ内で多くのファイルやオブジェクトを開く場合にdeferを使用すると、各deferは遅延呼び出しのスタックに記録され、関数から出るまでクリーンアップされません。これにより、メモリが不必要に増加します。
コード例:
for i := 0; i < 10000; i++ { f, _ := os.Open("file.txt") defer f.Close() // mainの最後まで全ての10000ファイルを保持します }
f.Close()の呼び出しがエラーを返し、それが「飲み込まれた」場合はどうなりますか？
リソースの閉鎖エラーをログに記録することは標準的な実践です。このポイントを無視すると、ファイルの障害や部分的な保存に気づかない可能性があります。たとえば、一時ファイルの削除不可能な場合やネットワークの障害などです。
ファイル処理のループ内で、開くファイルごとにdefer f.Close()を設定します。その結果、数万のファイルが同時に開かれ、プログラムの実行が遅くなり、システムでファイルディスクリプタが終了します。
長所:
短所:
各ファイルの処理は、defer f.Close()が一度だけ実行され、そのリソースをすぐに解放する別の関数内で行います。
長所:
短所: