Сериализация Java - преимущества и недостатки, использовать или избежать? [закрыто]

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

Этот вопрос возник у меня после просмотра статьи DZone. Является ли сериализация объекта злом?

И вот строки, которые породили мой вопрос:

Если вы посмотрите на Java и его сессионные объекты, используется чистая сериализация объектов. Предполагая, что сеанс приложения является довольно коротким, то есть самое большее несколько часов, сериализация объектов проста, хорошо поддерживается и встроена в концепцию Java сеанса. Однако, когда постоянство данных длится более длительный период времени, возможно, дни или недели, и вам приходится беспокоиться о новых выпусках приложения, сериализация быстро становится злой. Любой хороший Java-разработчик знает, что если вы планируете сериализовать объект даже в сеансе, вам нужен реальный идентификатор сериализации (serialVersionUID), а не просто 1L, и вам необходимо реализовать интерфейс Serializable. Однако большинство разработчиков не знают настоящих правил, лежащих в основе процесса десериализации Java. Если ваш объект изменился, больше, чем просто добавление простых полей к объекту, Возможно, что Java не сможет правильно десериализовать объект, даже если идентификатор сериализации не изменился. Внезапно вы больше не можете получать свои данные, что по своей сути плохо.

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

Сериализация в основном используется в двух областях:

• прототипирование постоянства

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

• кратковременное хранение почти произвольных объектов:

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

Почти во всех других случаях недостатки, о которых вы (и статья) упоминаете, слишком велики: точный формат трудно поддерживать стабильным, изменения классов могут легко сделать ваши сериализованные данные нечитаемыми, чтение / запись данных в коде, отличном от Java, почти невозможно (или, по крайней мере, намного сложнее, чем необходимо).

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

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

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

Каковы преимущества сериализации по сравнению с несериализационными методами?

Java-сериализация имеет ряд преимуществ:

• Встроено в систему : вам не нужно полагаться на сторонние инструменты, библиотеки или конфигурацию.

• Относительно просто для понимания , по крайней мере, в начале.

• Каждый разработчик знает это (или должен). Независимо от того, одобряют ли разработчики Java или нет, они, вероятно, знакомы с сериализацией объектов Java.

И, конечно же, есть недостатки:

• Обходит стандартный поток Java. Выделяет память, но не вызывает конструктор, поэтому временные поля не инициализируются. Поля инициализируются в алфавитном порядке, а не в исходном порядке.

• Не так эффективно с точки зрения пространства, но и не ужасно. Вы можете сжать результат.

• Хрупкий, если вы не принимаете меры предосторожности, когда ваши объекты меняются. И даже тогда.

Когда его следует использовать и когда его следует избегать?

Используйте когда :

• Размер развертывания имеет значение. Встроено в систему, поэтому 0 лишних байтов.

• Все актеры будут использовать совместимые версии.

• Долгосрочное хранение не является проблемой.

Избегайте, когда :

• Любое из вышеперечисленного не распространяется.

Сериализация и ORM / база данных - это разные вещи, хотя есть некоторые совпадения.

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

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

Используйте ORM, если вы хотите сохранить данные в базе данных для ситуаций, когда вы имеете дело с большими объемами данных или вам необходимо сообщить, выполнить поиск / запрос, создать хранилище или другие вещи, которые хороши для баз данных. Используйте сериализацию, когда вы хотите сохранить представление вашей структуры данных на диск.

Сериализация редко используется на практике.

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

Для данных, которые необходимо хранить в течение длительного периода времени (например, корзина покупок Amazon), рекомендуется хранить эти данные в базе данных.

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

У этого подхода есть две проблемы:

Во-первых, сброс данных сеанса в базу данных сеанса является медленным процессом. Сброс данных сеанса слишком часто снижает производительность, и большинство серверов настроено на сброс каждые 30 секунд, каждую минуту или дольше. Это «кажущееся» решение по отказоустойчивости никогда не бывает эффективным на 100%

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

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

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

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

Краткий ответ «когда использовать сериализацию Java» и «когда избегать сериализации Java»

Использовать сериализацию Java, если

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

Во всех остальных ситуациях «двоичная Java-сериализация» плоха

альтернативы

• XML сериализация
• база данных nosql
• реляционная база данных с ORM