Javaでのシリアル化：ブラックボックス内の見方

太古の昔から、Javaには素晴らしいシリアル化メカニズムがあり、特別な精神的な労力をかけることなく、任意の複雑なオブジェクトグラフを一連のバイトとして保存できます。 ストレージ形式は十分に文書化されており、多くの例があり、シリアル化されたオブジェクトはかなり「重く」、一度にネットワーク経由で送信され、カスタマイズの多くの可能性があります...これはすべて素晴らしいと思われますが、あなたが顔を合わせていない限り非常に価値があり、現在必要なデータを含むマルチメガバイトのバイナリファイル。

素手でこのファイルにアクセスして、ソースコードなしでオブジェクトのこの巨大なシリアル化されたグラフの内部に保存されているものを理解する方法は？ Serialysisは、これらの質問や他の多くの質問に答えることができます-シリアル化されたJavaオブジェクトを詳細に分析できるライブラリ（ シリアル化された形式は、式のシリアル形式を翻訳する私のバージョンです。 そのため、オブジェクトに関する情報を取得できますが、その情報はパブリックAPIからは入手できません。 このライブラリは、独自のクラスのシリアル化をテストするときにも便利なツールです。


翻訳者から：
土曜日 夕方。 この日の仕事を予感させるものは何もありませんでしたが、突然、私は自分の仕事がhadoopクラスターでどのようになっているかを確認して、良心を落ち着かせるのはいいことだと思います-問題は解決されました...

<歌詞の余談>
過去数日間で、本番環境のhadoopクラスターでOutOfMemoryErrorを使用してかなりの数のタスクが完了し始め、割り当てられたメモリの量を増やす機会がなくなったため、IT部門は理由を探そうとしてかなりの時間を費やしました。 私たちのアメリカ人の同僚が思慮深く設定を見て、いくつかの行を修正し、問題が解決したと言ったという事実で終わりました。
実際、金曜日にはすべてがうまくいきました。また、 Cloudera認定デベロッパーがチームに加わったことを嬉しく思います。
</叙情的な余談>

しかし、そこにありました！
Khadupは、この不幸な土曜日に1つのタスクが完了しなかったことを証言しました。
クラッシュの理由は以前のものとは多少異なります。タスクトラッカーは、タスク構成のxmlファイルをロードするのに十分なメモリがないため、タスクを開始できませんでした。

もちろん、私はすぐにどんな種類の巨大な構成がそこに保存されているのだろうと思いましたか？ 残念ながら、大部分は50メガバイトのシリアル化されたブロブで占められていました。 ブロブは、さまざまなクラスのオブジェクトのグラフで構成されています。もちろん、ソースはありません。

土曜日の夕方、即興のツールだけでこのマルチメガバイトバイナリを使って何ができるでしょうか？

私の救世主、シリアリシスが来ました。 数行のコード-そして、クラスとフィールドの名前とともに、シリアル化されたオブジェクトの内部の完全なダンプを手にしています。 手元に完全なダンプがあるので、問題を見つけ、文字列辞書のgzip圧縮をオンにし、 JBEを使用してクラスにパッチを適用します。 出来上がり-問題は解決しました！

もちろんこれはハックですが、時にはハックなしで-どこにもありません。

PSライブラリは長年使用されていますが、現時点では非常に役立つことが判明しました。 率直に言って、著者がライブラリ用に見つけたアプリケーションのいくつかは、私にとって非常に奇妙に思えます。 神のために、彼らは私たちに港を知らせなかったので、それは本当に必要ではありません！ 私の意見では、このテクノロジーの最適なアプリケーションは、あらゆる種類のデバッグとトラブルシューティングです。この分野では、本当に同等ではありません。

実際には、記事：

パブリックAPIで十分でない場合

Serialysisライブラリを作成する理由は、パブリックAPIを介して取得できなかったが、シリアル化された形式で利用できるオブジェクトに関する情報が必要なときに、いくつかの問題に遭遇したためです。

