Сериализация объектов в Java

Сериализация — механизм представления объекта в виде последовательности байтов, включая информацию о типе объекта в целом и типе данных сохраненных внутри объекта.

Мы все знаем, что Java позволяет нам создавать повторно используемые объекты в памяти. Однако, все эти объекты существуют только в период работы виртуальной машины. Сериализация позволяет сохранить ваши объекты для повторного использования после перезапуска программы.

Java API сериализации предоставляет стандартный механизм работы с сериализацией объектов для Java разработчиков. Этот API мал и прост в использовании, предоставляемые классы и методы понятны.

Мы посмотрим три разных пути для проведения сериализации: использование стандартного протокола, модификацию стандартного протокола и создание нашего собственного протокола, и мы исследуем, что происходит при кэшировании объектов, контроли версий, и влияние этого на производительность.

Стандартный механизм сериализации — интерфейс Serializable

Для сохранения объекта в Java, мы должны иметь сохраняемый объект. Объект делается сериализуемым путем реализации интерфейса java.io.Serializable, что значит для нижележащего API, что объект может быть сохранен в байтовом представлении и восстановлен в будущем

Интерфейса Serializable — пустой интерфейс пометка, указывающий что объект серийный. Ниже приведен максимально простой пример его использования:

import java.io.Serializable;
import java.util.Date;
import java.util.Calendar;
public class PersistentTime implements Serializable
{
  private Date time;
  public PersistentTime()
  {
    time = Calendar.getInstance().getTime();
  }
  public Date getTime()
  {
    return time;
  }
}

Как вы можете видеть, единственным отличием от создания обычного класса является реализация интерфейса java.io.Serializable в строке 40. Полностью пустой интерфейс Serializable является маркером — это простое разрешение механизму сериализации проверять класс на возможность его сохранения. Таким образом, обратим внимание на первое правило сериализации:

Следующий шаг — это, собственно, сохранение объекта. Это выполняется классом java.io.ObjectOutputStream. Этот класс является фильтрующим потоком — это надстройка над низкоуровневым потоком байтов (называемым узловым потоком) для работы с протоколом сериализации для нас. Узловые потоки могут быть использованы для записи в файловую систему или даже в сокет. Это означает, что мы можем легко передавать сохраняемый объект по сетевому кабелю и заново создавать его на другой машине!

Посмотрите на код, используемый для сохранения объекта PersistentTime:

import java.io.ObjectOutputStream;
import java.io.FileOutputStream;
import java.io.IOException;
public class FlattenTime
{
  public static void main(String [] args)
  {
    String filename = "time.ser";
    if(args.length > 0)
    {
      filename = args[0];
    }
    PersistentTime time = new PersistentTime();
    FileOutputStream fos = null;
    ObjectOutputStream out = null;
    try
    {
      fos = new FileOutputStream(filename);
      out = new ObjectOutputStream(fos);
      out.writeObject(time);
      out.close();
    }
    catch(IOException ex)
    {
      ex.printStackTrace();
    }
  }
}

Классы ObjectInputStream и ObjectOutputStream — обертки для потоков ввода/вывода с поддержкой записи и загрузки объектов. Интерфейс не зависит от платформы джава машины. Т.е. объект может быть создан на jvm одной платформы и без проблем загружен на другой.
Данных механизм может использоваться для сохранения состояния приложения или его части. А также для передачи объектов по сети.

Реальная работа происходит на строке 20 когда мы вызываем метод

, который запускает механизм сериализации и объект сохраняется (в данном случае в файл).

Для восстановления из файла мы можем использовать следующий код :

import java.io.ObjectInputStream;
import java.io.FileInputStream;
import java.io.IOException;
import java.util.Calendar;
public class InflateTime
{
  public static void main(String [] args)
  {
    String filename = "time.ser";
    if(args.length > 0)
    {
      filename = args[0];
    }
    PersistentTime time = null;
    FileInputStream fis = null;
    ObjectInputStream in = null;
    try
    {
      fis = new FileInputStream(filename);
      in = new ObjectInputStream(fis);
      time = (PersistentTime)in.readObject();
      in.close();
    }
    catch(IOException ex)
    {
      ex.printStackTrace();
    }
    catch(ClassNotFoundException ex)
    {
      ex.printStackTrace();
    }
    // напечатаем сохраненное время
    System.out.println("Flattened time: " + time.getTime());
    System.out.println();
    // напечатаем текущее время
    System.out.println("Current time: " + Calendar.getInstance().getTime());
  }
}

