package
1.23.0
Repository: https://github.com/shogo82148/std.git
Documentation: pkg.go.dev

# Packages

cgoパッケージは、cgoツールによって生成されたコードの実行時サポートを含んでいます。cgoの使用方法の詳細については、cgoコマンドのドキュメントを参照してください。 */.
No description provided by the author
debug パッケージには、プログラムが実行中に自己デバッグするための機能が含まれています。.
Package metrics provides a stable interface to access implementation-defined metrics exported by the Go runtime.
pprofパッケージは、pprof視覚化ツールで期待される形式でランタイムプロファイリングデータを書き込みます。 # Goプログラムのプロファイリング Goプログラムをプロファイリングする最初のステップは、プロファイリングを有効にすることです。 標準のテストパッケージでビルドされたベンチマークのプロファイリングをサポートするためには、go testに組み込まれています。 たとえば、次のコマンドは現在のディレクトリでベンチマークを実行し、CPUプロファイルとメモリプロファイルをcpu.profとmem.profに書き込みます: go test -cpuprofile cpu.prof -memprofile mem.prof -bench .
raceパッケージはデータ競合検出ロジックを実装しています。 パブリックなインターフェースは提供されていません。 レースディテクターの詳細については、以下を参照してください。 https://golang.org/doc/articles/race_detector.html.
traceパッケージには、Go実行トレーサーのためのトレースを生成するプログラムの機能が含まれています。 # Tracing runtime activities 実行トレースは、ゴルーチンの作成/ブロック/アンブロック、システムコールの入力/出力/ブロック、 GC関連のイベント、ヒープサイズの変更、プロセッサの開始/停止など、幅広い実行イベントをキャプチャします。 CPUプロファイリングがアクティブな場合、実行トレーサーはこれらのサンプルも含めるように努力します。 ほとんどのイベントに対して、正確なナノ秒精度のタイムスタンプとスタックトレースがキャプチャされます。 生成されたトレースは `go tool trace` を使用して解釈することができます。 標準のテストパッケージで構築されたテストとベンチマークのトレースのサポートは、 `go test`に組み込まれています。例えば、以下のコマンドは現在のディレクトリでテストを実行し、 トレースファイル(trace.out)を書き出します。 go test -trace=trace.out このruntime/traceパッケージは、同等のトレーシングサポートをスタンドアロンのプログラムに追加するためのAPIを提供します。 このAPIを使用してトレーシングを有効にする方法を示す例を参照してください。 また、トレースデータには標準的なHTTPインターフェースもあります。以下の行を追加すると、 /debug/pprof/trace URLの下にハンドラがインストールされ、ライブトレースをダウンロードできます: import _ "net/http/pprof" このインポートによってインストールされたすべてのデバッグエンドポイントについての詳細は、 [net/http/pprof] パッケージを参照してください。 # User annotation traceパッケージは、実行中の興味深いイベントをログに記録するために使用できる ユーザー注釈APIを提供します。 ユーザー注釈には3つのタイプがあります:ログメッセージ、領域、タスク。 [Log] は、メッセージのカテゴリや [Log] を呼び出したゴルーチンなどの追加情報とともに、 実行トレースにタイムスタンプ付きのメッセージを発行します。実行トレーサーは、 ログカテゴリと [Log] で提供されるメッセージを使用してゴルーチンをフィルタリング およびグループ化するUIを提供します。 リージョンは、ゴルーチンの実行中の時間間隔をログに記録するためのものです。 定義上、リージョンは同じゴルーチンで開始し終了します。 リージョンは、サブインターバルを表すためにネストすることができます。 例えば、次のコードは、カプチーノ作成操作の連続したステップの期間をトレースするために、 実行トレースに4つのリージョンを記録します。 trace.WithRegion(ctx, "makeCappuccino", func() { // orderIDは、多くのカプチーノ注文領域レコードの中から特定の注文を識別するために使用します。 trace.Log(ctx, "orderID", orderID) trace.WithRegion(ctx, "steamMilk", steamMilk) trace.WithRegion(ctx, "extractCoffee", extractCoffee) trace.WithRegion(ctx, "mixMilkCoffee", mixMilkCoffee) }) タスクは、RPCリクエスト、HTTPリクエスト、または複数のゴルーチンが協力して行う必要がある 興味深いローカル操作など、論理的な操作のトレースを支援する高レベルのコンポーネントです。 タスクは複数のゴルーチンを含む可能性があるため、[context.Context] オブジェクトを介して追跡されます。 [NewTask] は新しいタスクを作成し、それを返された [context.Context] オブジェクトに埋め込みます。 ログメッセージとリージョンは、[Log] と [WithRegion] に渡されたContextにあるタスク(存在する場合)に添付されます。 例えば、ミルクを泡立て、コーヒーを抽出し、ミルクとコーヒーを別々のゴルーチンで混ぜることにしました。 タスクを使用すると、トレースツールは特定のカプチーノ注文に関与するゴルーチンを識別できます。 ctx, task := trace.NewTask(ctx, "makeCappuccino") trace.Log(ctx, "orderID", orderID) milk := make(chan bool) espresso := make(chan bool) go func() { trace.WithRegion(ctx, "steamMilk", steamMilk) milk <- true }() go func() { trace.WithRegion(ctx, "extractCoffee", extractCoffee) espresso <- true }() go func() { defer task.End() // アセンブルが完了したら、注文は完了します。 <-espresso <-milk trace.WithRegion(ctx, "mixMilkCoffee", mixMilkCoffee) }() トレースツールは、タスクの作成とタスクの終了の間の時間を測定することでタスクの遅延を計算し、 トレース内で見つかった各タスクタイプの遅延分布を提供します。.

