コンテンツにスキップ

【比較】キャッシュとバッファの違い

概要

「キャッシュ（cache）」は、一度取得・計算した結果をコピーして手元に置いておき、次回以降の同じアクセスを速くするための仕組みです。再利用が前提で、要求されたデータが手元にあれば「ヒット」、なければ「ミス」となり遅い元データへ取りに行きます。容量に限りがあるため、いっぱいになると追い出し（eviction）が起きます。一方「バッファ（buffer）」は、データをある場所から別の場所へ移す間、一時的に溜めておくための領域です。送り手と受け手の速度差や処理タイミングの差を吸収するのが目的で、再利用は本質ではありません。

両者が混同される最大の理由は、どちらも「データを一時的にメモリに置く」点が表面的に似ているうえ、Linux の free コマンドが両者をまとめて buff/cache と表示するなど実装上隣接して使われるためです。しかし目的が決定的に異なります。キャッシュは「同じデータを二度取りに行かない（再利用で速くする）」ため、バッファは「速度・タイミングの不一致をならす（橋渡しする）」ためにあります。Wikipedia も「キャッシュはほぼ常に何らかのバッファリングを伴うが、純粋なバッファリングは必ずしもキャッシュを伴わない」と整理しています。

例えるなら：よく使う調味料の小瓶 vs 蛇口の下のバケツ

キャッシュは「料理人がよく使う調味料を手元の小瓶に取り分けておく」イメージです。毎回奥の倉庫（遅い元データ）まで取りに行かず、手元にあれば即使える（ヒット）。なければ倉庫に取りに行き（ミス）、小瓶が満杯なら使っていない調味料を戻して入れ替えます（追い出し）。同じものを何度も使うほど得をします。一方バッファは「水道の蛇口の下に置いたバケツ」です。蛇口（生産者）が出す速度とコップ（消費者）が汲む速度が違っても、バケツが差を吸収してあふれ・空きを防ぎます。同じ水をもう一度使うためではなく、流れの速度差をならすためにあります。比喩は目的の違いを掴むのに有効ですが、実システムではキャッシュがバッファを内包するなど両者が重なる構成もある点に注意してください。

詳細比較

項目 キャッシュ (Cache) バッファ (Buffer)
主目的 再利用による高速化（同じデータの再取得・再計算を避ける） 速度差・タイミング差の吸収（生産者と消費者の橋渡し）
前提となる性質 局所性（時間的・空間的）。同じ／近いデータが繰り返し使われること 生産レートと消費レートの不一致、またはレートが可変であること
データの由来 どこか別の場所にあるデータのコピー、または以前の計算結果 これから別の場所へ移送する途中のデータ（その場限り）
中心概念・指標 ヒット／ミス、ヒット率、追い出し方針（LRU 等）、無効化・整合性 容量とフロー制御、オーバーフロー／アンダーフロー、フラッシュ
満杯時の挙動 既存エントリを方針に従って追い出して空ける（性能が落ちるだけで処理は継続） これ以上溜められない＝生産側をブロック／待たせる、または溢れて損失
典型例 CPU L1/L2 キャッシュ、ブラウザキャッシュ、DNS キャッシュ、メモ化、Linux ページキャッシュ I/O バッファ、ネットワークソケットの送受信バッファ、動画の再生バッファ、stdio バッファ
取り除いたときの影響 正しさは保たれ、遅くなるだけ（透過的に再取得できる） 速度差を吸収できず、データ損失・取りこぼし・スループット低下を招き得る
再利用するか する（同じデータが再び要求される前提） しない（移送が済めば用済み。同じ内容を再要求する前提はない）

Linux のページキャッシュは「ファイル読み込み時にデータをページキャッシュへ置き、以降の読み込みで高価なディスクアクセスを避ける」とカーネル公式ドキュメントが説明しており、これは再利用による高速化＝キャッシュの典型です。一方、ソケットの送受信バッファや stdio のバッファは、アプリの書き込み速度とデバイス／ネットワークの処理速度の差を吸収するもので、再利用ではなく橋渡しが目的です。free コマンドが両者を buff/cache とまとめるのは実装上の近接ゆえで、概念の同一性を意味しません。

よくある誤解

  • 「キャッシュとバッファは同じもの（どちらも一時メモリ置き場）」は誤り。 表面の「一時的にメモリに置く」は共通ですが目的が違います。キャッシュは同じデータの再取得を避けて速くする再利用の仕組み、バッファは速度・タイミングの差を吸収する橋渡しの仕組みです。Wikipedia も「キャッシュはほぼ常にバッファリングを伴うが、純粋なバッファリングはキャッシュを伴うとは限らない」と、包含はしても同一ではないと明示しています。

  • 「キャッシュを消すとデータが壊れる／失われる」は誤り。 キャッシュは元データのコピーなので、捨てても元データから再取得でき正しさは保たれます（遅くなるだけ）。だから OS はメモリが必要になればページキャッシュを即座に解放できます。一方、書き込み待ちのデータを保持しているバッファをフラッシュ前に失うと、それは本当にデータ損失になり得ます。両者の「失われたときの重大度」は対照的です。

  • 「Linux で free の buff/cache が大きい＝メモリ不足／メモリリーク」は誤り。 ページキャッシュは性能のために空きメモリを活用しているだけで、アプリがメモリを要求すれば即座に回収されます。free の available 列こそが実際に使える量であり、buff/cache が大きいのはむしろメモリを有効活用している健全な状態です。

  • 「ライトバッファとライトバックキャッシュは同じ」は不正確。 どちらも書き込みを溜めて遅延させますが、目的が違います。ライトバッファは遅いデバイスとの速度差を吸収して書き手を待たせないため、ライトバックキャッシュは同じ場所への再書き込み・再読み出しを高速化するため（再利用が前提）です。実装が似て見えても、再利用を狙うかどうかが本質的な区別です。

実務での選び分け

  • 同じデータ／計算結果が繰り返し要求され、それを速くしたい → キャッシュ。ヒット率、追い出し方針（LRU/LFU 等）、無効化（TTL・イベント駆動）と整合性設計が肝。
  • 生産側と消費側の速度・タイミングが食い違い、取りこぼしや待ちを防ぎたい → バッファ。容量設計、フロー制御（バックプレッシャ）、オーバーフロー時の方針（ブロック／ドロップ）が肝。
  • 両方の性質が必要（例: ストリーミング再生） → 再生バッファでネットワークのゆらぎを吸収しつつ、デコード済みフレームやセグメントをキャッシュして再シーク／再描画を速くする、と役割を分けて設計する。
  • キャッシュ設計で最初に決めること → 何をキー化するか、いつ無効化するか（古いデータを返さないか）、ミス時のコスト。整合性を軽視すると「速いが間違ったデータ」を返す。
  • バッファ設計で最初に決めること → 想定レート差とバースト、満杯時にブロックするか捨てるか、レイテンシ予算（バッファを大きくすると遅延も増える）。

ひとことまとめ

キャッシュは「同じデータの再取得・再計算を避けて速くする再利用の仕組み（ヒット／ミス／追い出し）」、バッファは「生産者と消費者の速度・タイミング差を吸収する橋渡しの仕組み（容量／フロー制御）」であり、目的（再利用で速くするか、不一致をならすか）が両者を分けます。

出典・参考