Серіалізація Java - переваги та недоліки, використовувати чи уникати? [зачинено]

Серіалізація використовується для збереження в Java. Можливо, буде добре зберігати кілька об'єктів за допомогою серіалізації. Але, для великої кількості об'єктів, ORM, база даних тощо може бути кращою. Здається, що серіалізація корисна лише для невеликих робочих місць. Можливо, я помиляюся. Тож скажіть, будь ласка, які переваги серіалізації перед несеріалізаційними методами? Коли його слід застосовувати і коли слід уникати?

Це питання мені прийшло в голову після перегляду статті DZone Is Obay Serialization Evil?

І ось рядки, які породили моє запитання:

Якщо ви подивитеся на Java та її об'єкти сеансу, використовується серіалізація чистого об'єкта. Якщо припустити, що сеанс програми досить короткочасний, тобто не більше кількох годин, серіалізація об'єктів проста, добре підтримується і вбудована в концепцію Java сеансу. Однак, коли збереження даних триває довший період часу, можливо, дні чи тижні, і вам доведеться турбуватися про нові випуски програми, серіалізація швидко стає злою. Як знає будь-який хороший розробник Java, якщо ви плануєте серіалізувати об’єкт навіть на сеансі, вам потрібен справжній ідентифікатор серіалізації (serialVersionUID), а не лише 1L, і вам потрібно реалізувати інтерфейс Serializable. Однак більшість розробників не знають реальних правил, що стоять за процесом деріаріалізації Java. Якщо ваш об’єкт змінився, більше ніж просто додати до об’єкта прості поля, можливо, Java не може деріаріалізувати об'єкт правильно, навіть якщо ідентифікатор серіалізації не змінився. Раптом ви більше не можете отримати свої дані, що по суті є поганим.

Тепер розробники, читаючи це, можуть сказати, що вони ніколи не напишуть код, який би мав цю проблему. Це може бути правдою, але як бути з бібліотекою, яку ви використовуєте, або іншим розробником, який більше не працює у вашій компанії? Чи можете ви гарантувати, що ця проблема ніколи не відбудеться? Єдиний спосіб гарантувати це - використовувати інший метод серіалізації.

Серіалізація в основному використовується у двох сферах:

• прототипування стійкості

  майже кожен графік об'єкта може бути швидко серіализирован, для швидкого підтвердження концепцій або швидких і брудних додатків це може бути швидше, ніж налаштування реального рівня ORM або іншої системи збереження

• короткочасне зберігання майже довільних об'єктів:

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

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

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

Я використовую об'єктну серіалізацію, щоб дозволити післясмертний аналіз у разі несподіваної помилки у виробництві. Вхідні дані для розрахунку серіалізуються у файл даних. Якщо повідомляється про помилку, проста програма може перезавантажити входи та повторно обчислити доданий відладчик. Або ж шліфувальну оболонку можна використовувати для перезавантаження об'єктів та їх модифікації за бажанням.

Ми також використовуємо серіалізацію для передачі об’єктів Java через HTTP у веб-сервіс. Набагато простіше, ніж серіалізація до та з тексту. Недоліком є ​​те, що клієнтські та серверні установки повинні бути розгорнуті разом, але це не проблема, оскільки ми контролюємо обидва цілі.

Які переваги серіалізації перед методами несеріалізації?

Серіалізація Java має деякі переваги:

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

• Відносно простий для розуміння , принаймні на початку.

• Кожен розробник знає це (або повинен). Незалежно від того, затверджують чи не схвалюють Java розробники, вони, ймовірно, знайомі з серіалізацією об’єктів Java.

І, звичайно, є недоліки:

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

• Не настільки ефективний з точки зору простору, але і не жахливий. Можливо, ви захочете стиснути результат.

• Крихкий, якщо ви не вживати заходів обережності, коли ваші об'єкти змінюються. І навіть тоді.

Коли його слід застосовувати і коли слід уникати?

Використовувати, коли :

• Розмір розміщення має значення. Вбудовано в систему, тому 0 зайвих байт.

