なぜ、短命オブジェクトのために **sync.Pool** を使用しているプログラムが、高い同時実行性下でオブジェクトの再利用が積極的であっても、依然として大きなヒープ成長を経験する可能性があるのか？

質問への回答

質問の歴史

Goは、1.3バージョンでsync.Poolを導入し、テンポラリオブジェクトをキャッシュしてゴミ収集器への圧力を減少させるメカニズムを提供しました。このデザインは、パフォーマンスを優先し、プロセッサーごとの（P）ローカルキャッシュを維持することで、メモリ効率と速度のトレードオフを行っています。このアーキテクチャは、高い同時実行性の下で特定の故障モードを生み出し、従来のオブジェクトプールの挙動を期待している開発者を驚かせます。

問題

ゴルーチンが Get() を呼び出すと、彼らは現在のPのローカルキャッシュにしかアクセスしません。そのキャッシュが空である場合、他のPからオブジェクトを盗むことはできますが、ゴルーチンの移動後に以前のPからオブジェクトを再利用することはできません。GOMAXPROCSが32に設定されている場合、各Pは数百のオブジェクトを蓄積することができ、メモリ成長が指数的に増加します。加えて、sync.PoolはGCサイクル中にすべてのオブジェクトをクリアし、プールが空になると新しい割り当てを強制するため、割り当て率がGCの頻度を超えると問題が悪化します。

解決策

開発者は、sync.Poolがバウンドキャッシングではなく、最善の再利用を提供することを認識する必要があります。メモリ制約のあるアプリケーションに対しては、atomicカウンタやチャネルを使用してサイズ制限を明示的に持つカスタムシャーディプールを実装してください。または、初期化中に固定サイズのバッファプールを事前に割り当て、プールが枯渇した際に発生する割り当て失敗やブロッキングを受け入れ、ヒープ成長を予測可能に保つことを確保してください。

var bufferPool = sync.Pool{
    New: func() interface{} {
        return new([4096]byte)
    },
}

func handler() {
    // 各Pは独立したキャッシュを維持する
    buf := bufferPool.Get().(*[4096]byte)
    // データを処理...
    bufferPool.Put(buf) // 現在のPのキャッシュにのみ戻す
}

実際の状況

ある金融取引プラットフォームは、sync.Poolを使用して**[]byte**バッファ用に毎秒50,000の市場データメッセージを処理していました。GOMAXPROCSが32に設定された負荷テスト中に、ヒープ使用量が数分で8GBに膨れ上がりました。これにより、理論上必要な最大バッファスペースが500MBのみであるにもかかわらず、OOMキルが発生し、重大な生産ブロッカーが発生しました。

エンジニアリングチームはまず、プールに戻されるバッファサイズを制限し、割り当てを1KBに制限しようとしました。これによりオブジェクトごとのメモリは減少しましたが、根本的な原因には対処できませんでした—各Pは依然として独立してバッファのキャッシュを蓄積し続けていました。32のプロセッサが同時に実行されているため、成長は指数的に続きます。

次に、各シャードごとに固定サイズのチャネルを持つsync.RWMutexガードを使用してカスタムシャーディプールを実装しました。これによりメモリ使用量が抑えられ、OOMエラーが防止されました。ただし、ロックの競合がスループットを40％低下させ、レイテンシに敏感な取引要件には受け入れられませんでした。

最終的に、彼らはsync.Poolを、ロックフリーのインデックス用にatomic操作を使用した手動サイズのリングバッファプールに置き換えました。これにより、メモリは2GBに制限され、スループットを維持し、プールが枯渇したときに発生する偶発的な割り当てを受け入れることができました。

彼らは、予測可能なメモリ使用量が完璧な割り当て回避を上回るため、三番目の解決策を選択しました。システムは現在、安定した1.5GBのヒープ使用量で動作し、99パーセンタイルのレイテンシは常に2ms未満です。

候補者が見逃しがちなこと

なぜ、sync.PoolがPut()が複数回呼び出された後でもGet()でnilを返すのか？

sync.Poolは、オブジェクトの保持を保証しないため、nilを返す可能性があります。ガーベジコレクションのサイクル中に、ランタイムはすべてのプールを完全にクリアし、最近使用されたかどうかに関係なく、すべてのキャッシュオブジェクトを削除します。さらに、ゴルーチンがP間を移動する場合、以前のPのローカルキャッシュに保存されたオブジェクトにアクセスできず、新しいPのプールが空である場合、**Get()**はnilを返すことになります。候補者はしばしば、sync.Poolが保証された永続性を持つ従来のキャッシュのように機能すると推定しますが、最善の努力による再利用のみを提供します。

sync.Poolは、ポインタを含むオブジェクトをどのように処理し、これはGCパフォーマンスにとってなぜ重要なのか？**

sync.Poolがポインタを含むオブジェクトを格納すると、それらのオブジェクトはGCスキャンを生き残ります。これはプールがそれらへの参照を維持するためです。これにより、ガーベジコレクタはこれらのオブジェクトが指すメモリを回収できず、次のGCサイクルがプールをクリアするまで、オブジェクトグラフ全体が生存し続けます。高パフォーマンスシステムの場合、候補者はポインタのないオブジェクトを格納するか、**Put()**の前に手動でポインタをnilに設定して、GCが参照されたメモリを回収できるようにし、ヒープ圧力を大幅に減少させるべきです。

sync.Poolの並行する**Put()とGet()操作に関する具体的なスレッド安全性の保証は何か？

sync.Poolは、外部同期なしで複数のゴルーチンによる同時使用に対して完全に安全です。しかし、候補者はしばしば、sync.PoolがLast-In-First-OutまたはFirst-In-First-Outの順序を保証しないこと、つまり、取得順序はPスケジューリングに基づいてランダムであることを見落とします。さらに、**Get()**によって返されるオブジェクトはゼロクリアされず、前のユーザーが残した状態が含まれるため、データ競合を防ぐためには手動でリセットする必要があります。