たとえば、リモートRMIオブジェクトのスタブがあり、どのアドレスまたはポートを介して接続するか、またはどのRMIソケットファクトリ（RMIClientSocketFactory）を使用するかを知りたいとします。 標準のRMI APIは、スタブから情報を抽出する方法を提供しません。 シリアル化解除後にスタブが機能するには、この情報がシリアル化された形式で存在する必要があります。 したがって、シリアル化されたスタブを何らかの方法でしか解析できない場合、必要な情報を取得できます。

2番目の例は、 JMX APIからのものです。 MBeanサーバーへのリクエストは、 QueryExpインターフェースで表されます。 QueryExpの例は、 Queryクラスメソッドを使用して構築されます。 オブジェクトがQueryExpに属している場合、それが実行するクエリをどのように知るのですか？ JMX APIには、見つける方法がありません。 情報は、クライアントがリモートサーバーに要求を行ったときにサーバーに復元できるように、シリアル化された形式で提示する必要があります。 シリアル化されたフォームを確認できれば、リクエストが何であったかを判断できます。

2番目の例は、このライブラリを作成するように促しました。 既存の標準JMXコネクタはJavaシリアル化に基づいているため、QueryExpsの特別な処理は必要ありません。 しかし、新しいWebサービスでは
JSR 262で導入されたコネクタは、シリアル化にXMLを使用します。 QueryExpを解析してからXMLに変換する方法は？ 答えは簡単です。WSコネクタは、このライブラリのバージョンを使用して、シリアル化されたQueryExpの内部を調べます。

これらの例にはすべて共通点が1つあります。それぞれのAPIにスペースが表示されています。 つまり、RMIスタブから情報を抽出するにはメソッドが必要です。 QueryExpを変換して、それを生成した元のQueryメソッドに戻す方法が必要なように。 （解析可能な標準のtoString（）出力でも十分です）。 しかし、現在そのようなメソッドはありません。現在の形式でこれらのAPIで動作するコードが必要な場合は、別のアプローチが必要です。

オブジェクトのプライベートフィールドに侵入します

興味のあるクラスのソースコードがある場合は、目的のデータを取得して取得するだけです。 RMIスタブを使用した例では、 getRef（）スタブメソッドがsun.rmi.server.UnicastRefを返すことが実験的にわかります。JDKソースを調べた結果、このクラスにはsun.rmi.transport.LiveRef型のrefフィールドが含まれていることがわかります。必要な情報で したがって、このコードのようなものが得られます（ただし、事前に言っておきますが、これを行うべきではありません）。

import sun.rmi.server.*; import sun.rmi.transport.*; import java.rmi.*; import java.rmi.server.*; public class StubDigger { public static getPort(RemoteStub stub) throws Exception { RemoteRef ref = stub.getRef(); UnicastRef uref = (UnicastRef) ref; Field refField = UnicastRef.class.getDeclaredField("ref"); refField.setAccessible(true); LiveRef lref = (LiveRef) refField.get(uref); return lref.getPort(); } } 

結果はおそらくあなたにぴったりでしょうが、繰り返しますが、そうすることはお勧めしません-このコードは良くありません。 まず、太陽への依存関係を使用しないでください*クラス。JDKの更新によって認識を超えて変更されないことを保証できないため、クラスは他のJDKプラットフォームに移植するのは容易ではありません。 次に、 Field.setAccessibleのようなものが表示されたら 、それを一時停止の標識として使用する必要があります。 つまり、コードは、リリースごとに変更される可能性のある文書化されていないフィールドに依存していることを意味します。

（このコードはJDK 5向けに作成されました。判明したように、JDK 6ではLiveRefはpublic getPort（）メソッドを取得したため、Field.setAccessibleは必要なくなりました。しかし、いずれにしてもsunに依存するべきではありません。

