問題タブ [binary-serialization]

シリアル化先を知らなくても、シリアル化されたオブジェクトのメタデータとプロパティ情報を表示する方法はありますか?

一連のバイナリ シリアル化オブジェクトがあり、データ マイニングが必要ですが、元のクラスにアクセスできません。これで、ダミー クラスを定義してデータを設定することが可能になりましたが、逆シリアル化されたオブジェクトに保持されている情報がわからないと、プロパティのいずれかが欠落しているかどうかを検証する方法がありません。

逆シリアル化するときに、シリアル化されたストリームの次の「エントリ」をスキップする可能性はありますか? プラグイン指向のアーキテクチャに関しては、シリアル化されたオブジェクト グラフの個別の部分が、別の環境では不明なタイプになる可能性があります (無視しても問題ないと仮定してください)。もちろん、これらをデシリアライズしようとすると失敗します。

これをバイナリフォーマッタで動作させるにはどうすればよいですか? 長さを計算し、シリアル化されたエントリの明確な型名 (文字列など) を取得し、エントリ自体の直前に格納する必要がありますか? (ストリーム ポインタをインクリメントすることによって) 逆シリアル化するときにスキップできますか? または、シリアル化された表現の問題固有の操作が少ない、より良い代替手段はありますか?

HashMap<String,Double>を使用する代わりに、エントリを反復してそれぞれをシリアル化することにより、 a をシリアル化するコードをいくつか書きましObjectOutputStream.readObject()た。その理由は単に効率です。結果として得られるファイルははるかに小さく、書き込みと読み取りがはるかに高速です (たとえば、0.6 秒で 23 MB、9.9 秒で 29 MB)。

これは私がシリアル化するためにしたことです：

ご覧のとおりbyte、各 key の配列を取得し、Stringその長さをシリアル化し、次に配列自体をシリアル化します。これは私がデシリアライズするためにしたことです：

問題は、ある時点でキーが正しくシリアル化されないことです。本来の 16 バイトではなく 8 バイトを読み取ることができるようになるまでデバッグを行ったois.read(bytes)ため、キーStringが適切に形成されてdoubleおらず、まだ読み取られていないキーの最後の 8 バイトを使用して値が読み取られました。 . 結局、例外はどこにでもあります。

以下のサンプル データを使用すると、出力はある時点で次のようになります。

この問題は、シリアル化されたファイルで確認できます (次のように表示されます2010-00-008.html)。

キーの間に 2 バイトが追加されStringます。詳細については、 MxyL の回答を参照してください。要するに、なぜこれらの 2 バイトが追加され、なぜ正常にreadFully動作するのかということです。

String適切に (デ) シリアライズされないのはなぜですか? 固定ブロックサイズへのある種のパディングか、そのようなものでしょうか? 効率を求めるときに手動でシリアル化するより良い方法はありますか? Stringある種のwriteStringandを期待していreadStringましたが、Java の にはそのようなものはないようですObjectStream。

何か問題が発生した場合に備えて、バッファリングされたストリームを使用してみました。さまざまなエンコーディングを使用して、書き込みと読み取りのバイト数を明示的に示していますが、うまくいきません。

これは、問題を再現するためのサンプル データです。

複数のプロセスでファイルをシリアライズしているときに、パフォーマンスの問題に直面しています。

問題は次のとおりです。計算を実行するために（分散コンピューティング環境で）複数のプロセスを作成し、各プロセスの出力をファイルに書き留めています。メインプロセスはこれらのファイルを使用し、メモリにマージしてさらに計算を行います。

サーバー数を制限しています。何が起こるかというと、同じサーバーに 2 ～ 3 つのプロセスを作成できます。これが発生した場合 (同じサーバーで 2 ～ 3 つのプロセスが作成された場合)、これらのプロセスが計算されたファイル (ファイル サイズは約 80 ～ 90 MB) をディスクに同時に書き込み\シリアル化しようとするシナリオが発生します。これが発生すると、ファイルをシリアル化するのに約 3m かかります。通常、その 80 ～ 90 MB には 30 秒しかかかりません。

このシナリオをパフォーマンス モニター (およびログのタイミング) で監視したところ、2 ～ 3 のプロセスが同時に書き込みを試みているため、通常のタイミングよりも約 6 倍長くかかることがわかりました。

（3分のシナリオの）タイミングを改善するための提案は大歓迎です。

.Net フレームワークを使用し、コードは c# で記述されています。

MSMQ メッセージを取得する WCF Windows サービスがあります。SubmitPurchaseOrderInMessage が呼び出されないようで、キューにメッセージが表示されません。コードを以下に示します。

WCF クラス:

インターフェイス コントラクト:

配列 Parameters は、クライアントが渡すことができる任意の動的なシリアル化可能な型にすることができます。問題はこのパラメータにあると思います。このパラメーターとシリアライズ可能な属性、およびクライアントの binding.SerializationFormat を削除すると、すべてが正常に機能します。

シリアライズ可能なクラス:

クライアント ：

円を描くベースクラスを継承する派生クラスがあります

バイナリシリアル化を使用してこのクラスをシリアル化しようとしています。

私はそれを次のようにシリアライズしています：

シリアル化は問題ないようですが、シリアル化を解除すると、次のようになります。データ フィールド (brace、radius、および centerPoint) が正常に返されました。しかし、私は円を取り戻していません！基本クラスをデシリアライズしていないためだと思います。やってみても、やり方がわからない！

私の質問は、これをどのように逆シリアル化できるかです。このようなものを探していますが、これは可能ですか？