質問の歴史
Goのメモリ安全モデルは、バッファオーバーフローやメモリ破損を防ぐためにスライスおよび配列アクセスの境界チェックを義務付けています。初期のコンパイラバージョンは、実行時にこれらのチェックを無差別に実行していましたが、現代のGoツールチェーンは、実行前にインデックスの有効性を数学的に保証できる場合に冗長なチェックを排除するための高度なSSAベースの静的解析（「証明」パス）を取り入れています。
問題
境界チェックは分岐命令を導入し、CPUの命令パイプラインを混乱させ、SIMDのベクトル化を妨げ、タイトなループでのサイクル消費を大幅に増加させます。パフォーマンスが重要な分野（パケット処理や数値計算など）では、これらのチェックが実行時間の20-40％を消費し、安全だが遅いコードと危険なunsafe.Pointer操作の間で開発者に選択を強いることがあります。
解決策
Goコンパイラは、特定のパターンが検出されると境界チェックを省略します：境界内にあることが証明されたコンパイル時の定数インデックス；範囲変数が暗黙的に長さより小さいfor i := range sliceループ；同じ基本ブロック内の明示的な事前長さチェック（例：if i < len(s) { _ = s[i] }）；およびインデックスがスライスの長さより小さいことを保証するビットマスク操作（例：s[i & mask]、ここでmask = len(s)-1は2の累乗の長さ用）。
問題の説明：
毎秒数百万のUDPデータグラムを処理する高スループットパケットパーサを最適化していると、プロファイリングでruntime.panicIndexの境界チェックオーバーヘッドによってCPUサイクルの25％が消費されていることが明らかになりました。パーサは固定幅のヘッダーをバイトスライスへのインデックスアクセスを使用して抽出し、プロトコルが固定長を保証しているにもかかわらず、各フィールドアクセスで安全チェックがトリガーされました。
解決策A：unsafeを使用した手動境界チェックの持ち上げ
私たちは、関数のエントリで長さチェックを抽出し、すべての後続のチェックをバイパスするためにunsafe.Pointer演算を使用することを検討しました。このアプローチにより、分岐が完全に排除されスループットが最大化されましたが、壊滅的なセキュリティリスクをもたらしました：将来のプロトコルの変更や破損したパケットはメモリ破損を引き起こし、アーキテクチャ間で異なる整列要件を持つコードの移植性が失われました。
解決策B：スライスのリスライスパターン
アクセスパターンを書き換えて、徐々にリスライスする方法（s = s[n:]の後にs[0]）を使用すると、コンパイラは長さを証明した後にチェックを省略できました。ただし、これはプロトコルフィールドオフセットの意味を大幅に不明瞭にし、元のスライス参照を保持するための複雑な状態管理を必要とし、プロトコルバージョンの変更に対してコードが脆弱になりました。
解決策C：定数インデックスを使用した明示的な長さ検証
私たちは、明示的な長さチェックを伴うfor len(data) >= headerSize {ループにパーサを構造化し、その後に定数インデックスを使用してフィールドアクセスを行いました（例：id := binary.BigEndian.Uint16(data[0:2])）。これにより、コンパイラの証明パスが長さチェック後にdata[0:2]が有効であることを確認できるようにし、unsafeなしで自動的に境界チェックの排除を達成しました。これは、安全性と保守性のバランスを考慮して選択されました。結果は、セーフティの低下なしでスループットが30％向上しました。
なぜfor i := 0; i < len(slice); i++はfor i := range sliceと比較して境界チェックの省略に失敗することが多いのか？
候補者はしばしば、手動インデックスが範囲ループと等価であると考えます。しかし、Goコンパイラの証明パスは、rangeステートメントをi < len(slice)を構築により保証する標準パターンとして認識しますが、手動ループは、ループ変数が変更されたり、スライスがループ内で再スライスされた場合に失敗する可能性のある複雑な帰納変数分析を必要とし、境界チェックが保持されます。
ビットマスキング（i & (len-1)）は、円形バッファへのアクセス時に境界チェックの排除を保証できるのか？
ジュニア開発者は、lenが2の累乗でマスクがlen-1のとき、i & maskの式は常にlenより小さいことを見落とします。GoコンパイラのSSAバックエンドはこのイディオムを認識し、境界チェックを排除して、unsafe操作なしで高性能のリングバッファを可能にします。ただし、マスクが正しく計算され、lenが使用サイトで証明可能に定数である必要があります。
どのような状況下でインライン化の失敗が境界チェックの排除を関数境界を越えて妨げるのか？
呼び出し関数内の明示的な長さチェックが呼び出される側を保護するという一般的な誤解があります。スライスにアクセスする関数がインライン化されていない場合、コンパイラは呼び出し元の先行境界チェックに関するコンテキストを失います。その結果、小さなアクセサ関数は//go:inlineでマークされるか、証明パスが呼び出しサイトを越えて境界情報を伝播できるようにインラインのしきい値を満たさなければならず、さもなくば冗長なチェックがバイナリに残ります。