Java 8 Streamインスタンスは常にclose（） 'dすべきですか？

quothがJavadocを：

ストリームにはBaseStream.close（）メソッドがあり、AutoCloseableを実装していますが、ほとんどすべてのストリームインスタンスを実際に使用後に閉じる必要はありません。通常、ソースがIOチャネル（Files.lines（Path、Charset）によって返されるものなど）であるストリームのみを閉じる必要があります。ほとんどのストリームは、特別なリソース管理を必要としないコレクション、配列、または生成関数によって支援されます。（ストリームを閉じる必要がある場合、try-with-resourcesステートメントでリソースとして宣言できます。）

「ほぼすべて」と「一般に」はあいまいです-ライブラリを作成していて、そのストリームのユーザーからストリームのソースを抽象化している場合は、とにかく自分に質問する必要があります-「閉じる必要がありますこの？" 端末操作はを呼び出さないため、IOがサポートするストリームを閉じる必要がありますclose。そのため、事実上、ストリームの送信元を常に覚えておくか、常にストリームする必要がありますclose。

核となる選択肢は、メソッドからストリームを返さないか、ストリームパラメーターを受け入れないことです。これは、JDKチームの一部の人々によって反響されてきた感情です。Streamsの実用的な有用性を考えると、過度に制限されていることがわかります。

Streamsを閉じる際のベストプラクティスは何ですか？よく似たコミュニティの質問に通常積極的に参加しているJDKの人々から、これに対する答えをオンラインで探しましたが、関連するものは見つかりませんでした。

先ほど述べたように、Javaでは、誰がどのリソースを解放する責任があるかを正確に知る必要があるため、適切なtry-catch-constructs、try-with-resourcesを入力するか、何らかの方法でそのタスクを委任できます。

GCに依存してクリーンアップできる唯一のものは、100％純粋なメモリです。他のリソースが混在している可能性がある
場合、合理的にできるのは、単に安全にプレイすることだけです。

「ベストプラクティス」に関する限り、「リソースストリーム」を返すメソッドには命名規則を使用することをお勧めします。

ストリームをclose()編集する必要がある場合は、ファクトリメソッドopen()またはを呼び出しますopenStream()。stream()SDKによって確立された規則に従って、一時ストリームを構築するメソッドを呼び出します。メソッドにjavadocを常に配置して、クライアントに必要close()であることを警告します。

public interface StreamingServer<RECORD> {
    /** 
     * Return a memory-efficient record stream from {@code source}.
     * Clients <em>must</em> call {@link Stream#close} to dispose the
     * stream.
     */
    Stream<RECORD> openStream(URI source) throws IOException;
}

SDKの作成者がAutoCloseable基本ストリームクラスを使用することを選択していなかったことを願っています。ResourceStream簡単に実装する別個のサブタイプAutoCloseableは、異なるコントラクトを明らかにします。次に、それをStream必要としないを閉じることができずResourceStream、静的分析ツールで潜在的に誤った管理を検出することができます。

コードベースのニーズ（およびコードレビューで規則を実施する能力）に応じて、必要なストリームサブクラスを自分で確立できます。または、独自の静的分析ツール、管理対象リソースを直接マークするメソッドアノテーションを作成する場合。

@RequiresClose
Stream<RECORD> openStream(URI source) throws IOException { ... }