もちろん、より良い解決策が見つからない場合があります。 しかし、あなたが真剣に興味を持っていたクラスが直列化可能であることが判明した場合、成功する可能性は十分にあります。 実際、クラスの直列化された形式はその契約の一部です。 APIが完全に欠落していない場合、その外部コントラクトは以前のバージョンと互換性があります。 これは、特にJDKプラットフォームにとって非常に重要な条件です。

したがって、必要な情報がパブリッククラスメソッドを介してアクセスできないが、少なくとも文書化されたシリアル化された形式の一部である場合、シリアル化された形式で変更されないままであることが望まれます。

直列化された形式の説明は、実装される各クラスの「関連項目」セクションのJavadocに含まれています。 1つの大きなページで、すべてのパブリックJDKクラスのシリアル化された形式を見つけることができます。

こんにちはSerialysis！

シリアル化されたオブジェクトのメタデータを取得するための私のライブラリは、「シリアル分析」という言葉の組み合わせからSerialysisと呼ばれます。

これがどのように機能するかの簡単な例を挙げます。 このコード...

  SEntity sint = SerialScan.examine(new Integer(5)); System.out.println(sint); 

...これをもたらす...

 SObject(java.lang.Integer){ value = Prim(int){5} } 

これは、SerialScan.examineに渡したjava.lang.Integer型のオブジェクトは、int型の単一フィールドを内部に持つオブジェクトとしてシリアル化されることを示唆しています。 文書化された直列化された形式java.lang.Integerをチェックすると、これがまさに予想されたものであることがわかります 。

ソースコードjava.lang.Integerを見ると、クラス自体にもint型の単一の値フィールドがあることがわかります。

 /** * The value of the <code>Integer</code>. * * @serial */ private final int value; 

ただし、プライベートフィールドは実装の詳細です。 更新では、フィールドの名前を変更したり、新しいフィールドに置き換えたり、親クラスjava.lang.Numberなどから継承したりできます 。 そして、これが起こらないという保証はありませんが、直列化された形式が変更されないという保証があります。 シリアル化は、クラスのフィールドが変更された場合でも、シリアル化されたフォームを元のフォームに保存するメカニズムを提供します。

これはもっと複雑な例です。 何らかの理由で、 ArrayList内の配列の大きさを知りたいとします。 APIは必要な情報を提供しませんが、指定された配列以上の配列を強制的に割り当てることができます。

ArrayListのシリアル化された形式を見ると、探している情報が含まれていることがわかります。 これは、リスト内のアイテムの数であるシリアル化されたフィールドサイズを示しますが、それは必要なものではありません。 ただし、WriteObjectメソッドのバイナリデータには、必要なものだけが含まれています。

シリアルデータ：
内部ArrayListの長さ、およびその背後-すべての要素（それぞれオブジェクトとして）が指定された順序で含まれています。

このコードを実行すると...

 List<Integer> list = new ArrayList<Integer>(); list.add(5); SObject slist = (SObject) SerialScan.examine(list); System.out.println(slist); 

