Главная » Java, Советы » Рассмотрите возможность использования специализированной сериализованной формы

0

 

Если вы создаете класс в условиях дефицита времени, то, как правило, имеет смысл сконцентрировать усилия на построении самого лучшего АРI. Иногда это означает создание "одноразовой" реализации, которая в следующей версии поменяется. Обычно это проблем не вызывает, однако если данный класс реализует интерфейс Serializable и использует при этом сериализованную форму, предоставленную по умолчанию, вам уже никогда не удастся полностью избавиться от этой временной реализации, и она всегда будет навязывать вам именно эту сериализованную форму. Это не теоретическая проблема. Такое уже происходило с несколькими классами из библиотек для платформы Java, такими как B1gInteger.

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

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

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

// Хороший кандидат для использования формы,

 // предлагаемой по умолчанию

public class Name implements Serializable

/**

* Последнее имя (англ. ). Не должно быть пустым (non-null)

 * @serial

*/

private String lastName;

/**

* Первое имя. Не должно быть пустым.

*’@serial

*/

private String firstName;

/**

* Средний инициал или ‘\uOOOO’, если инициал отсутствует

* @serial

*/

private char middlelnitial;

// Остальное опущено

Логически имя человека в английском языке состоит из двух строк, представляющих последнее и первое имя, а также из некоего символа, соответствующего среднему инициалу. Экземпляры полей в классе Name в точности воспроизводят это .логическое содержание,

Если вы решите принять сериализованную форму, предлагаемую по умолчанию, во многих случаях сохранение инвариантов и безопасность требуют реализации метода readObj ect. В случае с классом Name метод readObject мог бы гарантировать, что поля lastName и firstName не будут иметь значения null. Эта тема подробно рассматривается в статье 56.

Заметим, что поля lastName, firstName и middlelnitial сопровождает комментарий к документации, хотя все они являются закры~ыми. Это необходимо поскольку эти закрытые поля определяют открытый АР!: сериализованную форму класса, а всякий открытый АР! должен быть документирован. Наличие тега @serial говорит утилите Javadoc о том, что эту информацию необходимо поместить на специальную страницу, где описываются сериализованные формы.

 

Теперь рассмотрим класс, который представляет набор строк (забудем на минуту о том, что для этого лучше было бы взять в библиотеке одну из стандартных реализаций интерфейса List):

 

// Ужасный кандидат на использование сериализованной формы,

// предлагаемой по умолчанию

public class StringList implements Serializable {

 private int size = 0;

private Entry head = null;

private static class Entry implements Serializable {

String data;

Entry next;

Entry previous;  }

// Остальное опущено

}

Логически этот класс представляет последовательность строк. Физически последовательность представлена им как дважды связный список. Если вы примите сериализованную форму, предлагаемую по умолчанию, она старательно отразит каждый элемент в этом связном списке, а также все связи между этими элементами в обоих направлениях.

В случае, когда физическое представление объекта существенно отличается от содержащихся в нем логических данных, сериализованная форма, предлагаемая по умолчанию, имеет четыре недостатка:

 

·     Она навсегда связывает внешний API класса с его текущим внутренним представлением. В приведенном примере закрытый

класс StringList.Entry становится частью открытого API. Даже если в будущей версии внутреннее представление StringList поменяется,

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

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

слишком велика, ее запись на диск или передача по сети

будет выполняться слишком медленно.

 

·      Она может обрабатываться чрезвычайно долго. Логика сериализации не содержит информации о топологии графа объекта, а потому приходится выполнять дорогостоящий обход вершин графа. В приведенном Примере достаточно было просто идти по ссылкам next.

·     Она может вызвать переполнение стека. Процедура сериализации, реализуемая по умолчанию, выполняет рекурсивный обход графа объектов, что может вызвать переполнение стека даже при обработке графов среднего размера. На моей машине к переполнению стека приводит сериализация экземпляра StringList с 1200 элементами. Количество элементов, вызывающее эту проблему, меняется в зависимости от реализации ]УМ. В некоторых реализациях этой проблемы вообще не существует.

Правильная сериализованная форма для класса StringList – это количество строк в списке, за которым следуют сами строки. Это соответствует освобожденным от деталей физической реализации логическим данным, представляемым классом StringList. Приведем исправленный вариант StringList, содержащий методы writeObject и readObject, которые реализуют правильную сериализованную форму. Напомним, что модификатор transient указывает на то, что экземпляр поля должен быть исключен из сериализованной формы, применяемой по умолчанию:

// Класс StringList справильной сериализованной формой

public class StringList implements Serializable

                private transient int size = о;

private transient Entry head = null;

// Больwе нет реализации Serializablel

private static class Entry {

String data;

Entry next;

Entry previous;

}

// Добавляет указанную строку в конец списка

public void add(String s) { … }

/**

* Сериализует данный экземпляр <tt>StringList</tt>.

*

* @serialData Показывается размер списка (количество

* содержащихся в нем строк) «tt>int</tt», за которым * в правильной последовательности   

*  следуют все

* элементы списка (каждый в виде <tt>String</tt». */

206private void writeObject(ObjectOutputStream s)

                     throws IОЕхсерtion {

         s.defaultWriteObject();

          s.writelnt(size);

// Выписываем все элементы в правильном порядке

         for (Entry е = head; е != null; е = e.next)

                     s.writeObject(e.data);

}