В коде выше, восстановление объекта происходит в строке 21 путем вызова метода

. Вызов метода считывает байты, которые мы предварительно сохранили, и создает объект, являющийся точной копией оригинала. Так как

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

Позже, мы просто вызываем метод

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

Еще один пример сериализации объектов приведен ниже:

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class CompanyInfoSerializeble implements Serializable {

    public String name;
    public String address;
    double lon, lat;

    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder();
        sb.append('{').append("name: ").append(name).append(", ");
        sb.append("address: ").append(address).append(", ");
        sb.append("location: (").append(lon).append(", ").append(lat)
                .append(')');
        sb.append('}');
        return sb.toString();
    }

  // сохранение объекта - сериализация
    public static void demoSerialize(CompanyInfoSerializeble obj) {
        try {
            FileOutputStream fos = new FileOutputStream("test.data");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(obj); 
            oos.close();
            fos.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    // загрузка объекта - десериализация
    public static CompanyInfoSerializeble demoDeserialize() {
        CompanyInfoSerializeble obj = null;
        try {
            FileInputStream fis = new FileInputStream("test.data");
            ObjectInputStream ois = new ObjectInputStream(fis);
            obj = (CompanyInfoSerializeble) ois.readObject();
            ois.close();
            fis.close();
        } catch (IOException i) {
            i.printStackTrace();

        } catch (ClassNotFoundException c) {
            System.out.println("CompanyInfoSerializeble class not found");
            c.printStackTrace();
        }

        return obj;
    }

    public static void main(String[] args) {
        CompanyInfoSerializeble obj = new CompanyInfoSerializeble();
        obj.name = "darkraha.com";
        obj.address = "internet";
        obj.lon=57.000;
        obj.lat=37.000;
        
        System.out.println("saved object: "+obj);
        demoSerialize(obj);
        CompanyInfoSerializeble obj2 = demoDeserialize();
        System.out.println("loaded object: "+obj2);
    }

}

Базовый механизм сериализации в Java прост в использовании, но здесь есть еще несколько вещей, которые нужно знать. Как упоминалось ранее, только объекты, реализующие Serializable могут быть сохранены. Класс

не реализовывает этот интерфейс. Поэтому, не все объекты в Java могут быть сохранены автоматически. Хорошей новостью является то, что большинство из них — такие как AWT и Swing GUI компоненты, строки и массивы — сериализуемы.

Если среди членов класса есть ссылки на не серийные объекты, то при попытке сериализовать такой класс возникнет исключение NotSerializableException.

С другой стороны, некоторые системные классы, такие как Thread, OutputStream и их подклассы, а также Socket несериализуемы. В действительности это не имеет никакого смысла. Например, поток, работающий в моей JVM может использовать память моей системы. Сохранение потока и попытка его запустить в вашей JVM не имеет смысла. Другим важным моментом в том, почему

не реализует интерфейс

, является то, что любой создаваемый вами класс наследует только код Object (а не других сериализуемых классов), несериализуем до тех пор, пока вы не реализуете интерфейс самостоятельно (как сделано в предыдущем примере).

В этой ситуации присутствует проблема: что если мы имеем класс, который содержит экземпляр класса Thread? В этом случае, можем ли мы когда-либо сохранить объект этого типа? Ответ утвердителен, пока вы сообщаете механизму сериализации наши намерения маркируя наш объект класса Thread как

.

ключевое слово transient

Атрибут transient указывает, что указанный член класса должен игнорироваться механизмом сериализации. Полезно для секретных (пароль) или не особо важных данных.

Пусть мы хотим создать класс, производящий анимацию. Я на самом деле не приведу здесь код анимации. Вот используемый класс:

import java.io.Serializable;
public class PersistentAnimation implements Serializable, Runnable
{
  transient private Thread animator;
  private int animationSpeed;
  public PersistentAnimation(int animationSpeed)
  {
    this.animationSpeed = animationSpeed;
    animator = new Thread(this);
    animator.start();
  }
  public void run()
  {
    while(true)
    {
      // выполнение анимации
    }
  }
}

Когда мы создаем экземпляр класса

, поток animator будет создан и запущен, как мы и ожидали. Мы пометили поток модификатором

, чтобы сообщить механизму сериализации, что поле не будет сохраняться вместе с остальным состоянием объекта (в этом случае, это переменная speed). Вывод: вы должны отметить модификатором

любое поле, которое не может быть сериализованым или любое поле, которое вы не хотите сериализовывать. Сериализация не обращет внимания на модификаторы доступа, такие как

— все долгоживущие поля рассматриваются как часть сохраняемого состояния объекта и допускаются к сохранению.

Поэтому можно сформулировать следующие правила сериализации:

• Чтобы быть сохраняемым объект должен реализовывать интерфейс
  Serializable

  или наследовать его реализацию из его иерархии объектов.

• Сохраняемый объект должен отмечать все несериализуемые поля модификатором
  transient

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

то в результате работы программы во второй строке вместо адреса будет

.

Модификация стандартного протокола: переопределение сериализации

Хотя код анимации выше демонстрирует, как нить может быть включена в объект, и при этом объект остается сериализуемым, существует серьезная проблема, если мы рассмотрим, как Java создает объекты. К сведению, когда мы создаем объект с помощью ключевого слова new, конструктор объекта вызывается только тогда, когда создается новый экземпляр класса. Сохраняя этот базовый факт в памяти, вернемся к нашему коду анимации. Сначала, мы создаем объект типа

, который запускает нить анимации. Далее, мы сериализуем объект с помощью кода:

PersistentAnimation animation = new PersistentAnimation(10);
FileOutputStream fos = ...
ObjectOutputStream out = new ObjectOutputStream(fos);
out.writeObject(animation);

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

. Запомните, конструктор вызывается только при создании нового экземпляра. Мы не создаем здесь новый экземпляр, мы восстанавливаем сохраненный объект. В итоге объект анимации будет работать только один раз, при первом создании. Метод создания не сохраняется, не так ли?

Но есть и хорошие новости. Мы можем заставить наш объект работать так, как мы хотим; мы можем сделать рестарт анимации при восстановлении объекта. Чтобы сделать это, мы можем, например, создать вспомогательный метод

, который делает то, что должен делать конструктор. Мы можем затем вызвать этот метод из конструктора, после чего мы считываем объект. Неплохо, но это приводит к увеличению сложности. Теперь, кто-то, кто хочет использовать этот объект анимации, будет знать какой метод нужно вызвать после обычного процесса десериализации. Это не делает механизм цельным, хотя Java API сериализации обещает это разработчикам.

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

• writeObject — запись объекта в поток;
• readObject — чтение объекта из потока;
• writeReplace — позволяет заменить себя экземпляром другого класса перед записью;
• readResolve — позволяет заменить на себя другой объект после чтения;

Эти методы объявлены (и должны быть объявлены) private, проверьте, что эти методы не уналедованы и не переопределены или не перегружены. Фокус в том, что виртуальная машина автоматически проверит, объявлены ли эти методы в течении вызова соответствующего метода. Виртуальная машина может вызывать private методы вашего класса когда она хочет, но другие объекты нет. Таким образом, целостность класса сохраняется и протокол сериализации может продолжить работу, как обычно. Протокол сериализации всегда используется тем же способом, путем вызова любого метода:

или

. Итак, хотя эти специализированные private методы предоставлены, сериализация объекта работает также по отношению к любому вызываемому объекту.

Принимая все это во внимание, посмотрим на исправленную версию PersistentAnimation который содержит эти private методы для предоставления нам контроля над процессом десериализаци, давая нам псевдоконструктор:

// пример из из SDN
import java.io.Serializable;
public class PersistentAnimation implements Serializable, Runnable
{
  transient private Thread animator;
  private int animationSpeed;
  public PersistentAnimation(int animationSpeed)
  {
    this.animationSpeed = animationSpeed;
    startAnimation();
  }
  public void run()
  {
    while(true)
    {
      // do animation here
    }
  }
  private void writeObject(ObjectOutputStream out) throws IOException
  {
    out.defaultWriteObject();
  }
  private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException
  {
    // our "pseudo-constructor"
    in.defaultReadObject();
    // now we are a "live" object again, so let's run rebuild and start
    startAnimation();
  }
  private void startAnimation()
  {
    animator = new Thread(this);
    animator.start();
  }
}

Обратите внимание на первую строку каждого из новых

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

заставляет заработать протокол сериализации. Сначала объект проверяется на реализацию

и затем проверяется, педоставлены ли эти

методы. Если они предоставлены, потоковый класс передается как параметр, давая контроль над его использованием.

Эти

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

Запрещаем сериализацию

Мы увидели простоту процесса сериализации, сейчас увидим несколько больше. Что если вы создаете класс, чей класс-предок сериализуем, но вы не хотите чтобы новый класс был сериализуемым? Вы не можете убрать реализацию интерфейса, следовательно если ваш класс-предок реализовал

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

методы для генерации исключения

. Здесь показано, как это можно сделать:

private void writeObject(ObjectOutputStream out) throws IOException
{
  throw new NotSerializableException("Не сегодня!");
}
private void readObject(ObjectInputStream in) throws IOException
{
  throw new NotSerializableException("Не сегодня!");
}

Любая попытка записи или чтения этого объекта всегда будет генерировать исключение. Запомните, так как эти методы объявлены как private, никто не может изменить ваш код без наличия доступных исходных текстов — Java не допускает перекрытие этих методов.

Создание вашего собственного механизма сериализации: интерфейс Externalizable

Также есть возможность определить полностью свой механизм сериализации. Для нужно реализовать интерфейс Externalizable вместо

. Этот интерфейс содержит два метода:

public void writeExternal(ObjectOutput out) throws IOException;
public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException;

Переопределите эти методы для предоставления вашего протокола. В отличие от предыдущих двух вариантов сериализации, здесь ничего не предоставляется. Следовательно, протокол полностью в ваших руках. Несмотря на то, что это более сложный сценарий, он также наиболее контролируемый. Пример ситуации для альтернативного типа сериализации: чтение и запись PDF файлов в Java приложении. Если вы знаете как писать и читать PDF файлы (необходимую последовательность байтов), вы можете предоставить PDF-специфичный протокол в методах

и

.

Однако, как и ранее, здесь нет различия в том, какая реализация

используется классом. Только вызовите

или

и, вуаля, эти методы интерфейса

будут вызваны автоматически.

Подводные камни сериализации

Имеются некоторые подводные камни механизма сериализации, которые могут выглядеть очень странно для неподготовленных разработчиков. Цель этой статьи — подготовить вас! — поговорим о некоторых затруднениях и посмотрим, почему они существуют и как их обрабатывать.

Кэширование объектов в потоке

Сначала рассмотрим ситуацию в которой объект записан в поток и затем записывается снова. По умолчанию,

будет сохранять ссылку на объект, записанный в него. Это значит, что если состояние записанного объекта записано и затем записано снова, тогда новое состояние объекта не будет сохранено! Здесь кусок кода, показывающий эту проблему в действии:

ObjectOutputStream out = new ObjectOutputStream(...);
MyObject obj = new MyObject(); //должен реализовывать интерфейс Serializable
obj.setState(100);
out.writeObject(obj); // сохраняет объект с состоянием = 100
obj.setState(200);
out.writeObject(obj); // не сохраняет новое состояние объекта

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

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

Контроль версий

Представьте, что вы создали класс, создали его экземпляр, и записали его в поток объектов. Этот сохраненный объект некоторое время находится в файловой системе. Тем временем, вы обновили файл класса, возможно добавили новое поле. Что произойдет, когда вы попытаетесь прочитать сохраненный объект?

Плохой новостью является то, что будет выработано исключение —

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

Да, это возможно, но потребуются небольшие манипуляции с кодом. Идентификатор, являющийся частью всех классов содержится в поле

. Если вы хотите контролировать версионность, вы просто подставляете поле

вручную и обеспечиваете ее постоянство при изменениях, вносимых в класс. Вы можете использовать утилиту serialver, поставляемую с дистрибутивом JDK, для просмотра кода по-умолчанию (по-умолчанию это хэш-код объекта).

Пример использования serialver с классом с именем

> serialver Baz
> Baz: static final long 
serialVersionUID = 10275539472837495L;

источник