# Functions

BlockProfileは現在のブロッキングプロファイルのレコード数nを返します。 もしlen(p) >= nの場合、BlockProfileはプロファイルをpにコピーし、nとtrueを返します。 もしlen(p) < nの場合、BlockProfileはpを変更せずに、nとfalseを返します。 ほとんどのクライアントは、 [runtime/pprof] パッケージや [testing] パッケージの-test.blockprofileフラグを使用して、 BlockProfileを直接呼び出す代わりに使用すべきです。.
ブレークポイントはブレークポイントトラップを実行します。.
Callerは、呼び出し元のゴルーチンのスタック上での関数呼び出しに関するファイルと行番号情報を報告します。 引数skipは、上昇するスタックフレームの数であり、0はCallerの呼び出し元を識別します。 (歴史的な理由から、skipの意味はCallerと [Callers] で異なります。) 戻り値は、対応する呼び出しのプログラムカウンタ、ファイル名、およびファイル内の行番号を報告します。 情報を回復できなかった場合、ブール値okはfalseです。.
Callersは、呼び出し元のゴルーチンのスタック上での関数呼び出しの戻りプログラムカウンタを、スライスpcで埋めます。 引数skipは、pcに記録する前にスキップするスタックフレームの数であり、0はCallers自体のフレームを識別し、1はCallersの呼び出し元を識別します。 pcに書き込まれたエントリ数を返します。 これらのPCを関数名や行番号などの記号情報に変換するには、[CallersFrames] を使用します。 CallersFramesはインライン化された関数を考慮に入れ、戻りプログラムカウンタを 呼び出しプログラムカウンタに調整します。返されたPCのスライスを直接反復処理することは 勧められません。また、返されたPCのいずれかに [FuncForPC] を使用することも、 インライン化や戻りプログラムカウンタの調整を考慮に入れられないため、勧められません。.
CallersFramesは [Callers] によって返されるPC値のスライスを受け取り、 関数/ファイル/行情報を返す準備をします。 [Frames] で終わるまでスライスを変更しないでください。.
CPUProfileはパニックします。 以前はランタイムによって生成されたpprof形式のプロファイルの チャンクへの直接的なアクセスを提供していました。 その形式を生成する方法が変更されたため、 この機能は削除されました。 Deprecated: [runtime/pprof] パッケージ、 または [net/http/pprof] パッケージのハンドラ、 または [testing] パッケージの-test.cpuprofileフラグを代わりに使用してください。.
FuncForPCは、指定されたプログラムカウンターアドレスを含む関数を記述した*[Func] を返します。もし複数の関数がインライン展開の影響で存在する場合は、最も内側の関数を示す*Funcを返しますが、最も外側の関数のエントリーも持っています。 完全に不明な理由で、runtimeをインポートできるにもかかわらず、 いくつかの広く使用されているパッケージはこれをlinknameを使用してアクセスします。 恥の殿堂に名を連ねる注目のメンバーには以下が含まれます: - gitee.com/quant1x/gox 型シグネチャを変更または削除しないでください。 go.dev/issue/67401 を参照してください。 go:linkname FuncForPC.
GCはガベージコレクションを実行し、呼び出し元が完了するまで呼び出し元をブロックします。 プログラム全体をブロックする場合もあります。.
Goexitはそれを呼び出したゴルーチンを終了します。他のゴルーチンには影響を与えません。 Goexitは終了する前にすべての延期呼び出しを実行します。Goexitはパニックではないため、 これらの延期された関数内のrecover呼び出しはnilを返します。 メインゴルーチンからGoexitを呼び出すと、そのゴルーチンはfunc mainが戻らない状態で終了します。 func mainが戻っていないため、プログラムは他のゴルーチンの実行を継続します。 他のすべてのゴルーチンが終了すると、プログラムはクラッシュします。.
GOMAXPROCSは同時に実行できる最大CPU数を設定し、前の設定を返します。デフォルトは [runtime.NumCPU] の値です。nが1未満の場合、現在の設定は変更されません。スケジューラの改善が行われると、この呼び出しはなくなります。.
GOROOTは、Goツリーのルートを返します。プロセス開始時に設定されている場合はGOROOT環境変数を使用し、 それ以外の場合はGoビルド中に使用されたルートを使用します。.
GoroutineProfileはアクティブなゴルーチンスタックプロファイルのレコード数であるnを返します。 もしlen(p)がn以上であれば、GoroutineProfileはプロファイルをpにコピーしnとtrueを返します。 もしlen(p)がn未満であれば、GoroutineProfileはpを変更せずにnとfalseを返します。 ほとんどのクライアントは直接GoroutineProfileを呼び出す代わりに [runtime/pprof] パッケージを使用するべきです。.
Gosched はプロセッサを譲り、他のゴルーチンが実行されるようにします。現在のゴルーチンは一時停止されませんが、実行は自動的に再開されます。 go:nosplit.
KeepAliveは、引数を現在到達可能なものとしてマークします。 これにより、オブジェクトが解放されず、そのファイナライザが実行されないようになります。 KeepAliveが呼び出されたプログラムのポイントより前に。 KeepAliveが必要な場所を示す非常に簡単な例: type File struct { d int } d, err := syscall.Open("/file/path", syscall.O_RDONLY, 0) // ..
LockOSThreadは呼び出し側のゴルーチンを現在のオペレーティングシステムスレッドに接続します。 呼び出し側のゴルーチンは常にそのスレッドで実行され、他のゴルーチンは実行されません。 それまでのLockOSThreadへの呼び出し回数と同じ数だけ、[UnlockOSThread] への呼び出しを行うまで、呼び出し側のゴルーチン以外は実行されません。 呼び出し側のゴルーチンがスレッドのロックを解除せずに終了すると、スレッドは終了します。 すべてのinit関数は起動時のスレッド上で実行されます。init関数からLockOSThreadを呼び出すと、main関数がそのスレッド上で呼び出されます。 ゴルーチンは、スレッドごとの状態に依存するOSサービスや非Goライブラリ関数を呼び出す前に、LockOSThreadを呼び出す必要があります。 go:nosplit.
MemProfileは、割り当てられたメモリと解放されたメモリのプロファイルを、割り当ての場所別に返します。 MemProfileは、現在のメモリプロファイルのレコード数であるnを返します。 もしlen(p) >= nであれば、MemProfileはプロファイルをpにコピーし、nとtrueを返します。 もしlen(p) < nであれば、MemProfileはpを変更せずに、nとfalseを返します。 inuseZeroがtrueの場合、プロファイルにはr.AllocBytes > 0 かつ r.AllocBytes == r.FreeBytesのアロケーションレコードが含まれます。 これは、メモリが割り当てられたがランタイムにすべて解放された場所です。 返されるプロファイルは、最大で2つのガベージコレクションサイクル前のものです。 これは、プロファイルがアロケーションに偏った結果にならないようにするためです。 アロケーションはリアルタイムで発生しますが、解放はガベージコレクタがスイーピングを実行するまで遅延されるため、 プロファイルはガベージコレクタによって解放されるチャンスを持ったアロケーションのみをカウントします。 多くのクライアントは、runtime/pprofパッケージまたはtestingパッケージの-test.memprofileフラグを直接呼び出す代わりに使用するべきです。.
MutexProfileは現在のmutexプロファイルのレコード数であるnを返します。 もしlen(p) >= nならば、MutexProfileはプロファイルをpにコピーしてnとtrueを返します。 そうでなければ、MutexProfileはpを変更せずにnとfalseを返します。 ほとんどのクライアントは、MutexProfileを直接呼び出す代わりに [runtime/pprof] パッケージを使用するべきです。.
NumCgoCall は現在のプロセスによって行われた cgo 呼び出しの数を返します。.
NumCPUは現在のプロセスで使用可能な論理CPUの数を返します。 利用可能なCPUのセットはプロセスの起動時にオペレーティングシステムによって確認されます。 プロセスの起動後にオペレーティングシステムのCPU割り当てに変更があっても、それは反映されません。.
NumGoroutineは現在存在するゴルーチンの数を返します。.
ReadMemStatsはメモリアロケータ統計情報をmに書き込みます。 返されるメモリアロケータ統計情報はReadMemStatsの呼び出し時点で最新のものです。 これは、ヒーププロファイルとは異なり、最新のガベージコレクションサイクルのスナップショットです。.
ReadTrace はバイナリ追跡データの次のチャンクを返します。データが利用可能になるまでブロックされます。もし追跡がオフになっており、オンの間に蓄積されたデータがすべて返された場合、ReadTrace は nil を返します。呼び出し元は、再度 ReadTrace を呼び出す前に返されたデータをコピーする必要があります。 ReadTrace は一度に1つの goroutine から呼び出す必要があります。.
SetBlockProfileRateは、ブロッキングイベントの割合を制御します。 プロファイラは、ブロックされた時間がrateナノ秒ごとに平均1つのブロッキングイベントをサンプリングすることを目指しています。 プロファイルにすべてのブロッキングイベントを含めるには、rate = 1を渡します。 プロファイリングを完全にオフにするには、rate <= 0を渡します。.
SetCgoTracebackは、Cコードからトレースバック情報を収集し、そのトレースバック情報をシンボル情報に変換するために使用する3つのC関数を記録します。 これらは、cgoを使用するプログラムのスタックトレースを印刷するときに使用されます。 トレースバックとコンテキスト関数は、シグナルハンドラから呼び出すことができるため、 非同期シグナルセーフ関数のみを使用する必要があります。 シンボライザ関数は、プログラムがクラッシュしている間に呼び出される可能性があるため、 メモリの使用に注意する必要があります。これらの関数のいずれも、Goにコールバックすることはできません。 context関数は、構造体へのポインタを単一の引数として呼び出されます。 struct { Context uintptr } In C syntax, this struct will be struct { uintptr_t Context; }; Contextフィールドが0の場合、context関数は現在のトレースバックコンテキストを記録するために呼び出されます。 おそらくスタックポインタとPCなど、後でスタックトレースを生成するために必要な現在の実行ポイントに関する情報をContextフィールドに記録する必要があります。 この場合、context関数はCコードから呼び出されます。 Contextフィールドが0でない場合、それは以前のcontext関数の呼び出しで返された値です。 この場合、GoコードがCコードの呼び出し元に戻るとき、つまりコンテキストが不要になったときに呼び出されます。 これにより、context関数は関連するリソースを解放できます。 context関数が呼び出されるたびに完全なスタックトレースを記録し、 traceback関数でそれを単にコピーすることが正しいと言えますが、 典型的なプログラムでは、context関数はそのコンテキストのためにトレースバックを記録することなく多数の呼び出しが行われます。 context関数の呼び出しで完全なスタックトレースを記録することは、効率的ではない可能性があります。 traceback関数は、構造体へのポインタを単一の引数として呼び出されます。 struct { Context uintptr SigContext uintptr Buf *uintptr Max uintptr } In C syntax, this struct will be struct { uintptr_t Context; uintptr_t SigContext; uintptr_t* Buf; uintptr_t Max; }; Contextフィールドが0の場合、現在のプログラム実行ポイントからトレースバックを収集するために使用されます。 この場合、traceback関数はCコードから呼び出されます。 それ以外の場合、Contextは以前のcontext関数の呼び出しで返された値です。 traceback関数は、その保存されたプログラム実行ポイントからスタックトレースを収集する必要があります。 traceback関数は、コンテキストが有効で変更されていないことがわかっている場合にのみ、 コンテキストを記録した実行スレッド以外の実行スレッドから呼び出すことができます。 traceback関数は、同じスレッドでコンテキストを記録した深い呼び出しスタックでも呼び出すことができます。 traceback関数は、同じContext値で複数回呼び出されることがあります。 特定のコンテキスト値に対して最初に呼び出された場合、可能であれば結果をキャッシュするのが通常適切です。 Unixシステムのシグナルハンドラからtraceback関数が呼び出された場合、 SigContextはシグナルハンドラに渡されたシグナルコンテキスト引数です(uintptr_tにキャストされたCのucontext_t*)。 これを使用して、シグナルが発生したポイントからトレースを開始できます。 traceback関数がシグナルハンドラから呼び出されていない場合、SigContextはゼロになります。 Bufはトレースバック情報を格納する場所です。 Buf[0]が呼び出し元のPCであり、Buf[1]がその関数の呼び出し元のPCであるような、PC値である必要があります。 Maxは格納するエントリの最大数です。 関数は、スタックのトップを示すためにゼロを格納する必要があります。 または、呼び出し元が別のスタック、おそらくGoスタックにあることを示します。 runtime.Callersとは異なり、返されるPC値は、 シンボライザ関数に渡された場合、呼び出し命令のファイル/行を返す必要があります。 追加の減算は必要ありません。また、適切ではありません。 すべてのプラットフォームで、トレースバック関数は、GoからCへの呼び出しとCからGoへの呼び出しの間でスタックトレースを要求する場合に呼び出されます。 linux/amd64、linux/ppc64le、linux/arm64、およびfreebsd/amd64では、トレースバック関数は、cgo呼び出しを実行しているスレッドがシグナルを受信した場合にも呼び出されます。 トレースバック関数は、いつ呼び出されるかについての仮定をするべきではありません。将来のGoのバージョンでは、追加の呼び出しが行われる可能性があります。 シンボライザ関数は、構造体へのポインタを単一の引数として呼び出されます。 struct { PC uintptr // 情報を取得するプログラムカウンタ File *byte // ファイル名(NULで終わる) Lineno uintptr // 行番号 Func *byte // 関数名(NULで終わる) Entry uintptr // 関数のエントリポイント More uintptr // このPCに対してさらに情報がある場合は非ゼロに設定します Data uintptr // ランタイムによって使用されない、関数で使用可能なデータ } C言語の構文では、この構造体は次のようになります。 struct { uintptr_t PC; char* File; uintptr_t Lineno; char* Func; uintptr_t Entry; uintptr_t More; uintptr_t Data; }; PCフィールドは、traceback関数の呼び出しで返される値です。 トレースバック関数が特定のトレースバックに対して最初に呼び出された場合、 PC以外のすべてのフィールドは0になります。 情報が利用できない場合は、フィールドを0/nilに設定して、他のフィールドを埋める必要があります。 Dataフィールドは、呼び出し間で有用な情報を格納するために使用できます。 Moreフィールドは、このPCに対してさらに情報がある場合は非ゼロに設定します。 Moreが非ゼロに設定されている場合、同じPCで再度呼び出され、異なる情報を返すことができます(これはインライン関数で使用するために意図されています)。 Moreがゼロの場合、次のPC値でトレースバック関数が呼び出されます。 トレースバックが完了すると、PCがゼロに設定された状態で関数が1回呼び出されます。 これは、情報を解放するために使用できます。 各呼び出しでは、Moreフィールドがゼロである場合を除き、構造体のフィールドが呼び出し前と同じ値に設定されたままになります。 関数は、呼び出し間で構造体ポインタのコピーを保持してはいけません。 SetCgoTracebackを呼び出すとき、version引数は関数が受け取る構造体のバージョン番号です。 現在、これは0でなければなりません。 シンボライザ関数がnilの場合、トレースバック関数の結果は数値として表示されます。 トレースバック関数がnilの場合、シンボライザ関数は呼び出されません。 コンテキスト関数がnilの場合、トレースバック関数はコンテキストフィールドが0に設定された状態でのみ呼び出されます。 コンテキスト関数がnilの場合、GoからCへの呼び出しでは、C部分の呼び出しスタックのトレースバックは表示されません。 SetCgoTracebackは、理想的にはinit関数から1回だけ呼び出す必要があります。.
SetCPUProfileRateはCPUプロファイリングのレートをhzサンプル/秒に設定します。 hz <= 0の場合、プロファイリングはオフになります。 プロファイラがオンの場合、レートを変更する前にオフにする必要があります。 ほとんどのクライアントは、[runtime/pprof] パッケージまたは [testing] パッケージの-test.cpuprofileフラグを直接呼び出す代わりに使用するべきです。.
SetFinalizerは、objに関連付けられたファイナライザを提供されたファイナライザ関数に設定します。 ガベージコレクタが関連付けられたファイナライザを持つ到達不能なブロックを見つけると、 関連付けをクリアし、別のゴルーチンでfinalizer(obj)を実行します。 これにより、objは再び到達可能になりますが、関連付けられたファイナライザはなくなります。 SetFinalizerが再度呼び出されない限り、次にガベージコレクタがobjが到達不能であることを検出した場合、objは解放されます。 SetFinalizer(obj, nil)は、objに関連付けられたファイナライザをクリアします。 引数objは、newを呼び出すことによって割り当てられたオブジェクトへのポインタ、 複合リテラルのアドレスを取得することによって、またはローカル変数のアドレスを取得することによって割り当てられたオブジェクトへのポインタである必要があります。 引数finalizerは、objの型に割り当てることができる単一の引数を取る関数であり、任意の無視される戻り値を持つことができます。 これらのいずれかがtrueでない場合、SetFinalizerはプログラムを中止する可能性があります。 ファイナライザは依存関係の順序で実行されます。 AがBを指し示し、両方にファイナライザがあり、それらが到達不能である場合、Aのファイナライザのみが実行されます。 Aが解放された後、Bのファイナライザが実行されます。 ファイナライザを持つブロックを含む循環構造がある場合、その循環はガベージコレクトされることは保証されず、 依存関係を尊重する順序がないため、ファイナライザが実行されることも保証されません。 ファイナライザは、プログラムがobjが指し示すオブジェクトに到達できなくなった後、 任意の時点で実行されるようにスケジュールされます。 プログラムが終了する前にファイナライザが実行されることは保証されていないため、 通常、長時間実行されるプログラム中にオブジェクトに関連付けられた非メモリリソースを解放するためにのみ有用です。 たとえば、[os.File] オブジェクトは、プログラムがCloseを呼び出さずにos.Fileを破棄するときに、 関連するオペレーティングシステムのファイルディスクリプタを閉じるためにファイナライザを使用できますが、 bufio.WriterのようなインメモリI/Oバッファをフラッシュするためにファイナライザに依存することは誤りです。 なぜなら、プログラムが終了するときにバッファがフラッシュされないためです。 *objのサイズがゼロバイトの場合、ファイナライザが実行されることは保証されません。 なぜなら、メモリ内の他のゼロサイズのオブジェクトと同じアドレスを共有する可能性があるためです。 詳細については、https://go.dev/ref/spec#Size_and_alignment_guarantees を参照してください。 パッケージレベルの変数の初期化子で割り当てられたオブジェクトに対して、 ファイナライザが実行されることは保証されません。 このようなオブジェクトはヒープに割り当てられるのではなく、リンカによって割り当てられる可能性があります。 ファイナライザがオブジェクトが参照されなくなってから任意の時間が経過した後に実行される可能性があるため、 ランタイムは、オブジェクトを単一の割り当てスロットにまとめるスペース節約の最適化を実行できます。 そのような割り当て内の参照されなくなったオブジェクトのファイナライザは、常に参照されたオブジェクトと同じバッチに存在する場合、実行されない可能性があります。 通常、このバッチ処理は、小さな(16バイト以下の)ポインタフリーオブジェクトに対してのみ行われます。 ファイナライザは、オブジェクトが到達不能になるとすぐに実行される可能性があります。 ファイナライザを正しく使用するためには、プログラムはオブジェクトが不要になるまで到達可能であることを保証する必要があります。 グローバル変数に格納されたオブジェクトや、グローバル変数からポインタをたどって見つけることができるオブジェクトは到達可能です。 関数の引数やレシーバは、関数がそれを最後に言及する時点で到達不能になる可能性があります。 到達不能なオブジェクトを到達可能にするためには、そのオブジェクトを [KeepAlive] 関数の呼び出しに渡して、 関数内でオブジェクトが到達可能でなければならない最後の時点をマークします。 たとえば、pがファイルディスクリプタdを含むos.Fileのような構造体を指し示す場合、 pにはdを閉じるファイナライザがあり、pの最後の使用がsyscall.Write(p.d、buf、size)の呼び出しである場合、 プログラムがsyscall.Writeに入るとすぐにpが到達不能になる可能性があります。 その瞬間にファイナライザが実行され、p.dを閉じ、syscall.Writeが閉じられたファイルディスクリプタ(または、 より悪い場合、別のgoroutineによって開かれた完全に異なるファイルディスクリプタ)に書き込もうとして失敗する可能性があります。 この問題を回避するには、syscall.Writeの呼び出し後にKeepAlive(p)を呼び出します。 プログラムのすべてのファイナライザを、1つのgoroutineが順次実行します。 ファイナライザが長時間実行する必要がある場合は、新しいgoroutineを開始することで実行する必要があります。 Goのメモリモデルの用語で、SetFinalizer(x、f)の呼び出しは、 ファイナライザ呼び出しf(x)の前に「同期」します。 ただし、KeepAlive(x)またはxの他の使用がf(x)の前に「同期」されることは保証されていないため、 一般的には、ファイナライザがxの可変状態にアクセスする必要がある場合は、ミューテックスまたは他の同期メカニズムを使用する必要があります。 たとえば、x内の時折変更される可変フィールドを検査するファイナライザを考えてみましょう。 xが到達不能になり、ファイナライザが呼び出される前に、メインプログラムで時折変更される場合。 メインプログラムでの変更とファイナライザでの検査は、読み書き競合を回避するために、ミューテックスやアトミック更新などの適切な同期を使用する必要があります。.
SetMutexProfileFractionは、mutexの衝突イベントのうち、 プロファイルに報告される割合を制御します。平均して1/rateのイベントが報告されます。 以前のrateが返されます。 プロファイリングを完全に無効にするには、rateに0を渡します。 現在のrateだけを読み取るには、rateに0より小さい値を渡します。 (n>1の場合、サンプリングの詳細が変更される場合があります。).
Stackは呼び出し元のゴルーチンのスタックトレースをbufに書き込み、 bufに書き込まれたバイト数を返します。 allがtrueの場合、現在のゴルーチンのトレースの後に、 他のすべてのゴルーチンのスタックトレースをbufに書き込みます。.
StartTraceは現在のプロセスのトレースを有効にします。 トレース中はデータがバッファされ、[ReadTrace] を介して利用可能です。 トレースが既に有効化されている場合、StartTraceはエラーを返します。 ほとんどのクライアントは [runtime/trace] パッケージや [testing] パッケージの-test.traceフラグを直接呼び出す代わりに使用するべきです。.
StopTraceは、以前に有効にされていた場合にトレースを停止します。 StopTraceは、トレースのすべての読み取りが完了するまで戻りません。.
ThreadCreateProfileはスレッド作成プロファイル内のレコード数であるnを返します。 もし、len(p) >= nならば、ThreadCreateProfileはプロファイルをpにコピーしてn, trueを返します。 もし、len(p) < nならば、ThreadCreateProfileはpを変更せずにn, falseを返します。 大抵のクライアントは直接ThreadCreateProfileを呼び出す代わりに、runtime/pprofパッケージを使用すべきです。.
UnlockOSThreadは、以前のLockOSThread呼び出しを取り消します。 呼び出し元のゴルーチンのアクティブなLockOSThread呼び出し数がゼロになると、 呼び出し元のゴルーチンは固定されたオペレーティングシステムスレッドからの接続が解除されます。 アクティブなLockOSThread呼び出しがない場合、これは無効操作です。 UnlockOSThreadを呼び出す前に、呼び出し元は他のゴルーチンを実行するためにOSスレッドが適していることを確認する必要があります。 呼び出し元が他のゴルーチンに影響を与えるスレッドの状態に対して恒久的な変更を行った場合、 この関数を呼び出さずにゴルーチンをOSスレッドにロックしたままにしておくべきです。 go:nosplit.
Versionは、Goツリーのバージョン文字列を返します。 ビルド時のコミットハッシュと日付、または可能な場合は「go1.3」のようなリリースタグです。.

# Constants

Compilerは、実行中のバイナリを構築したコンパイラツールチェーンの名前です。既知のツールチェーンは次のとおりです: gc cmd/compileとしても知られています。 gccgo GCCコンパイラスイートの一部であるgccgoフロントエンドです。.
GOARCHは、実行中のプログラムのアーキテクチャターゲットです。 386、amd64、arm、s390xなどのいずれかです。.
GOOSは実行中のプログラムのオペレーティングシステムターゲットです。 darwin、freebsd、linuxなどのいずれかです。 GOOSとGOARCHの可能な組み合わせを表示するには、「go tool dist list」と入力してください。.

# Variables

MemProfileRateは、メモリプロファイルに記録および報告されるメモリ割り当ての割合を制御します。 プロファイラは、MemProfileRateバイトあたり平均1回の割り当てをサンプリングすることを目指しています。 プロファイルにすべての割り当てブロックを含めるには、MemProfileRateを1に設定します。 プロファイリングを完全にオフにするには、MemProfileRateを0に設定します。 メモリプロファイルを処理するツールは、プロファイルの割合がプログラムの生存期間全体で一定であり、現在の値と等しいと想定しています。 メモリプロファイリングの割合を変更するプログラムは、できるだけ早く(たとえば、mainの開始時などに)1度だけ行う必要があります。.

# Structs

BlockProfileRecordは、特定の呼び出しシーケンス(スタックトレース)で発生したブロッキングイベントを記述します。.
Frameは各コールフレームごとに [Frames] によって返される情報です。.
Framesを使用すると、[Callers] が返すPC値のスライスのための関数/ファイル/行情報を取得できます。.
Funcは実行中のバイナリ内のGo関数を表します。.
MemProfileRecordは、特定の呼び出しシーケンス(スタックトレース)によって割り当てられた生きているオブジェクトを記述します。.
MemStatsはメモリアロケータに関する統計情報を記録します。.
PanicNilErrorは、コードがpanic(nil)を呼び出したときに発生します。 Go 1.21より前のバージョンでは、panic(nil)を呼び出すプログラムでは、recoverがnilを返すことが観察されました。 Go 1.21以降、panic(nil)を呼び出すプログラムでは、recoverが*PanicNilErrorを返すことが観察されます。 プログラムは、GODEBUG=panicnil=1を設定することで古い動作に戻すことができます。.
Pinnerは、メモリ内の固定された場所に各Goオブジェクトが固定されたセットです。 [Pinner.Pin]メソッドは1つのオブジェクトを固定し、[Pinner.Unpin]メソッドはすべての固定されたオブジェクトを解除します。 詳細については、それぞれのコメントを参照してください。.
StackRecordは単一の実行スタックを説明します。.
TypeAssertionErrorは、型アサーションの失敗を説明します。.

# Interfaces

Error インターフェースはランタイムエラーを識別します。.