4

オブジェクトをシリアライズするアプリケーションの一部として XStream を使用しています。ユース ケースの 1 つとして、Externalizable インターフェイスを実装するいくつかのオブジェクトをシリアル化する必要があります。私のユースケースでは、ネイティブ Java シリアライゼーションを使用してそれらをシリアライズしたいと考えています。

インターネットでhttp://old.nabble.com/How-to-remove-Externalizable-Converter-td22747484.htmlというリンクを見つけました。これは、この問題に対処するのに役立ち、Reflection Converter for Externalizable オブジェクトの使用を開始するのに役立ちました。

アプリケーションをテストすると、高度な同時アクセス時にアプリケーションがコンバーター コードに多くの時間 (数十秒) を費やしていることがわかります。FieldDictionary のbuildMapメソッドに問題があることがわかります。

元の問題に対処するためのより良い方法があるかどうか疑問に思っていましたか? 同時実行環境が高い場合、Reflection Converter のパフォーマンスは低下すると予想されますか?

環境に関する追加のコンテキストを提供するため。これは Web アプリケーションであり、要求処理中にシリアル化が行われ、アプリケーションは数百の同時スレッドを持つことができます。

これに関するヘルプやアドバイスをいただければ幸いです。

4

1 に答える 1

0

これは技術的には答えではありません..しかし、とにかく役立つことを願っています.

生体分子研究モデリングに使用される Java Swing ベースのデスクトップ アプリを作成する際、パフォーマンス上の理由から、非常に複雑で相互接続されたオブジェクト グラフをディスクにシリアル化していました。

Java シリアライゼーションはオブジェクトの構造や名前などに非常に敏感であるため、Externalization および Serializable 関連の問題に取り組んだ後でも、アプローチ全体を放棄して新たに始める必要がありました。 、ユーザーが古いシリアル化されたモデルを読み込もうとしたとき。

最終的に、データ ストアに適したオブジェクト構造 (グラフ内の他のノードへの強力な相互参照なし) を作成し、この構造をシリアル化しました。これは、元のグラフをシリアライズおよびデシリアライズするよりもはるかに単純で、エラーが発生しにくく、はるかに高速でした。これは、アダプタ (ドメイン オブジェクトをデータストア オブジェクトに変換するコンポーネント) が適切に更新されている限り、ドメイン グラフ オブジェクトを自由にリファクタリング/変更できることも意味していました。

于 2013-04-19T11:12:53.870 に答える