Пакет java.io

Сериализация объектов (serialization)

Для объектов процесс преобразования в последовательность байт и обратно организован несколько сложнее – объекты имеют различную структуру, хранят ссылки на другие объекты и т.д. Поэтому такая процедура получила специальное название - сериализация (serialization), обратное действие, – то есть воссоздание объекта из последовательности байт – десериализация.

Поскольку сериализованный объект – это последовательность байт, которую можно легко сохранить в файл, передать по сети и т.д., то и объект затем можно восстановить на любой машине, вне зависимости от того, где проводилась сериализация. Разумеется, Java позволяет не задумываться при этом о таких факторах, как, например, используемая операционная система на машине-отправителе и получателе. Такая гибкость обусловила широкое применение сериализации при создании распределенных приложений, в том числе и корпоративных (enterprise) систем.

Стандартная сериализация

Для представления объектов в виде последовательности байт определены унаследованные от DataInput и DataOutput интерфейсы ObjectInput и ObjectOutput, соответственно. В java.io имеются реализации этих интерфейсов – классы ObjectInputStream и ObjectOutputStream.

Эти классы используют стандартный механизм сериализации, который предлагает JVM. Для того, чтобы объект мог быть сериализован, класс, от которого он порожден, должен реализовывать интерфейс java.io.Serializable. В этом интерфейсе не определен ни один метод. Он нужен лишь для указания, что объекты класса могут участвовать в сериализации. При попытке сериализовать объект, не имеющий такого интерфейса, будет брошен java.io.NotSerializableException.

Чтобы начать сериализацию объекта, нужен выходной поток OutputStream, в который и будет записываться сгенерированная последовательность байт. Этот поток передается в конструктор ObjectOutputStream. Затем вызовом метода writeObject() объект сериализуется и записывается в выходной поток. Например:

ByteArrayOutputStream os = 
   new ByteArrayOutputStream();
Object objSave = new Integer(1);
ObjectOutputStream oos = 
   new ObjectOutputStream(os);
oos.writeObject(objSave);

Чтобы увидеть, во что превратился объект objSave, можно просмотреть содержимое массива:

byte[] bArray = os.toByteArray();

А чтобы восстановить объект, его нужно десериализовать из этого массива:

ByteArrayInputStream is = 
   new ByteArrayInputStream(bArray);
ObjectInputStream ois = 
   new ObjectInputStream(is);
Object objRead = ois.readObject();

Теперь можно убедиться, что восстановленный объект идентичен исходному:

System.out.println("readed object is: " + 
                    objRead.toString());
System.out.println("Object equality is: " + 
   (objSave.equals(objRead)));
System.out.println("Reference equality is: " +
                   (objSave==objRead));

Результатом выполнения приведенного выше кода будет:

readed object is: 1
Object equality is: true
Reference equality is: false

Как мы видим, восстановленный объект не совпадает с исходным (что очевидно – ведь восстановление могло происходить и на другой машине), но равен сериализованному по значению.

Как обычно, для упрощения в примере была опущена обработка ошибок. Однако, сериализация (десериализация) объектов довольно сложная процедура, поэтому возникающие сложности не всегда очевидны. Рассмотрим основные исключения, которые может генерировать метод readObject() класса ObjectInputStream.

Предположим, объект некоторого класса TestClass был сериализован и передан по сети на другую машину для восстановления. Может случиться так, что у считывающей JVM на локальном диске не окажется описания этого класса (файл TestClass.class ). Поскольку стандартный механизм сериализации записывает в поток байт лишь состояние объекта, для успешной десериализации необходимо наличие описание класса. В результате будет брошено исключение ClassNotFoundException.

Причина появления java.io.StreamCorruptedException вполне очевидна из названия – неправильный формат входного потока. Предположим, происходит попытка считать сериализованный объект из файла. Если этот файл испорчен (для эксперимента можно открыть его в текстовом редакторе и исправить несколько символов), то стандартная процедура десериализации даст сбой. Эта же ошибка возникнет, если считать некоторое количество байт (с помощью метода read ) непосредственно из надстраиваемого потока InputStream. В таком случае ObjectInputStream снова обнаружит сбой в формате данных и будет брошено исключение java.io.StreamCorruptedException.