private void readObject(ObjectlnputStream s)

                     throws IOException, ClassNotFoundException {

         s.defaultReadObject();

         int size = s. readlnt();

// Считываем все элементы и вставляем

         for (int i = 0; i < size; i++)

                     add((String)s. readObject());   }

// Остальное опускаем

}

 

Заметим, что из метода writeObject вызывается defaultWriteObject, а из метода readObject делается вызов defaultReadObject, несмотря на то, что ни одно из полей класса StringList не попадает в сериализованную форму. Если все экземпляры полей имеют модификатор transient, то формально можно обойтись без вызова методов defaultWriteObject и defaultReadObject, но это не рекомендуется. Даже если все экземпляры полей имеют модификатор trаnsiеnt, вызов defaultWriteObject оказывает влияние на сериализованную форму, в результате чего значительно повышается гибкость сериализации. Полученная форма оставляет возможность в последующих версиях добавлять в форму новые экземпляры полей, сохраняя при этом прямую и обратную совместимость с предыдущими версиями. Так, если сериализовать экземпляр класса в более поздней версии, а десериализовать в более ранней версии, появившиеся поля будут проигнорированы. Если бы более ранняя версия метода readObject не вызывала метод defaultReadObject, десериализация закончилась бы инициированием StreamCorruptedException.

Заметим также, что хотя метод writeObject является закрытым, он сопровождается комментариями к документации. Объяснение здесь то же, что и в случае с комментариями для закрытых полей в классе Name. Этот закрытый метод определяет сериализованную форму  открытый API, а открытый API должен быть описан в документации. Как и тег @seria1 в случае с полями, тег @serialData для методов говорит утилите Javadoc о том, что данную информацию необходимо поместить на страницу с описанием сериализованных форм.

 

 

Что касается производительности, то при средней длине строки, равной десяти символам, сериализованная форма для исправленной версии StгiпgList будет занимать вдвое меньше места, чем в первоначальном варианте. На моей машине сериализация исправленного варианта StгiпgList при длине строк в десять символов выполняется примерно в два с половиной раза быстрее, чем сериализация первоначального варианта. 11 наконец, у исправленного варианта не возникает проблем с переполнением стека, а потому практически нет верхнего ограничения на размер StringList, для которого можно выполнить сериализацию.

Сериализованная форма, предлагаемая по умолчанию, плохо подходит для класса StringList, но есть классы, для которых она подходит еще меньше. Для StгiпgList сериализованная форма, применяемая по умолчанию, не имеет гибкости и работает медленно. Однако она является правильнои в том смысле, что в результате сериализации и десериализации экземпляра StringList получается точная копия исходного объекта, и все его инварианты будут сохранены. Но для любого объекта, чьи инварианты при вязаны к деталям реализации, это не так.

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

11спользуете вы или нет сериализованную форму, предлагаемую по умолчанию, каждый экземпляр поля, не помеченный модификатором trаnsiеnt, будет сериализован при вызове метода defaultWriteObject. Поэтому каждое поле, которое можно не заносить в форму, нужно пометить этим модификатором. К таковым относятся избыточные поля, чьи значения можно вычислить по таким "первичным полям данных", как кэшированное значение хэша. Сюда также относятся поля, чьи значения меняются при повторном запуске JVM. Например, это может быть поле типа 10ng, в котором хранится указатель на местную’ (native) структуру данных. Прежде чем согласиться на запись какого-либо поля в сериализованной форме, убедитесь в том, что его значение является частью логического состояния данного объекта. Если вы пользуетесь специальной сериализованной формой, большинство или даже все экземпляры полей нужно пометить модификатором trаnsiеnt, как в примере с классом StringList.

Если вы пользуетесь сериализованной формой, предлагаемой по умолчанию, и к тому же пометили одно или несколько полей как trаnsiеnt, помните о том, что при десериализации экземпляра эти поля получат значения по умолчанию: пu11 для полей ссылок на объекты, нуль для простых числовых полей и false для полей типа

 

boolean [JLS, 4.5.5]. Если для какого-либо из этих полей указанные значения неприемлемы, необходимо предоставить метод readObject, который вызывает метод defaultReadObject, а затем восстанавливает приемлемые значения в полях, помеченных как transient (статья 56). Альтернативный подход заключается в том, чтобы отложить инициализацию этих полей до первого вызова.

Независимо от того, какую сериализованную форму вы выберете, в каждом сериализуемом классе, который вы пишите, явным образом декларируйте serial version UID. Тем самым вы исключите этот идентификатор из числа возможных причин несовместимости (статья 54). Это также даст некоторый выигрыш в производительности. Если seriaL version UID не представлен, то при выполнении программы для его генерации потребуется выполнить трудоемкие вычисления. Для декларации seriaд version UID добавьте в ваш класс строку:

private static final long serialVersionUID = raтdoтLoтgValue;

 // Произвольное число типа long

 

Не важно, какое значение вы выберете для randoтLongValиe. Общепринятая практика предписывает генерировать это число, запуская для класса утилиту serialver. Однако можно взять число просто из "воздуха". Если вам когда-нибудь захочется создать новую версию класса, которая несовместима с имеющимися версиями, достаточно будет поменять значение в этой декларации. В результате попытки десериализировать экземпляры, сериализованные в предыдущих версиях, будут заканчиваться инициированием исключения InvalidClassException.

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

 

Источник: Джошуа Блох, Java TM Эффективное программирование, Издательство «Лори»

По теме:

  • Комментарии