• Усі актори використовуватимуть сумісні версії.

• Тривале зберігання не є проблемою.

Уникайте, коли :

• Будь-яке з перерахованого вище не поширюється.

Серіалізація та ORM / база даних - це різні речі, хоча є певне перекриття.

Серіалізований об'єкт представляє всю інформацію, необхідну для "відтавання" збереженого об'єкта та перенаселення його даних. ORM і база даних зберігають дані в базі даних. Клас може мати поля інформації, які ORM не зберігаються в базі даних, наприклад обчислені поля.

Крім того, серіалізація та ORM вирішують різні проблеми. Серіалізація вирішує проблему збереження графіка об'єкта в потоці (пам'ять, файлова система тощо). ORM обробляє відображення фрагментів інформації до стовпців бази даних та пошук та інстанціювання об'єктів, на додаток до надання зручностей, таких як пошук та ліниве завантаження.

Використовуйте ORM, коли ви хочете зберегти дані в базі даних у випадках, коли ви маєте справу з великою кількістю даних або потребуєте звітування, пошуку / запитів, складування або інших речей, в яких добре базуються бази даних. Використовуйте серіалізацію, коли ви хочете зберегти на диску представлення вашої структури даних.

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

Як вже було сказано, найпоширенішим випадком використання серіалізації є зберігання об'єктів у вигляді крапок у базі даних сесій. Це добре працює з двох причин: сеанси, як правило, недовговічні, а база даних сесій - як відсутні знання про те, як зіставити довільні об'єкти до реляційної моделі.

Для даних, які потрібно зберігати протягом тривалого періоду часу (наприклад, кошик Amazon), найкращою практикою є зберігання цих даних у базі даних.

Механізм стійкості сеансу забезпечує повернення користувача з активним сеансом на той же сервер. До бази даних сеансів доступно лише тоді, коли сервер не працює і користувач перенаправляється на новий сервер. Новий сервер виявляє активний сеанс, але не знаходить його в пам'яті, тому намагається отримати його з бази даних сесій, намагаючись надати користувачеві безперебійний досвід.

З цим підходом є дві проблеми:

По-перше, передача даних сесії в базу даних сесій - це повільний процес. Дані сеансу промивання занадто часто погіршують продуктивність, і більшість серверів налаштовано на флеш кожні 30 секунд або щохвилини чи довше. Це "не здавалося б" рішення відмови ніколи не є на 100% ефективним.

По-друге, мій досвід - більшість клієнтів погоджуються з тим, що передаючи повідомлення про помилку з проханням увійти в систему та спробувати знову під час рідкісних випадків, коли сервер не працює. У цьому випадку ми повністю вимикаємо базу даних сесій і отримуємо задоволення від підвищення продуктивності.

Іншим використанням серіалізації є забезпечення більш швидкого часу відгуку за допомогою фреймів типу Flex, які використовують серіалізацію та стиснення графіків об'єктів для взаємодії сервер-клієнт.

Як зазначали інші, є деякі творчі та корисні причини використовувати серіалізацію, але вони є рідкісними на практиці.

Історично серіалізацію складно здійснити правильно та надійно, обмеживши її використання лише невеликою кількістю випадків. Більшість розробників ніколи самі не серіалізують об'єкти, але можуть покладатися на рамки, які роблять це за кадром.

Коротка відповідь на "коли використовувати серіалізацію Java" та "коли уникати серіалізації Java"

Використовуйте серіалізацію Java, якщо

• мало кодування
• не має значення, що двійкові дані не читаються людиною
• пошук в серіалізованих даних не потрібен (запит у вигляді бази даних неможливий)
• або
  • структура серіалізованих даних не змінюється або
  • не має значення, якщо збережені серіалізовані дані вже не читаються після "зміни структури даних" (тобто дані сеансу у веб-додатку)

У всіх інших ситуаціях «Двійкова серіалізація Java» погана

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

• xml серіалізація
• nosql бази даних
• реляційна база даних з ORM