Поскольку ObjectOutput наследуется от DataOutput, ObjectOutputStream может быть использован для последовательной записи нескольких значений как объектных, так и примитивных типов в произвольной последовательности. Если при считывании будет вызван метод readObject, а в исходном потоке следующим на очереди записано значение примитивного типа, будет брошено исключение java.io.OptionalDataException. Очевидно, что для корректного восстановления данных из потока их нужно считывать именно в том порядке, в каком были записаны.

Восстановление состояния

Итак, сериализация объекта заключается в сохранении и восстановлении состояния объекта. В Java в большинстве случаев состояние описывается значениями полей объекта. Причем, что важно, не только тех полей, которые были явно объявлены в классе, от которого порожден объект, но и унаследованных полей.

Предположим, мы бы попытались своими силами реализовать стандартный механизм сериализации. Нам передается выходной поток, в который нужно записать состояние нашего объекта. С помощью DataOutput интерфейса можно легко сохранить значения всех доступных полей (будем для простоты считать, что они все примитивного типа). Однако в большинстве случаев в родительских классах могут быть объявлены недоступные нам поля (например, private ). Тем не менее, такие поля, как правило, играют важную роль в определении состояния объекта, так как они могут влиять на результат работы унаследованных методов. Как же сохранить их значения?

С другой стороны, не меньшей проблемой является восстановление объекта. Как говорилось раньше, объект может быть создан только вызовом его конструктора. У класса, от которого порожден десериализуемый объект, может быть несколько конструкторов, причем, некоторые из них, или все, могут иметь аргументы. Какой из них вызвать? Какие значения передать в качестве аргументов?

После создания объекта необходимо установить считанные значения его полей. Однако многие классы имеют специальные set -методы для этой цели. В таких методах могут происходить проверки, могут меняться значения вспомогательных полей. Пользоваться ли этими методами? Если их несколько, то как выбрать правильный и какие параметры ему передать? Снова возникает проблема работы с недоступными полями, полученными по наследству. Как же в стандартном механизме сериализации решены все эти вопросы?

Во-первых, рассмотрим подробнее работу с интерфейсом Serializable. Заметим, что класс Object не реализует этот интерфейс. Таким образом, существует два варианта – либо сериализуемый класс наследуется от Serializable -класса, либо нет. Первый вариант довольно прост. Если родительский класс уже реализовал интерфейс Serializable, то наследникам это свойство передается автоматически, то есть все объекты, порожденные от такого класса, или любого его наследника, могут быть сериализованы.

Если же наш класс впервые реализует Serializable в своей ветке наследования, то его суперкласс должен отвечать специальному требованию – у него должен быть доступный конструктор без параметров. Именно с помощью этого конструктора будет создан десериализуемый объект и будут проинициализированы все поля, унаследованные от классов, не наследующих Serializable.

Рассмотрим пример:

// Родительский класс, не реализующий Serializable
public class Parent {
   public String firstName;
   private String lastName;
   public Parent(){
      System.out.println("Create Parent");
      firstName="old_first";
      lastName="old_last";
   }
   public void changeNames() {
      firstName="new_first";
      lastName="new_last";
   }
   public String toString() {
      return super.toString()+",first="+firstName+",last="+lastName;
   }
}
// Класс Child, впервые реализовавший Serializable
public class Child extends Parent implements Serializable {
   private int age;
   public Child(int age) {
      System.out.println("Create Child");
      this.age=age;
   }
   public String toString() {
      return super.toString()+",age="+age;
   }
}
// Наследник Serializable-класса
public class Child2 extends Child {
   private int size;
   public Child2(int age, int size) {
      super(age);
      System.out.println("Create Child2");
      this.size=size;
   }
   public String toString() {
      return super.toString()+",size="+size;
   }
}
// Запускаемый класс для теста
public class Test {
   public static void main(String[] arg) {
      try {
         FileOutputStream fos=new FileOutputStream("output.bin");
         ObjectOutputStream oos=new ObjectOutputStream(fos);
         Child c=new Child(2);
         c.changeNames();
         System.out.println(c);
         oos.writeObject(c);
         oos.writeObject(new Child2(3, 4));
         oos.close();
         System.out.println("Read objects:");
         FileInputStream fis=new FileInputStream("output.bin");
         ObjectInputStream ois=new ObjectInputStream(fis);
         System.out.println(ois.readObject());
         System.out.println(ois.readObject());
         ois.close();
      } catch (Exception e) { // упрощенная обработка для краткости
         e.printStackTrace();
      }
   }
}

