backpressure
流し込みが速すぎるときに、書き込み側を待たせて増えすぎを防ぐ仕組み。
- 概念URI
https://comcomponent.com/knowledge/backpressure/- 別名・表記
- バックプレッシャー
- 最終確認日
- 2026-08-01
- 機械可読データ
- JSON-LD
この概念が関わる関係
- Channel<T>はbackpressureを利用します。Channel<T>を境界付き(bounded)で作った場合、書き込み側を待たせて増えすぎを防ぐbackpressureが働く。unboundedで使う場合は働かない。backpressure自体はChannel<T>に限らず成り立つ考え方である / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
- Windowsスレッドプールはbackpressureを前提とします。プールが制限するのはワーカースレッドの数だけで、投函された未実行のコールバックは積み上がる。投入が処理を上回り続ける構成では、アプリ側にセマフォなどの入場制限か容量付きキューを置いて、満杯時に投入側が待つ形にする。 / 確度: 条件付きの関係 / 確認日: 2026-08-02 出典
- 有限バッファーはbackpressureの実装を担います。容量に上限のある有限循環バッファーは、生産が消費を追い越したら生産側が待つという自然な背圧になる。 / 確度: 確立した関係 / 確認日: 2026-08-22 出典
- Channel<T>はbackpressureの実装を担います。CreateBoundedで容量上限付きのチャネルを作ると、上限到達時の既定動作は書き込み側の待機になり、書き込みが読み出しより速い場合に背圧がかかる。DropOldestなど他のFullModeも選べる。 / 確度: 条件付きの関係 / 確認日: 2026-08-22 出典
- BlockingCollection<T>はbackpressureの実装を担います。容量を指定したBlockingCollectionは、容量制限によって生産側が消費側を追い越しすぎるのを防ぐ。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
- スレッドセーフなコレクション型をbackpressureに用いることは推奨されません。ConcurrentQueueとConcurrentStackはロックを使わずInterlocked操作で実装された高速なコレクションだが、容量制限も「空になったら待つ」仕組みも持たない素のスレッドセーフキューである。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
- ExecutorServiceはbackpressureを前提とします。固定プールはスレッド数を制限するが待ち行列は無制限なので、投入が処理を上回り続ける常駐サービスではキューに積まれたタスクがメモリを食い続ける。容量付きキューと拒否ポリシー、または投入側の入場制限で背圧をかける。 / 確度: 条件付きの関係 / 確認日: 2026-08-02 出典
- BlockingQueueはbackpressureの実装を担います。容量を指定したArrayBlockingQueueなら、満杯時にputがブロックして自然な背圧になる。プロデューサー/コンシューマーの境界を明確にするこの設計は仮想スレッド時代でも有効である。 / 確度: 確立した関係 / 確認日: 2026-08-02 出典
この概念を扱う記事
一次資料
このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。