1

Web 呼び出しをサポートするカスタム フォーマッタを使用していますが、バグ レポートで問題が明らかになりました。私はそのようにメソッドをオーバーライドしていましたWriteToStreamAsync():

public override Task WriteToStreamAsync(Type type,
                                        object value,
                                        Stream writeStream,
                                        HttpContent content,
                                        TransportContext transportContext)
{
    return Task.Run(() =>
        {
            if (value == null) return;
            using (var sw = new StreamWriter(writeStream))
            {
                var serialized = _serializer.Serialize(value);
                sw.Write(serialized);
            }
        });
}

この投稿によると、問題は、usingステートメントがストリームを閉じる原因となっていたことでした。using解決策は、ステートメントを削除して明示的なFlush()呼び出しを使用することでしたが、GC に依存してStreamWriter.

public override Task WriteToStreamAsync(Type type,
                                        object value,
                                        Stream writeStream,
                                        HttpContent content,
                                        TransportContext transportContext)
{
    return Task.Run(() =>
        {
            if (value == null) return;
            var sw = new StreamWriter(writeStream);
            var serialized = _serializer.Serialize(value);
            sw.Write(serialized);
            sw.Flush();
        });
}
  1. これは大きな懸念事項ですか？
  2. これを行うためのより良い（より多くの「ベストプラクティス」）方法はありますか？
4

1 に答える 1

1

これは大きな懸念事項ですか？

いいえ、Streamリーダーが生き残り、ストリームを破棄する責任があるのが明らかな場合。

.NET Framework でも一般的です。たとえば、Iconが から作成された場合、作成されたインスタンスによって使用されるため、破棄Streamしないでください (usingアイコンを作成するときに構造を使用しないでください)。

これを行うためのより良い（より多くの「ベストプラクティス」）方法はありますか？

  • Streamと の両方をStreamWriter同じスコープで作成すると、ストーリーが明確になり、それらを破棄できます。
  • 既に存在する を取得した場合、Streamその を処分できるかどうか確信が持てませんStream。ドキュメントで明確でない限り、閉じないでください。
于 2015-09-28T14:30:12.820 に答える