В этом примере объявлено 3 класса. Класс Parent не реализует Serializable и, следовательно, не может быть сериализован. В нем объявлено 2 поля, которые при создании получают значения, содержащие слово "old" ("старый"). Кроме этого, объявлен метод, позволяющий модифицировать эти поля. Он выставляет им значения, содержащие слово "new" ("новый’). Также переопределен метод toString(), чтобы дать возможность узнать значения этих полей.

Поскольку класс Parent имеет доступный конструктор по умолчанию, его наследник может реализовать интерфейс Serializable. Обратите внимание, что у самого класса Child такого конструктора уже нет. Также объявлено поле и модифицирован метод toString().

Наконец, класс Child2 наследуется от Child, а потому автоматически является допустимым для сериализации. Аналогично, имеет новое поле, значение которого отображает toString().

Запускаемый класс Test сериализует в файл output.bin два объекта. Обратите внимание, что у первого из них предварительно вызывается метод changeNames(), который модифицирует значения полей, унаследованных от класса Parent.

Результат выполнения примера:

Create Parent
Create Child
Child@ad3ba4,first=new_first,last=new_last,age=2
Create Parent
Create Child
Create Child2
Read objects:
Create Parent
Child@723d7c,first=old_first,last=old_last,age=2
Create Parent
Child2@22c95b,first=old_first,last=old_last,age=3,size=4

Во всех конструкторах вставлена строка, выводящая сообщение на консоль. Так можно отследить, какие конструкторы вызываются во время десериализации. Видно, что для объектов, порожденных от Serializable -классов, конструкторы не вызываются вовсе. Идет обращение лишь к конструктору без параметров не- Serializable -суперкласса.

Сравним значения полей первого объекта и его копии, полученной десериализацией. Поля, унаследованные от не- Serializable -класса ( firstName, lastName ), не восстановились. Они имеют значения, полученные в конструкторе Parent без параметров. Поля, объявленные в Serializable -классе, свои значения сохранили. Это верно и для второго объекта – собственные поля Child2 и унаследованные от Child имеют точно такие же значения, что и до сериализации. Их значения были записаны, а потом считаны и напрямую установлены из потока данных.

Иногда в классе есть поля, которые не должны участвовать в сериализации. Тому может быть несколько причин. Например, это поле малосущественно (временная переменная) и сохранять его нет необходимости. Если сериализованный объект передается по сети, то исключение такого поля из сериализации позволяет уменьшить нагрузку на сеть и ускорить работу приложения.

Некоторые поля хранят значения, которые не будут иметь смысла при пересылке объекта на другую машину, или при воссоздании его спустя какое-то время. Например, сетевое соединение, или подключение к базе данных, в таких случаях нужно устанавливать заново.

Затем, в объекте может храниться конфиденциальная информация, например, пароль. Если такое поле будет сериализовано и передано по сети, его значение может быть перехвачено и прочитано, или даже подменено.

Для исключения поля объекта из сериализации его необходимо объявить с модификатором transient. Например, следующий класс:

class Account implements 
      java.io.Serializable {
   private String name;
   private String login;
   private transient String password;
   /* объявление других элементов класса
   ...
   */
}

У такого класса поле password в сериализации участвовать не будет и при восстановлении оно получит значение по умолчанию (в данном случае null ).

Особого внимания требуют статические поля. Поскольку они принадлежат классу, а не объекту, они не участвуют в сериализации. При восстановлении объект будет работать с таким значением static -поля, которое уже установлено для его класса в этой JVM.

Граф сериализации

До этого мы рассматривали объекты, которые имеют поля лишь примитивных типов. Если же сериализуемый объект ссылается на другие объекты, их также необходимо сохранить (записать в поток байт), а при десериализации – восстановить. Эти объекты, в свою очередь, также могут ссылаться на следующие объекты. При этом важно, что если несколько ссылок указывают на один и тот же объект, то этот объект должен быть сериализован лишь однажды, а при восстановлении все ссылки должны вновь указывать на него одного. Например, сериализуемый объект A ссылается на объекты B и C, каждый из которых, в свою очередь, ссылается на один и тот же объект D. После десериализации не должно возникать ситуации, когда B ссылается на D1, а C – на D2, где D1 и D2 – равные, но все же различные объекты.

Для организации такого процесса стандартный механизм сериализации строит граф, включающий в себя все участвующие объекты и ссылки между ними. Если очередная ссылка указывает на некоторый объект, сначала проверяется – нет ли такого объекта в графе. Если есть – объект второй раз не сериализуется. Если нет – новый объект добавляется в граф.

При построении графа может встретиться объект, порожденный от класса, не реализующего интерфейс Serializable. В этом случае сериализация прерывается, генерируется исключение java.io.NotSerializableException.

Рассмотрим пример:

import java.io.*;
class Point implements Serializable {
   double x;
   double y;
   public Point(double x, double y) {
      this.x = x;
      this.y = y;
   }
   public String toString() {
      return "("+x+","+y+") reference="+super.toString();
   }
}
class Line implements Serializable {
   Point point1;
   Point point2;
   int index;
   public Line() {
      System.out.println("Constructing empty line");
   }
   Line(Point p1, Point p2, int index) {
      System.out.println("Constructing line: " + index);
      this.point1 = p1;
      this.point2 = p2;
      this.index = index;
   }
   public int getIndex() { return index; }
   public void setIndex(int newIndex) { index = newIndex; }
   public void printInfo() {
      System.out.println("Line: " + index);
      System.out.println(" Object reference: " + super.toString());
      System.out.println(" from point "+point1);
      System.out.println(" to point "+point2);
   }
}
public class Main {
   public static void main(java.lang.String[] args) {
      Point p1 = new Point(1.0,1.0);
      Point p2 = new Point(2.0,2.0);
      Point p3 = new Point(3.0,3.0);
      Line line1 = new Line(p1,p2,1);
      Line line2 = new Line(p2,p3,2);
      System.out.println("line 1 = " + line1);
      System.out.println("line 2 = " + line2);
      String fileName = "d:\\file";
      try{
         // записываем объекты в файл
         FileOutputStream os = new FileOutputStream(fileName);
         ObjectOutputStream oos = new ObjectOutputStream(os);
         oos.writeObject(line1);
         oos.writeObject(line2);
         // меняем состояние line1 и записываем его еще раз
         line1.setIndex(3);
         //oos.reset();
         oos.writeObject(line1);
         // закрываем потоки
         // достаточно закрыть только поток-надстройку
         oos.close();
         // считываем объекты
         System.out.println("Read objects:");
         FileInputStream is = new FileInputStream(fileName);
         ObjectInputStream ois = new ObjectInputStream(is);
         for (int i=0; i<3; i++) { // Считываем 3 объекта
            Line line = (Line)ois.readObject();
            line.printInfo();
         } ois.close();
      } catch(ClassNotFoundException e) {
         e.printStackTrace();
      } catch(IOException e) {
         e.printStackTrace();
      }
   }
}

В этой программе работа идет с классом Line (линия), который имеет 2 поля типа Point (линия описывается двумя точками). Запускаемый класс Main создает два объекта класса Line, причем, одна из точек у них общая. Кроме этого, линия имеет номер (поле index ). Созданные линии (номера 1 и 2) записываются в поток, после чего одна из них получает новый номер (3) и вновь сериализуется.

Выполнение этой программы приведет к выводу на экран примерно следующего:

Constructing line: 1
Constructing line: 2
line 1 = Line@7d39
line 2 = Line@4ec
Read objects:
Line: 1
   Object reference: Line@331e
   from point (1.0,1.0) reference=Point@36bb
   to point (2.0,2.0) reference=Point@386e
Line: 2
   Object reference: Line@6706
   from point (2.0,2.0) reference=Point@386e
   to point (3.0,3.0) reference=Point@68ae
Line: 1
   Object reference: Line@331e
   from point (1.0,1.0) reference=Point@36bb
   to point (2.0,2.0) reference=Point@386e

Из примера видно, что после восстановления у линий сохраняется общая точка, описываемая одним и тем же объектом (хеш-код 386e ).

Третий записанный объект идентичен первому, причем, совпадают даже объектные ссылки. Несмотря на то, что при записи третьего объекта значение index было изменено на 3, в десериализованном объекте оно осталось равным 1. Так произошло потому, что объект, описывающий первую линию, уже был задействован в сериализации и, встретившись во второй раз, повторно записан не был.

Чтобы указать, что сеанс сериализации завершен, и получить возможность передавать измененные объекты, у ObjectOutputStream нужно вызвать метод reset(). В рассматриваемом примере для этого достаточно убрать комментарий в строке

//oos.reset();

Если теперь запустить программу, то можно увидеть, что третий объект получит номер 3.

Constructing line: 1
Constructing line: 2
line 1 = Line@ea2dfe
line 2 = Line@7182c1
Read objects:
Line: 1
   Object reference: Line@a981ca
   from point (1.0,1.0) reference=Point@1503a3
   to point (2.0,2.0) reference=Point@a1c887
Line: 2
   Object reference: Line@743399
   from point (2.0,2.0) reference=Point@a1c887
   to point (3.0,3.0) reference=Point@e7b241
Line: 3
   Object reference: Line@67d940
   from point (1.0,1.0) reference=Point@e83912
   to point (2.0,2.0) reference=Point@fae3c6

Однако это будет уже новый объект, ссылка на который отличается от первой считанной линии. Более того, обе точки будут также описываться новыми объектами. То есть в новом сеансе все объекты были записаны, а затем восстановлены заново.

Расширение стандартной сериализации

Некоторым сложно организованным классам требуется особый подход для сериализации. Для расширения стандартного механизма можно объявить в классе два метода с точно такой сигнатурой:

private void writeObject(
               java.io.ObjectOutputStream out)
   throws IOException;
private void readObject(
               java.io.ObjectInputStream in)
   throws IOException, ClassNotFoundException;

Если в классе объявлены такие методы, то при сериализации объекта для записи его состояния будет вызван writeObject, который должен сгенерировать последовательность байт и записать ее в поток out, полученный в качестве аргумента. При этом можно вызвать стандартный механизм записи объекта путем вызова метода

out.defaultWriteObject();

Этот метод запишет все не- transient и не- static поля в поток данных.

В свою очередь, при десериализации метод readObject должен считать данные из потока in (также полученного в качестве аргумента) и восстановить значения полей класса. При реализации этого метода можно обратиться к стандартному механизму с помощью метода:

in.defaultReadObject();

Этот метод считывает описание объекта из потока и присваивает значения соответствующих полей в текущем объекте.

Если же процедура сериализации в корне отличается от стандартной, то для таких классов предназначен альтернативный интерфейс java.io.Externalizable.

При использовании этого интерфейса в поток автоматически записывается только идентификация класса. Сохранить и восстановить всю информацию о состоянии экземпляра должен сам класс. Для этого в нем должны быть объявлены методы writeExternal() и readExternal() интерфейса Externalizable. Эти методы должны обеспечить сохранение состояния, описываемого полями самого класса и его суперкласса.

При восстановлении Externalizable -объекта экземпляр создается путем вызова конструктора без аргументов, после чего вызывается метод readExternal.

Метод writeExternal имеет сигнатуру:

void writeExternal(ObjectOutput out) 
   throws IOException;

Для сохранения состояния вызываются методы ObjectOutput, с помощью которых можно записать как примитивные, так и объектные значения. Для корректной работы в соответствующем методе

void readExternal(ObjectInput in) 
   throws IOException,ClassNotFoundException;

эти значения должны быть считаны в том же самом порядке.