...その後、次の結論が得られます...

 SObject(java.util.ArrayList){ size = SPrim(int){1} -- data written by class's writeObject: SBlockData(blockdata){4 bytes of binary data} SObject(java.lang.Integer){ value = SPrim(int){5} } } 

ここでは、シリアル化の暗いジャングルにいます。 オブジェクトのフィールドをシリアル化することに加えて、またはその代わりに、クラスには、 ObjectOutputStream.writeInt型のメソッドを使用してストリームに任意のデータを書き込むwriteObject（ObjectOutputStream）メソッドを含めることができます。 クラスには、同じデータを読み取る対応するreadObjectメソッドも含める必要があり、 @ serialDataタグを使用して 、ArrayListで行ったように、WriteObjectメソッドが正確に書き込む内容を文書化する必要があります。

SerialysisのwriteObjectデータは、Listを返すSObject.getAnnotations（）メソッドを介して取得できます。 ObjectOutputStream.writeObject（Object）メソッドを使用して記録された各オブジェクトは、このリストにSObjectとして表示されます。 DataOutputから継承したObjectOutputStreamメソッド（ writeInt 、 writeUTFなど）への1つ以上の連続した呼び出しによって記録された各データは、SBlockDataとして表されます。 シリアル化されたストリームでは、このピース内の個々の要素を選択できません。 この情報は、@ serialDataタグで文書化された、ライターとリーダー間の合意です。

ArrayListのドキュメントに基づいて、次のようにして配列のサイズを取得できます。

 SObject slist = (SObject) SerialScan.examine(list); List<SEntity> writeObjectData = slist.getAnnotations(); SBlockData data = (SBlockData) writeObjectData.get(0); DataInputStream din = data.getDataInputStream(); int alen = din.readInt(); System.out.println("Array length: " + alen); 

Serialysisがテストタスクを解決する方法

完全なソースコードを省略して、冒頭で述べたQueryExp問題の解決策の概要のみを説明します。 QueryExpが次のように構築されているとします：

 QueryExp query = Query.or(Query.gt(Query.attr("Version"), Query.value(5)), Query.eq(Query.attr("SupportsSpume"), Query.value(true))); 

これは、「バージョン属性が5より大きい、またはSupportsSpume属性がtrueのMBeanを提供する」という意味です。 JDKのこのリクエストのtoString（）は次のようになります。

 ((Version) > (5)) or ((SupportsSpume) = (true)) 

そして、これはSerialScan.examineの結果がどのように見えるかです：

 SObject(javax.management.OrQueryExp){ exp1 = SObject(javax.management.BinaryRelQueryExp){ relOp = SPrim(int){0} exp1 = SObject(javax.management.AttributeValueExp){ attr = SString(String){"version"} } exp2 = SObject(javax.management.NumericValueExp){ val = SObject(java.lang.Long){ value = SPrim(long){5} } } } exp2 = SObject(javax.management.BinaryRelQueryExp){ relOp = SPrim(int){4} exp1 = SObject(javax.management.AttributeValueExp){ attr = SString(String){"supportsSpume"} } exp2 = SObject(javax.management.BooleanValueExp){ val = SPrim(boolean){true} } } } 

この構造に突入するコードを想像するのは簡単で、XMLに相当するものが作成されます。 互換性のある各JMX API実装は、まったく同じシリアル化されたフォームを作成する必要があるため、それを分析するコードはどこでも機能することが保証されます。

ここで、RMIスタブのポート番号の問題を解決するコード：

  public static int getPort(RemoteStub stub) throws IOException { SObject sstub = (SObject) SerialScan.examine(stub); List<SEntity> writeObjectData = sstub.getAnnotations(); SBlockData sdata = (SBlockData) writeObjectData.get(0); DataInputStream din = sdata.getDataInputStream(); String type = din.readUTF(); if (type.equals("UnicastRef")) return getPortUnicastRef(din); else if (type.equals("UnicastRef2")) return getPortUnicastRef2(din); else throw new IOException("Can't handle ref type " + type); } private static int getPortUnicastRef(DataInputStream din) throws IOException { String host = din.readUTF(); return din.readInt(); } private static int getPortUnicastRef2(DataInputStream din) throws IOException { byte hasCSF = din.readByte(); String host = din.readUTF(); return din.readInt(); } 

それを理解するには、 シリアル化されたRemoteObjectフォームの説明を見てください。

もちろん、このコードは難しいですが、移植するのは簡単で、使用することを約束しています。 RMIスタブから他のすべてのデータを抽出する方法を説明することは意味がないと思います-同じ方法を使用します。

おわりに

ほとんどの場合、深刻なニーズがあるまで、シリアル化された形式を掘り下げたくないでしょう。 しかし、それなしではできない場合、Serialysisはタスクを大幅に簡素化できます。

また、これは、独自のクラスが期待どおりにシリアライズされていることを確認するための良い方法です。

Serialysisライブラリは、 http ：//weblogs.java.net/blog/emcmanus/serialysis.zipからダウンロードできます。