ここで決定的な答えを探しています。
ドキュメントによると、 JavascriptSerializer の public static メソッドはスレッドセーフですが、非静的メソッドはそうではありません。
このクラスの非静的パブリック メソッドについて、異なるスレッドを実行するさまざまなインスタンスがスレッド セーフであることが保証されていますか (つまり、スレッド セーフに違反する可能性のあるプライベートな静的リソースがないこと)。特に私が興味を持っているのは、JavascriptSerializer と JavascriptDeserializer でシリアル化および逆シリアル化するためのメソッドですが、一般的な答えを知りたいです。
つまり、スレッド A がインスタンス A でのみ実行され、スレッド B がインスタンス B でのみ実行される場合、そのシナリオでパブリック非静的メソッドのスレッド セーフの決定的な保証はありますか?
質問を要約するJavaScriptSerializerと、特定のインスタンスと対話する最大 1 つのスレッドを使用して、個別のインスタンスを異なるスレッドで使用できますか?
ここで決定的な答えを探しています。
私はあなたにそれを与えることはできません。ただし、(おそらくご存じのとおり) ドキュメント内のスレッド セーフ メッセージは非常に一般的であり、ほとんどどこにでも表示されます (同時実行が管理される型は例外です)。
逸話: スレッドセーフではない共有内部状態を格納する型を私は知りません。Lista の 2 つの異なるインスタンスを使用できるかどうか、またはXmlDocument2 つの異なるスレッドで使用できるかどうかを尋ねるのと同じです。できなければ、フレームワークはまったく役に立たないでしょう。
JavaScriptSerializerWeb サーバーが行うように、複数のスレッドで複数回インスタンス化することを意図しています (ASP.Net のスレッド化は非常に複雑ですが、型の複数のインスタンスが確実に作成され、異なるスレッドで呼び出されます)。MVC フレームワークはJavaScriptSerializer内部で使用されるため、チームがマルチスレッド Web 環境で使用することを意図していることは明らかです。
逆コンパイルされたソースのクイック ビューでは、共有された内部状態は示されません。@usr が指摘しているように、内部実装の一貫性は保証されません。ただし、前述の理由により、これが変更される可能性は非常に低いと思われます。
とは言っても、JSON.net ライブラリは、そのパフォーマンスと柔軟性から、JSON (デ) シリアル化の優れた代替手段と見なされることがよくあります。
型に static private unsafe が含まれている場合
それは時を刻む爆弾のような状態です。そんなことをする人はいないと思います。
ドキュメントだけがそれを保証できるため、スレッドセーフは保証されません。しかし、そうではありません。
スレッド セーフをテストすることはできません。スレッド化エラーは、負荷がかかっている場合、または本番環境でのみ発生する場合があります。
また、実装はいつでも変更できます。Windows Update、Service Pack、または新しいバージョンをインストールすると、コードが壊れます。
私に関する限り、これは決定的な答えです。信頼することはできません。また、少量のデータであっても定期的に新しいインスタンスを作成することが問題になる理由がわかりません。逆シリアル化は、単一のオブジェクトをインスタンス化するよりもはるかに CPU を集中的に使用します。(小さい) オブジェクトの作成は非常に安価です。