ストリームとキューの違いは何ですか？

ストリームとキューの違いは何ですか？どちらも要素の順序付けされたセットの概念を持っていますが、「挿入」/「抽出」（ストリーム）と「エンキュー」/「デキュー」（キュー）の実装やボキャブラリが異なる傾向があります。これらは交換可能ですか？彼らは異なる概念やパターンを提案していますか？もしそうなら、違いは何ですか？

ストリームは、実際に（概念的には）のようなデータ構造ではなく、デジタル符号化されたコヒーレント信号を送信するために使用される、または」情報を受信する（データまたはデータパケットのパケット）のシーケンスである。したがって、基本的にデータの配列。

キューは、キューの後ろに項目を追加したり、正面から取ることができるように、単純なFIFOメカニズムです。

ストリームは常にソース（ファイル、ネットワークの場所など）を持っています。キューには本質的にデータが含まれていません。

したがって、基本的にはそれらの概念はまったく異なり、メイソンが指摘したように、それらの使用方法は異なります。

基本的な違いは、それらの使用方法にあります。ストリームでは、通常、操作の片側のみを使用します。ストリームを開いて読み取りまたは書き込みを行いますが、両方は行いません。待ち行列では、アイテムを出し入れします。

また、キューは、物を置いたり取り出したりする順序について非常に厳格ですが、ストリームSeekからの読み取りの場合は特に、ストリームが操作をサポートすることがよくあります（常にではない）。

私の経験では、ストリームは、ストリーム内のデータによって決定されることが多いレートで生成/消費される一連のバイトです。たとえば、MPEGデータストリームには、次のバイトシーケンスの機能と消費する必要があるバイト数を説明するフレームヘッダーがあります。ドキュメントのバイナリシリアル化も同様です。これは常に自己記述的ではありません。STDOUTへの書き込みはストリームごとに行うことができますが、人間が読み取れる/解析できないデータの場合があります。

逆に、キューは通常、全体が消費される既知のタイプのオブジェクト（またはインターフェースをサポートするオブジェクト）です。例としては、いくつかのデータベースワーカーによって処理されるデータベースジョブのキューがあります。

ストリームとキューの違いは、データレートの制御方法です。

• キューでは、送信者はリーダーの速度に適応します。送信者は、キューがいっぱいになった場合の対処方法を決定します。キューが使用可能になるまで待つか、データを破棄します。

• ストリームでは、リーダーは送信者の速度に適応します。リーダーは、古いデータが消費される前に新しいデータが到着した場合の対処法を決定します。

その観点では、Unixパイプなどの文字ストリームは、ストリームとしてではなくキューとしての資格があります。

単語の一般的な使用方法について視覚的に考えると、特定の言語や実装による特定の使用の混乱を回避できるため、これらの用語は実際に何かを意味する可能性があります。

• 人の列が並んで待っていて、一人ずつ出されます。より多くの人々が最後尾で列に加わります。サービスが進むにつれて誰もが待機し、サービス時間は変動することが予想されます。合計で何人が奉仕されているかを話すことができます。
• たとえば、ドアから建物を出る人々の流れは、一人ずつではなく、ほぼ一定の速度で出口を通過するだけです。遅延は予想されず、十分に許容されません。あなたは人々の割合を話すことができます：1秒あたり1つ。

それがこれらの用語の意図です。それらは比喩です。（他のすべてのように）（シッ！あなたは物語を台無しにするでしょう！）

キューは、ストリームよりも上位の概念です。キューの基本要素はメッセージ/オブジェクトです。これは、コンシューマが独自に解釈できる一貫した（通常は型指定された）データ構造です。一方、ストリームのベースには（通常は固定サイズ）のビット/バイト/文字があり、それ自体では通常、アプリケーションには意味がありません。これらの文字のシーケンスは「メッセージ」を構成する場合がありますが、ストリームAPIはそれをアプリケーションに任せて、文字のシーケンスを適切なチャンクに分割します。

ストリームバッファーがいっぱいで、反対側が読み取り/書き込みを行っていない場合、通常、Stream APIは部分的な読み取りと書き込みも許可します。キューを処理するアプリケーションは通常、キューがこれらを内部的に処理することを期待しています。

キューはストリームの上に実装できます。これはメッセージフレーミングを実装することによって行われます。たとえば、TCPはストリームインターフェイスを提供し、HTTPはTCPの上に構築され、Content-Length /チャンク転送エンコーディングを使用してメッセージフレーミングを追加します。HTTP接続APIのユーザーは、HTTP接続ストリームをHTTPリクエストに分割する処理から抽象化されています。

一方、メッセージフレーミングの処理により不要なオーバーヘッドが追加されるため、通常、キューの上にストリームAPIを実装することはあまり意味がありません。

関数型プログラミング言語（Scalaなど）、およびおそらく他の言語でも、ストリームは実際には関数型リストに似ており、キューです。ただし、キューは実際にはリストのペアを使用して実装できます。Scalaおよびおそらく他の場所では、ストリームは単なる遅延リストですlazy val。より具体的には、リストの末尾はです。

関数ストリームは、リストとは対照的に、キューといくつかの類似点を共有できます。これは、ストリームの先頭への参照を保持しない方法でそれらを使用できるためです。ただし、注意する必要があります。https：// stackoverflow.com/a/5159356/3096687。これは、キューへのデキュー呼び出しに多少似ています（ストリームの場合、暗黙的に行います：http : //daily-scala.blogspot.com/2010/01/streams-2-stream-construction.html）。

ストリームは、シリアルまたはパラレルまたはバルクでデータの無限シーケンスを生成および消費するための概念/フレームワークです。Queは、ストリームを実装できるデータ構造です。ストリームを実装できるlistまたはseqと同じです。