MicroStreamの直列化を具体的にどのように動作するか私は思っていました。それは「超高速」と記載されているので、それは右、コード生成に依存していますか？それとも、反射に基づいていますか？
それはどのように直接Javaのフィールドの読み出しとのByteBufferに書き込むと、その逆のコード生成に依存しているProtobuf-シリアライズ、と比較して実行します。
それは、巨大なスケールでオブジェクトをシリアライズするとき大幅にパフォーマンスが低下する反射を使用していないでしょうか？
私は、送信するために高速な方法を探しているとマルチプレイゲームとミリ秒ごとのカウントのためにオブジェクトを永続化しています。:)
前もって感謝します！
PS：私は十分な評判を持っていないので、私は「microstream」 -タグを作成することはできません。https://microstream.one/
私はMicroStreamのリード開発者です。（これは別名アカウントではありません。私は実際にそれを作成した。私は10年かそこらのためにStackOverflowの上で読んだが、アカウントを作成する理由がなかったんだ。今までは。）
すべての初期化時に、MicroStreamは彼らからメタデータを最適化し、必要なすべてのエンティティと値型クラスと派生の現在のランタイムのバージョンを分析します。これまで不明であった、実行時にクラスに遭遇したときも同じことが行われています。分析は、反射ごとに行われますが、それは唯一のすべての扱わクラスに一度行われるので、反射性能コストはごくわずかです。実際の格納およびロードまたはシリアライゼーションおよびデシリアライゼーションは、作成されたメタデータに基づいて最適化されたフレームワークコードを介して行われます。
クラスのレイアウトが変更された場合、型分析はクラスのインスタンスが現在のクラスのものに格納されているフィールドレイアウトからマッピングを作成します。自動的可能であれば（明白な変更またはいくつかの設定ヒューリスティックを介して）、そうでなければユーザ提供マッピングを介し。それは位置＃3や位置＃5までにコピーし、ロードされた値＃3（スピーキングを簡素化）場合、JVMは気にしませんので、同じ性能のまま。これは、すべてのメタデータ内にあります。
たByteBufferは、より正確には、直接的たByteBufferを使用しますが、されているのみで、直接「安全でない」低レベルの操作を経由しての作業にオフヒープメモリのためのアンカーとして。あなたは、「安全でない」の操作に慣れていない場合は、短くてシンプルな概念がある：「これは、高速C ++コードとして直接としてのです。」。あなたは非常に速くしたいとメモリに近い何かを行うことができます、あなたはまた、すべてを担当しています。詳細については、「sun.misc.Unsafe」をグーグル。
いいえコードが生成されません。いいえバイトコードハッキング、プロキシまたは類似モンキービジネスによってインスタンスの暗黙の交換は使用されません。技術的なレベルで、それは（「安全でない」の使用を含む）だけでJavaライブラリですが、適切に考案されたロジックの多くの。
サイドノートとして：一般的であると考えられているような反射が遅いようではありません。もう違います。それはでしたが、それはいくつかの過去のバージョンのJavaにはかなり最適化されています（複数可？）。それは、すべての操作が関係している場合にのみ遅いのすべてのクラスの分析、フィールドのルックアップなど新たに（フレームワークの非常に多くが、彼らはひどく書かれているので、やるように思われます）。フィールドが収集された（など、アクセスを設定する）一度、その後、キャッシュされている場合は、反射が驚くほど速く、実際にあります。
いるProtobuf-シリアライズとの比較について：
私はプロトコルバッファを使用していないと私はそれが内部でどのように動作するか分からないので、私はそれについて何も具体的なことを言うことはできません。異なる技術が異なる最適化の優先順位と制限がありますので、複雑な技術といつものように、本当に意味のある比較を行うのはかなり難しいかもしれません。
ほとんどのシリアライズは、参照整合性をあきらめるだけ「データ」を保存するアプローチ（2つのオブジェクトが三分の一を参照する場合、直列化復元は、その第三の目的の2つのインスタンスを作成します。つまり枚この：A-> C <-B ==シリアライズ==> A- > C1 B-> C2。この基本的に休憩/遺跡例えば、/オブジェクトグラフを破棄し、それが作成され、際限なく複製をカスケード接続するので、不可能巡回グラフの直列化を行います。参照JSONのシリアライズ。おかしいもの。）Aのためであってもブライアン・ゲッツ」ドラフトJavaの「シリアライズ2.0」は、その制限（AT「制限」を参照含むhttp://cr.openjdk.java.net/~briangoetz/amber/serialization.html）（及び関心事の分離を壊す別のもの）。
MicroStreamはその制限はありません。それは彼らの参照を台無しにすることなく、適切に、任意のオブジェクトグラフを扱います。彼は書いて無傷で参照整合性を保つことは、これまで「あまりやろう」ではないことです。これは、「適切にそれをやって」されます。一つは、ちょうどそれを正しく行う方法を知っていなければなりません。正しく行われれば、それはさえかなり簡単です。だから、いるProtobuf-シリアル化（「悪魔との協定」）がどのように多くの制限によっては、それは一般的にほとんど、あるいはないMicroStreamへのすべての同等のでもないかもしれません。
もちろん、あなたは常にあなたの特定の要件のために、いくつかの性能比較テストを作成し、その技術のスーツあなたのベストを見ることができます。ちょうどあなたが制限に注意されていることを確認し、あなたの特定の技術課し（台無し参照一貫性、禁断の種類、必要な注釈、必要なデフォルトコンストラクタ/ゲッター/セッターなど）。MicroStreamはなし*を持っています。
（*）理由の中：シリアライズ/保存システム内部（例えばスレッド）または（ラムダまたはプロキシインスタンスのような）非実体があり、技術的に可能ではあるが、意図的に除外しました。