Критерии выбора формата сериализации

Производительность
Производительность измеряется по трём метрикам: скорость сериализации (объект → байты), скорость десериализации (байты → объект) и размер полученного сообщения.
Java Native Serialization медленна из-за рефлексии и записи метаданных класса для каждого объекта. Protobuf и Kryo в 10–100 раз быстрее. JSON медленнее бинарных форматов из-за парсинга текста и boxing'а чисел.

Boxing — это автоматическая упаковка примитивных типов в объектные обёртки. В JSON число 42 парсится как строка, затем преобразуется в int, что требует дополнительных операций по сравнению с прямым чтением 4 байт из бинарного потока.

Читаемость
Текстовые форматы (JSON, XML, YAML) человекочитаемы, что упрощает отладку, логирование и ручное тестирование API. Бинарные форматы требуют специальных инструментов (hex-редакторов, декодеров protobuf) для анализа. В production-системах читаемость часто жертвуется ради производительности, но для конфигураций, API-спецификаций и логов предпочтительны текстовые форматы.

Версионность (эволюция схем)
Версионность — способность формата адаптироваться к изменениям структуры данных без поломки существующих клиентов и серверов.
Java Native Serialization требует ручного управления serialVersionUID и ломается при изменении сигнатуры класса (удаление/переименование полей, изменение типов). Protobuf поддерживает добавление полей (старые клиенты игнорируют неизвестные теги), удаление полей (если они не обязательны), изменение типов в рамках wire-совместимости. Avro поддерживает схемы чтения и записи разных версий с автоматическим разрешением различий.

Wire-совместимость (wire compatibility) — это свойство формата, при котором изменение схемы не нарушает формат бинарного потока. Например, в protobuf изменение int32 на int64 wire-совместимо, так как оба типа кодируются как varint, но семантически может привести к truncation на старых клиентах.

Безопасность
Безопасность — критичнейший критерий, особенно для десериализации данных из недоверенных источников.
Java Native Serialization имеет печальную репутацию: десериализация ObjectInputStream.readObject() может выполнить произвольный код, если в classpath есть классы с уязвимыми конструкторами, методами readObject() или ObjectInputValidation. Это привело к множеству критических CVE (Common Vulnerabilities and Exposures). Начиная с Java 9, добавлен механизм JEP 290 — фильтрация входящих классов через ObjectInputFilter.

CVE (Common Vulnerabilities and Exposures) — это стандартизированный каталог публично известных уязвимостей информационной безопасности. Каждой уязвимости присваивается уникальный идентификатор, например CVE-2015-4852 (уязвимость десериализации в Oracle WebLogic).

// JEP 290: фильтрация десериализации с Java 9
public void safeDeserialize(InputStream in) throws IOException, ClassNotFoundException {
    ObjectInputStream ois = new ObjectInputStream(in);
    
    // Разрешаем десериализовать только классы из доверенных пакетов
    ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
        "maxdepth=5;maxrefs=10000;com.myapp.*;!*"
    );
    ois.setObjectInputFilter(filter);
    
    Object obj = ois.readObject();
}

ObjectInputFilter — интерфейс, введённый в Java 9 (JEP 290), позволяющий задавать белые и чёрные списки классов для десериализации, ограничивать глубину графа объектов, количество ссылок и размер данных.
JSON безопаснее, так как парсер создаёт только простые структуры (строки, числа, массивы, объекты), не вызывая произвольных конструкторов Java. Однако и JSON имеет уязвимости: XXE (XML External Entity) при использовании небезопасных XML-парсеров, или DOS-атаки через Billion Laughs в YAML/XML.

XXE (XML External Entity) — тип атаки на XML-парсеры, при котором злоумышленник внедряет внешнюю сущность в XML-документ, заставляя парсер обращаться к внутренним файлам сервера или внешним ресурсам.
Protobuf и Avro безопасны по дизайну: они не поддерживают произвольную загрузку классов, работают только со схемой, строго типизированы и не позволяют встроить исполняемый код в сообщение.
Кроссплатформенность

Если система полиглотная (использует несколько языков программирования), Java Native Serialization и Kryo неприменимы — они привязаны к JVM. JSON, XML, protobuf, Avro, FlatBuffers имеют реализации на десятках языков и являются lingua franca для межсервисного взаимодействия.

Полиглотная система (polyglot system) — это система, построенная с использованием нескольких языков программирования. Например, backend на Java/Go, ML-сервис на Python, frontend на JavaScript. В таких системах формат обмена данных должен быть языконезависимым.


Размер данных
Бинарные форматы значительно компактнее текстовых. Например, объект с тремя полями в JSON может занимать 100 байт из-за повторяющихся ключей и скобок. Тот же объект в protobuf — 10–20 байт. Это критично для мобильных приложений, IoT-устройств и высоконагруженных сетевых протоколов.


#Java #для_новичков #beginner #IO #NIO #Serialize

Путь байтов в памяти JVM при сериализации

Сериализация: от объекта к байтам
Когда вы вызываете ObjectOutputStream.writeObject(user):
Объект в куче. Объект user и все объекты, на которые он ссылается (глубокий граф), находятся в куче (Heap). ObjectOutputStream обходит граф, начиная с корневого объекта. Для каждого объекта он записывает:
Дескриптор класса (полное имя класса, serialVersionUID, флаги)
Типы и значения полей (примитивы записываются как есть, объекты — рекурсивно)
Для каждого нового класса в иерархии — его дескриптор
Обход графа и отслеживание ссылок. ObjectOutputStream поддерживает таблицу handle — целочисленных идентификаторов для уже записанных объектов. Если в графе есть циклические ссылки (A ссылается на B, B ссылается на A) или повторяющиеся ссылки, второе вхождение объекта записывается не полностью, а как backreference (handle ранее записанного объекта). Это предотвращает бесконечную рекурсию и дублирование.
Буферизация. ObjectOutputStream пишет данные во внутренний буфер byte[] (обычно 512 байт или больше). Этот буфер создаётся в Young Generation, в Eden. Когда буфер заполняется, он сбрасывается (flush) в нижележащий поток: ByteArrayOutputStream, FileOutputStream или SocketOutputStream.
ByteArrayOutputStream. Если сериализация идёт в память, ByteArrayOutputStream накапливает байты в динамически расширяющемся массиве. При превышении ёмкости создаётся новый массив вдвое большего размера, данные копируются, старый массив становится мусором. Это может породить несколько временных массивов в Young Generation, которые собираются Minor GC.
Возвращаемый массив. baos.toByteArray() создаёт новый массив точного размера и копирует в него данные. Исходный внутренний буфер ByteArrayOutputStream остаётся в куче до сборки мусора. Итоговый массив байтов — это объект в куче, который может быть передан по сети, сохранён в файл или закэширован.
Работа GC. Все временные объекты — внутренние буферы ObjectOutputStream, промежуточные массивы ByteArrayOutputStream, объекты ObjectStreamClass (метаданные классов) — создаются в Young Generation. При короткой сериализации они уничтожаются при следующей Minor GC. Если сериализация выполняется в цикле (например, сериализация 10 000 объектов для пакетной отправки), буферы могут пережить несколько циклов Minor GC и мигрировать в Survivor Space, а затем в Old Generation.
ObjectStreamClass — это внутренний класс JVM, представляющий метаданные сериализуемого класса: имя, serialVersionUID, поля, методы writeObject/readObject. Эти объекты кэшируются внутри ObjectOutputStream для повторного использования, но при сериализации множества разных классов они накапливаются.


Десериализация: от байтов к объекту

При ObjectInputStream.readObject():
Байты в куче. Исходный массив байтов или поток находится в куче (если это ByteArrayInputStream) или читается из нативного буфера (если это FileInputStream или SocketInputStream).
Чтение дескрипторов. ObjectInputStream читает заголовок потока (magic number, версия протокола), затем дескриптор класса. Он ищет класс в Metaspace через Class.forName(). Если класс не загружен, ClassLoader загружает его байткод в Metaspace.
Создание объекта без конструктора. JVM выделяет память под объект в Young Generation (Eden) через механизм sun.misc.Unsafe.allocateInstance() (или аналог в новых версиях). Это выделение памяти без вызова конструктора — объект создаётся "сырым", с полями в состоянии по умолчанию (null, 0, false).
Заполнение полей. ObjectInputStream читает значения полей из потока и записывает их напрямую в память объекта (через JNI или Unsafe). Для объектных полей — рекурсивная десериализация. Для transient-полей — значение не читается, остаётся по умолчанию.
Восстановление графа. Если в потоке есть backreference (ссылка на ранее десериализованный объект), ObjectInputStream подставляет ссылку на существующий объект из таблицы handles. Это восстанавливает точную топологию исходного графа, включая циклы.
Вызов readObject(). Если класс реализует private void readObject(ObjectInputStream in), JVM вызывает этот метод после заполнения полей. Это позволяет выполнить пост-инициализацию: восстановить transient-поля, вычислить производные значения, проверить инварианты.
Работа GC. Вновь созданные объекты размещаются в Eden. Если десериализуемый граф большой (миллионы объектов), они могут быстро заполнить Young Generation и вызвать Minor GC в процессе десериализации. Если объекты сохраняются в долгоживущую структуру (коллекцию, кэш), они переходят в Old Generation.


Потоковая сериализация и GC

При сериализации в FileOutputStream или SocketOutputStream:
Буфер ObjectOutputStream (в куче) периодически сбрасывается. Сброс вызывает системный вызов write() (POSIX), который копирует байты из кучи JVM в нативную память ядра (кэш страниц или сетевой буфер).
Буфер в куче переиспользуется — новые объекты не создаются при каждом сбросе. Это снижает давление на GC.
Если сериализация выполняется в цикле с высокой частотой (например, в RPC-сервере, обрабатывающем 10 000 запросов в секунду), объекты ObjectOutputStream и ObjectInputStream создаются и закрываются для каждого запроса. Каждый такой объект — это десятки килобайт в куче. При интенсивной нагрузке они быстро заполняют Eden и вызывают частые Minor GC.

Оптимизация: пул переиспользуемых потоков. В высоконагруженных системах ObjectOutputStream создаётся один раз и сбрасывается через reset() между запросами. Метод reset() очищает внутренние таблицы handles, позволяя сериализовать новый граф объектов без создания нового потока.

public class PooledSerializer {
    private final ByteArrayOutputStream baos = new ByteArrayOutputStream(8192);
    private final ObjectOutputStream oos;
    
    public PooledSerializer() throws IOException {
        this.oos = new ObjectOutputStream(baos);
    }
    
    public synchronized byte[] serialize(Object obj) throws IOException {
        baos.reset();  // сбрасываем буфер, не создавая новый
        oos.reset();   // сбрасываем таблицу handles
        oos.writeObject(obj);
        oos.flush();
        return baos.toByteArray();  // копирует текущий буфер
    }
}

В этом примере baos.reset() очищает счётчик байтов, но не освобождает внутренний массив. oos.reset() очищает таблицу handles, позволяя сериализовать новые объекты без утечки памяти. Это существенно снижает давление на GC в сценариях с высокой частотой сериализации.


#Java #для_новичков #beginner #IO #NIO #Serialize

Раздел 11. Работа с файлами, I/O и сетью (NIO.2)

Глава 3. Сериализация и форматы обмена

Нативная сериализация Java: интерфейс Serializable

Интерфейс java.io.Serializable — это центральный элемент механизма нативной сериализации Java, существующий с версии JDK 1.1.
Он не требует реализации методов, не содержит констант и не накладывает контрактов на поведение класса. Его единственное назначение — сигнализировать JVM и стандартной библиотеке, что экземпляры данного класса разрешено преобразовывать в поток байтов и восстанавливать из него.
Этот механизм глубоко интегрирован в JVM: он обходит граф объектов, записывает метаданные классов, управляет версионностью и обеспечивает восстановление ссылочной целостности. Однако за простотой использования скрывается сложная внутренняя архитектура, множество подводных камней и серьёзные ограничения, которые делают нативную сериализацию устаревшим выбором для новых систем.


Маркерный интерфейс Serializable

Serializable — это маркерный интерфейс (marker interface). В отличие от обычных интерфейсов, он не объявляет ни одного метода. Его роль чисто декларативная: наличие implements Serializable в объявлении класса изменяет поведение JVM при обработке этого класса механизмом сериализации.

import java.io.Serializable;

public class Document implements Serializable {
    // Маркерный интерфейс не требует методов
    private String title;
    private String content;
}

Маркерный интерфейс — это интерфейс в Java без методов и полей, служащий метаданным для компилятора или runtime. Cloneable, Serializable, RandomAccess — примеры таких интерфейсов. Они не влияют на структуру класса напрямую, но изменяют поведение встроенных механизмов JVM. В современной Java роль маркерных интерфейсов частично вытесняется аннотациями (например, @Entity в JPA), но Serializable остаётся неизменным с 1997 года по причинам обратной совместимости.

Аннотация (annotation) — это форма метаданных в Java, введённая в Java 5, которая предоставляет данные о программе, не являющиеся частью самой программы. Аннотации не влияют непосредственно на операции кода, но могут обрабатываться компилятором, инструментами или во время выполнения через рефлексию.

При попытке сериализовать объект, класс которого не реализует Serializable, ObjectOutputStream.writeObject() выбросит NotSerializableException. Это проверка выполняется рекурсивно: если класс реализует Serializable, но одно из его полей — объект класса без Serializable, исключение возникнет при попытке записать это поле.

public class Container implements Serializable {
    private Document doc;  // Document должен быть Serializable
    private Metadata meta; // Metadata тоже должен быть Serializable
}

Если Metadata не реализует Serializable, сериализация Container завершится NotSerializableException на этапе обхода поля meta. Это ограничение каскадируется по всему графу объектов: каждый объект, достижимый от корневого, должен быть сериализуемым, либо должен быть помечен как transient.


#Java #для_новичков #beginner #IO #NIO #Serialize #Serializable

Что сериализуется и что нет

Сериализуемое состояние
Механизм нативной сериализации записывает состояние экземпляра объекта — значения всех полей экземпляра, за исключением тех, что явно исключены. Это включает:
Поля всех уровней доступности: public, protected, package-private и private. Сериализация обходит модификаторы доступа через механизм reflection или нативный доступ JNI, поэтому приватные поля сохраняются и восстанавливаются без геттеров и сеттеров.

Поля примитивных типов: их значения записываются в бинарном виде.

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

public class Library implements Serializable {
    private String name;
    private List<Book> books;  // Book тоже должен быть Serializable
    private Librarian head;    // Librarian тоже должен быть Serializable
}

При сериализации Library механизм рекурсивно обойдёт список books: каждый элемент Book будет сериализован со своими полями, включая ссылки на Author, Publisher и т.д. Затем будет сериализован head (Librarian) со всеми его полями. Результат — глубокая копия всего графа объектов в виде потока байтов.

Глубокая копия (deep copy) — это копия объекта, при которой копируются не только сам объект, но и все объекты, на которые он ссылается, рекурсивно. В отличие от поверхностной копии (shallow copy), где копируются только ссылки на те же внутренние объекты.

Что не сериализуется

Статические поля не сериализуются. Они принадлежат классу, а не экземпляру, и их значения хранятся в Metaspace (в структурах класса), а не в куче вместе с объектом. При десериализации статические поля получают текущие значения, определённые в загруженном классе, а не значения из потока.

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

public class Config implements Serializable {
    private static String globalPrefix = "app";  // не сериализуется
    private String instanceName;                  // сериализуется
}

Transient-поля явно исключаются из сериализации. Ключевое слово transient указывает механизму, что поле не должно быть записано в поток. При десериализации такое поле получает значение по умолчанию: null для ссылочных типов, 0 для чисел, false для boolean.

public class UserSession implements Serializable {
    private String username;
    private transient String password;      // не сериализуется
    private transient Connection dbConn;    // не сериализуется
    private transient byte[] cachedToken;   // не сериализуется
}

transient используется для чувствительных данных (пароли, ключи), ресурсов, привязанных к runtime (соединения с БД, потоки, сокеты), и вычисляемых/кэшированных значений, которые можно восстановить после загрузки.
Важно: transient не влияет на видимость поля — оно остаётся приватным или публичным, просто исключается из сериализационного протокола.

Поля-суперклассы
Если класс реализует Serializable, а его суперкласс — нет, то поля суперкласса не сериализуются. При десериализации суперкласс инициализируется через свой no-arg конструктор (конструктор без аргументов). Если такого конструктора нет — InvalidClassException.

public class Base {  // не Serializable
    private int baseField;
    public Base() {}  // обязателен no-arg конструктор
}

public class Derived extends Base implements Serializable {
    private int derivedField;  // только это поле сериализуется
}

При десериализации Derived поле baseField не восстанавливается из потока. Вместо этого вызывается Base(), и baseField получает значение по умолчанию (0), независимо от того, каким оно было при сериализации. Это частый источник багов: разработчик забывает, что суперкласс не serializable, и удивляется, почему поля предка обнуляются.

No-arg конструктор (no-argument constructor, default constructor) — это конструктор без параметров. В Java, если класс не объявляет явных конструкторов, компилятор генерирует no-arg конструктор автоматически. Если объявлен хотя бы один конструктор с параметрами, no-arg конструктор нужно объявлять явно.

Механизм обхода графа объектов

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

Отслеживание ссылок и циклы

Ключевая особенность: каждый объект в графе записывается ровно один раз. Для этого ObjectOutputStream поддерживает внутреннюю таблицу handles — отображение от сериализованного объекта к целочисленному идентификатору (int). При первой встрече объекта:
Объект записывается полностью (дескриптор класса + поля).
Объекту присваивается handle — следующее свободное целое число.
Handle сохраняется в таблице.
При повторной встрече того же объекта (через другую ссылку или в цикле):
В поток записывается маркер backreference (TC_REFERENCE) + handle ранее записанного объекта.
Полная сериализация не выполняется.

public class Node implements Serializable {
    private String name;
    private Node next;  // может образовать цикл
}

// Создаём цикл: A -> B -> C -> A
Node a = new Node("A");
Node b = new Node("B");
Node c = new Node("C");
a.next = b;
b.next = c;
c.next = a;  // цикл!

// Сериализация не зацикливается благодаря таблице handles
oos.writeObject(a);  // записывает A, B, C, затем backreference на A

Этот механизм предотвращает бесконечную рекурсию при циклических ссылках и гарантирует, что после десериализации топология графа сохранится: c.next будет ссылаться на тот же объект a, что и корневой указатель. Без handles граф с циклами привёл бы к StackOverflowError при сериализации.
Handle (в контексте сериализации Java) — это целочисленный идентификатор, присваиваемый каждому уникальному объекту в потоке сериализации. Handles начинаются с базового значения (обычно baseWireHandle = 0x7E0000) и инкрементируются. Они используются для кодирования backreferences.


#Java #для_новичков #beginner #IO #NIO #Serialize

serialVersionUID: идентификатор версии класса

Что такое serialVersionUID

serialVersionUID — это статическое поле типа long, которое выступает уникальным идентификатором версии класса для механизма сериализации. При сериализации JVM записывает serialVersionUID класса в поток.
При десериализации она сравнивает serialVersionUID из потока с serialVersionUID загруженного класса. Если значения не совпадают — InvalidClassException.

public class Document implements Serializable {
    private static final long serialVersionUID = 1L;
    private String title;
}

Этот механизм защищает от десериализации объектов, сериализованных несовместимой версией класса. Например, если класс Document v1 имел поля title и author, а в v2 поле author было удалено и добавлено content, десериализация v1-объекта в v2-класс без контроля версий привела бы к повреждению данных или ClassCastException.


Генерация по умолчанию

Если класс не объявляет serialVersionUID явно, JVM вычисляет его автоматически на основе структуры класса. Алгоритм генерации (документирован в спецификации Java Object Serialization) учитывает:
Имя класса.
Модификаторы класса (public, final, abstract, interface).
Имена интерфейсов, которые реализует класс.
Имена полей, их модификаторы, типы.
Имена методов, их модификаторы, сигнатуры (возвращаемый тип, параметры).
Имена конструкторов, их сигнатуры.
Имена и сигнатуры методов writeObject, readObject, writeReplace, readResolve.
Имена статических полей (кроме serialVersionUID itself).
Этот хеш вычисляется через алгоритм, похожий на Secure Hash Algorithm (SHA), но упрощённый. Результат — 64-битное целое число long.

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

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

// Версия 1
public class User implements Serializable {
    private String name;
    private int age;
}

// Версия 2 — добавлен метод, serialVersionUID изменился!
public class User implements Serializable {
    private String name;
    private int age;
    
    public void greet() {  // новый метод изменяет вычисленный UID
        System.out.println("Hello");
    }
}

Если объект User был сериализован версией 1, а десериализуется версией 2, JVM вычислит новый serialVersionUID для загруженного класса, сравнит с UID из потока, обнаружит несоответствие и выбросит:

java.io.InvalidClassException: User; local class incompatible:
stream classdesc serialVersionUID = -123456789, 
local class serialVersionUID = 987654321

Это происходит даже если изменение семантически совместимо: добавление метода не влияет на состояние объекта, но меняет вычисленный хеш.

Решение: явное объявление
Рекомендуется всегда объявлять serialVersionUID явно:

public class User implements Serializable {
    private static final long serialVersionUID = 1L;
    private String name;
    private int age;
}

При явном объявлении JVM не вычисляет UID динамически, а использует указанное значение. Теперь добавление методов, изменение порядка полей, рефакторинг внутренней структуры не влияет на совместимость сериализации — до тех пор, пока изменения совместимы с форматом потока.
Как выбрать начальное значение? Традиционно используется 1L. Если позже потребуется несовместимое изменение, значение увеличивают: 2L, 3L и т.д. Некоторые команды используют timestamp или хеш от начальной структуры класса, но на практике последовательные номера проще в управлении.


Когда менять serialVersionUID

serialVersionUID следует изменять (инкрементировать) при несовместимых изменениях структуры класса.

Несовместимые изменения включают:
Удаление полей.
Изменение типа поля (например, int → String).
Изменение модификаторов класса с Serializable на несериализуемый.
Перемещение класса в другой пакет (имя класса входит в поток).
Изменение порядка полей суперкласса (влияет на порядок в потоке).
Изменение класса с enum на обычный или наоборот.


Совместимые изменения

При явном serialVersionUID можно вносить изменения, не ломающие десериализацию старых объектов:
Добавление полей: новые поля в потоке отсутствуют, поэтому при десериализации они получают значения по умолчанию (null, 0, false). JVM использует ObjectInputStream.defaultReadObject(), который читает из потока только те поля, которые есть в текущем классе, игнорируя лишние данные в потоке.
Добавление классов в иерархию: если добавить новый суперкласс, который сам реализует Serializable, старые объекты десериализуются корректно — новые поля суперкласса получат значения по умолчанию.
Удаление классов из иерархии: если удалить сериализуемый суперкласс, поля этого суперкласса в потоке игнорируются.
Добавление/удаление методов writeObject/readObject: не влияет на serialVersionUID при явном объявлении.
Изменение модификатора доступа поля: не влияет, так как сериализация обходит модификаторы.
Пометка поля как transient: поле перестаёт читаться из потока, получает значение по умолчанию.

// Версия 1
public class User implements Serializable {
    private static final long serialVersionUID = 1L;
    private String name;
}

// Версия 2 — совместимое изменение: добавлено поле
public class User implements Serializable {
    private static final long serialVersionUID = 1L;  // тот же UID!
    private String name;
    private String email;  // новое поле, старые объекты получат null
}

При десериализации объекта версии 1 в класс версии 2 поле email получит null. Это безопасно, но требует, чтобы код класса корректно обрабатывал null (например, через инициализацию в readObject() или ленивую инициализацию в геттере).

Обратная совместимость: новый объект в старый класс
Если объект сериализован версией 2 (с полем email), а десериализуется классом версии 1 (без email), JVM прочитает из потока поле email, но не найдёт соответствующего поля в классе. В этом случае данные поля сохраняются во внутренней структуре ObjectInputStream как no-data или skipped fields, но не восстанавливаются. Это не вызывает исключения, но данные теряются.


#Java #для_новичков #beginner #IO #NIO #Serialize

Расширенный контроль: writeObject, readObject, readResolve

writeObject и readObject
Класс может переопределить поведение сериализации, объявив приватные методы:

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

JVM вызывает эти методы через рефлексию, если они объявлены. Метод writeObject вызывается после записи дескриптора класса, но перед записью полей. Внутри него можно выполнить out.defaultWriteObject() (записать стандартные поля) и затем дописать произвольные данные.

public class SecureDocument implements Serializable {
    private static final long serialVersionUID = 1L;
    private String title;
    private transient String secretContent;  // не сериализуем напрямую
    
    private void writeObject(ObjectOutputStream out) throws IOException {
        out.defaultWriteObject();  // записываем title и другие нетранзиентные поля
        // Шифруем секретный контент перед записью
        String encrypted = encrypt(secretContent);
        out.writeUTF(encrypted);
    }
    
    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        in.defaultReadObject();  // читаем title
        // Дешифруем секретный контент
        String encrypted = in.readUTF();
        this.secretContent = decrypt(encrypted);
    }
    
    private String encrypt(String data) { /* ... */ return data; }
    private String decrypt(String data) { /* ... */ return data; }
}

Этот паттерн позволяет сериализовать transient-поля в зашифрованном виде, выполнять валидацию инвариантов, восстанавливать производные структуры.

readResolve
Метод readResolve вызывается после полной десериализации объекта и позволяет заменить десериализованный экземпляр на другой объект. Это критично для реализации singleton и enum-like паттернов.

Singleton — это порождающий паттерн проектирования, гарантирующий, что класс имеет только один экземпляр, и предоставляющий глобальную точку доступа к нему. При десериализации singleton механизм создаёт новый объект, нарушая гарантию единственности. readResolve возвращает существующий экземпляр.

public class Singleton implements Serializable {
    private static final long serialVersionUID = 1L;
    private static final Singleton INSTANCE = new Singleton();
    
    private Singleton() {}
    
    public static Singleton getInstance() {
        return INSTANCE;
    }
    
    // При десериализации возвращаем существующий INSTANCE, а не новый объект
    private Object readResolve() {
        return INSTANCE;
    }
}

Без readResolve десериализация Singleton создала бы новый объект в куче, и getInstance() вернул бы старый INSTANCE, в то время как десериализованный объект — отдельная сущность. readResolve гарантирует, что любая десериализация вернёт канонический экземпляр.

writeReplace
Аналогично, writeReplace вызывается перед сериализацией и позволяет заменить объект на другой перед записью в поток. Используется для прокси-сериализации (serialization proxy pattern), когда внутреннее представление объекта не должно попадать в поток.

Прокси-сериализация (serialization proxy pattern) — это паттерн, при котором вместо самого объекта сериализуется лёгкий прокси-объект (proxy), содержащий только необходимые данные, а при десериализации прокси через readResolve восстанавливает оригинальный объект через его конструктор или фабрику. Это защищает инварианты, предотвращает создание "сырых" объектов и позволяет менять внутреннюю структуру класса, не ломая совместимость.

public class ComplexObject implements Serializable {
    private static final long serialVersionUID = 1L;
    private final int x;
    private final int y;
    // инвариант: x >= 0 && y >= 0
    
    public ComplexObject(int x, int y) {
        if (x < 0 || y < 0) throw new IllegalArgumentException();
        this.x = x;
        this.y = y;
    }
    
    // Вместо себя сериализуем прокси
    private Object writeReplace() {
        return new SerializationProxy(x, y);
    }
    
    // Запрещаем десериализацию ComplexObject напрямую
    private void readObject(ObjectInputStream in) throws InvalidObjectException {
        throw new InvalidObjectException("Proxy required");
    }
    
    private static class SerializationProxy implements Serializable {
        private static final long serialVersionUID = 1L;
        private final int x;
        private final int y;
        
        SerializationProxy(int x, int y) {
            this.x = x;
            this.y = y;
        }
        
        // При десериализации прокси восстанавливаем ComplexObject через конструктор
        private Object readResolve() {
            return new ComplexObject(x, y);  // инвариант проверяется!
        }
    }
}

Этот паттерн рекомендуется Джошуа Блохом (Joshua Bloch) в "Effective Java" как предпочтительный способ сериализации сложных объектов


#Java #для_новичков #beginner #IO #NIO #Serialize

Раздел 11. Работа с файлами, I/O и сетью (NIO.2)

Глава 3. Сериализация и форматы обмена

JSON — современный стандарт обмена данными

JSON (JavaScript Object Notation) — это текстовый формат сериализации данных, изначально выведенный из синтаксиса литералов объектов языка JavaScript. Несмотря на происхождение, JSON является полностью языконезависимым форматом и определён стандартом RFC 8259 (декабрь 2017), который заменил RFC 7159. Сегодня JSON де-факто является стандартным форматом обмена данными в веб-сервисах, конфигурационных файлах, логах, сообщениях брокеров и хранилищах документов.

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

RFC (Request for Comments) — серия документов Интернет-инженерного совета (IETF), описывающих стандарты, протоколы и технологии Интернета. RFC 8259 является официальной спецификацией формата JSON.

Что такое JSON

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

Формат спроектирован так, чтобы быть легко читаемым для человека и легко парсящимся для машины. Это достигается за счёт минималистичного синтаксиса и строгих правил: каждый документ JSON — это либо один объект, либо один массив.

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

JSON как основа REST API

REST (Representational State Transfer) — это архитектурный стиль проектирования распределённых систем, введённый Роем Филдингом в его докторской диссертации 2000 года. REST не является протоколом или стандартом в строгом смысле; это набор ограничений и принципов.

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

JSON стал доминирующим форматом представления ресурсов в REST API благодаря нескольким факторам:
Нативная поддержка в JavaScript, который исполняется в браузере клиента.
Простота генерации и парсинга на стороне сервера — любой язык имеет библиотеку для работы с JSON.
Читаемость при отладке — в отличие от бинарных форматов, JSON можно просмотреть в инструментах разработчика браузера или в логах.
Отсутствие необходимости в схеме для базового использования — в отличие от XML, JSON не требует DTD или XSD для валидации.

DTD (Document Type Definition) и XSD (XML Schema Definition) — это механизмы определения структуры и допустимых элементов XML-документа. JSON изначально не имел встроенного механизма схем, хотя позже появились JSON Schema и OpenAPI.

#Java #для_новичков #beginner #IO #NIO #Serialize #JSON

Структура JSON

Спецификация JSON определяет шесть типов значений:

Объекты
Объект — это неупорядоченный набор пар ключ-значение, заключённый в фигурные скобки. Ключ — это строка, значение — любой допустимый JSON-тип. Пары разделяются запятыми.

{
  "user": {
    "id": 42,
    "name": "Alice",
    "active": true
  }
}

В Java объект JSON обычно маппится на Map<String, Object> или на POJO (Plain Old Java Object — простой Java-объект без специальных требований к наследованию или аннотациям). Ключи в объекте JSON уникальны в пределах одного объекта, но спецификация не запрещает дубликаты — поведение при дубликатах зависит от парсера. Большинство парсеров используют последнее встреченное значение.

Массивы
Массив — это упорядоченная последовательность значений, заключённая в квадратные скобки. Значения разделяются запятыми. Индексация начинается с нуля.

{
  "orders": [
    { "id": 1, "total": 99.99 },
    { "id": 2, "total": 150.00 }
  ]
}

В Java массив JSON маппится на List<Object>, Object[] или типизированный список List<Order>, если используется библиотека с поддержкой дженериков.

Строки
Строка — это последовательность из нуля или более символов Unicode, заключённая в двойные кавычки. JSON поддерживает escape-последовательности: \n (перевод строки), \t (табуляция), \\ (обратный слеш), \" (кавычка), \uXXXX (символ Unicode в шестнадцатеричном виде).

{
  "description": "Line 1\nLine 2\tTabbed",
  "emoji": "\uD83D\uDE00"
}

Строки в JSON кодируются в UTF-8, UTF-16 или UTF-32. На практике UTF-8 доминирует, так как обеспечивает обратную совместимость с ASCII и экономит память для латинских текстов.

UTF-8 (Unicode Transformation Format, 8-bit) — это кодировка переменной длины, которая кодирует символы Unicode от 1 до 4 байтами. Символы ASCII (0–127) занимают 1 байт, что делает UTF-8 эффективной для англоязычных текстов.

Числа
Числа в JSON записываются в десятичной системе и могут быть целыми или с плавающей точкой. Поддерживается экспоненциальная нотация. Нет различия между целыми и вещественными числами на уровне синтаксиса — это одна грамматическая категория.

{
  "integer": 42,
  "negative": -17,
  "float": 3.14159,
  "exponential": 6.022e23,
  "small": 1e-10
}

Спецификация JSON не ограничивает точность или диапазон чисел. Однако на практике числа с плавающей точкой часто интерпретируются как IEEE 754 double-precision (64 бита), что даёт точность около 15–17 значащих цифр. Для финансовых расчётов, где критична точность до копеек, это может привести к ошибкам округления. В таких случаях числа передаются как строки.

IEEE 754 — это стандарт представления чисел с плавающей точкой в компьютерах. Double-precision использует 64 бита: 1 бит знака, 11 бит экспоненты и 52 бита мантиссы. Не все десятичные дроби точно представимы в двоичной системе, отсюда ошибки округления.

Булевы значения
Два литерала: true и false. В Java маппятся на примитив boolean или объект Boolean.

{
  "enabled": true,
  "debug": false
}

Null
Литерал null представляет отсутствие значения. В Java маппится на null.

{
  "middleName": null
}

Преимущества JSON

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

Универсальная поддержка
Каждый современный язык программирования имеет библиотеку для работы с JSON. В Java экосистеме существуют Jackson, Gson, JSON-B, JSON-P, org.json и многие другие. В JavaScript JSON — нативный формат. В Python — модуль json в стандартной библиотеке. В Go — пакет encoding/json. Это означает, что сервис на Java может бесшовно обмениваться данными с сервисом на Python, Go или Node.js.

Простота
Грамматика JSON минимальна: всего два контейнерных типа и четыре скалярных. Нет пространств имён, нет схем, нет атрибутов, нет комментариев (официально — комментарии не поддерживаются, хотя некоторые парсеры их принимают). Эта простота снижает сложность парсеров и уменьшает вероятность ошибок при сериализации.
Интеграция с веб-стеком
JSON родственен JavaScript, что делает его естественным выбором для веб-приложений. Fetch API, XMLHttpRequest, WebSocket — все эти API работают с JSON напрямую. Браузер предоставляет нативный объект JSON с методами parse() и stringify().


Недостатки JSON

Размер и текстовая природа
JSON — текстовый формат. Каждое число, булево значение или null записывается символами, а не бинарными данными. Ключи объектов повторяются в каждом документе. Для массовых данных это приводит к значительному overhead.

{
  "users": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ]
}

В этом примере ключи "id" и "name" повторяются для каждого элемента. В бинарном формате (например, Protocol Buffers) ключи заменяются числовыми тегами, а строковые значения могут быть закодированы более эффективно. JSON также не поддерживает сжатие на уровне формата — для уменьшения размера применяется внешнее сжатие (gzip, brotli).

Protocol Buffers (protobuf) — бинарный формат сериализации, разработанный Google. В отличие от JSON, protobuf требует предварительного определения схемы (proto-файл), но обеспечивает компактное бинарное представление и строгую типизацию.

Отсутствие строгой типизации
JSON не имеет схемы встроенной в сам документ. Поле "age" может содержать число в одном запросе и строку в другом. Это создаёт риск ошибок при десериализации, если клиент и сервер не согласовали контракт. Для решения этой проблемы используются JSON Schema, OpenAPI/Swagger или кодогенерация по proto-файлам.

JSON Schema — это спецификация (draft 2020-12) для описания структуры JSON-документов. Она позволяет определять типы полей, обязательность, диапазоны значений, регулярные выражения для строк и другие ограничения.

Отсутствие поддержки бинарных данных
JSON не имеет встроенного типа для бинарных данных. Для передачи бинарного контента (изображения, PDF, аудио) используется кодирование в Base64, что увеличивает размер данных примерно на 33%. Альтернативы — передача бинарных данных отдельно (multipart/form-data) или использование бинарных форматов.

Base64 — это схема кодирования бинарных данных в текстовый формат с использованием 64 символов ASCII (A–Z, a–z, 0–9, +, /). Каждые 3 байта (24 бита) кодируются 4 символами Base64 (по 6 бит каждый), отсюда overhead в 33%.

Отсутствие комментариев
Спецификация JSON явно запрещает комментарии. Это создаёт проблемы для конфигурационных файлов, где комментарии полезны для документирования. Решения: использование JSON5 (расширение JSON с комментариями), YAML или TOML для конфигурации, либо отдельные файлы документации.

Производительность парсинга
Парсинг JSON требует посимвольного разбора строки, построения дерева объектов в памяти и часто — рефлексии для маппинга на Java-объекты. Для высоконагруженных систем это может стать bottleneck. Оптимизации включают потоковый парсинг (Jackson Streaming API), бинарные форматы на основе JSON (BSON, MessagePack) или полный отказ от JSON в пользу protobuf/Avro.

Bottleneck — это узкое место в системе, которое ограничивает общую производительность. В контексте JSON-парсинга bottleneck часто возникает из-за аллокации объектов в куче и работы GC при обработке больших JSON-документов.

#Java #для_новичков #beginner #IO #NIO #Serialize #JSON

Путь байтов в памяти JVM при работе с JSON

1. Получение JSON-строки
JSON-данные обычно поступают в JVM одним из трёх способов: как строка из HTTP-ответа, как содержимое файла, считанное через Files.readString(), или как сообщение из брокера (Kafka, RabbitMQ).
Если JSON приходит по HTTP, процесс начинается на уровне сетевого стека ОС. Пакеты TCP собираются в сегменты, данные копируются из kernel space (пространство ядра) в user space (пользовательское пространство) в буфер сокета. Servlet-контейнер (Tomcat, Jetty, Netty) или фреймворк (Spring Boot) читает байты из сокета в буфер — обычно это byte[] или ByteBuffer в куче JVM.

Kernel space и user space — это два режима работы процессора. Kernel space — привилегированный режим, в котором работает код операционной системы и драйверов. User space — непривилегированный режим, в котором работают обычные приложения, включая JVM. Переход между режимами (context switch) — дорогая операция.

2. Декодирование байтов в строку
Байты из сети или файла представляют JSON в кодировке UTF-8. JVM декодирует их в объект String — это массив byte[] (начиная с Java 9; ранее char[]) в куче, плюс объект-обёртка String со ссылкой на массив, хэш-кодом и флагами.
В Java 9+ строки хранятся как byte[] с кодировкой LATIN1 (1 байт на символ) или UTF-16 (2 байта на символ), в зависимости от содержимого. Компактные строки (compact strings) экономят память для ASCII-текстов. Для JSON, состоящего преимущественно из ASCII, это означает экономию ~50% по сравнению со старым char[].

Compact strings — оптимизация, введённая в Java 9 (JEP 254). Строки, содержащие только символы Latin-1 (коды 0–255), хранятся в массиве 

byte[]

 по одному байту на символ. Если встречается символ вне Latin-1, массив переключается на UTF-16 (2 байта на символ).

3. Парсинг JSON: аллокация объектов в куче
Парсер (Jackson, Gson или стандартный org.json) читает строку посимвольно и строит дерево объектов. Для JSON-документа:

{
  "users": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ]
}

Jackson создаст следующие объекты в куче:
Один JsonNode (или LinkedHashMap при десериализации в Map) для корневого объекта.
Один ArrayNode (или ArrayList) для массива "users".
Два ObjectNode (или LinkedHashMap) для объектов пользователей.
Четыре IntNode / Integer для полей "id".
Два TextNode / String для полей "name".
Строковые ключи "users", "id", "name" — если они не интернированы, создаются как отдельные объекты String.
Все эти объекты создаются в Young Generation, в области Eden. Для JSON-документа размером 10 КБ количество объектов может достигать сотен. При обработке тысяч запросов в секунду это создаёт огромное давление на Minor GC.

4. Маппинг на POJO: рефлексия и дополнительные аллокации
При десериализации JSON в Java-объекты (POJO) парсер использует рефлексию — механизм Java для интроспекции классов во время выполнения.
Рефлексия требует:
Создания объекта Constructor через Class.getDeclaredConstructor().
Вызова Constructor.newInstance() — аллокация POJO в куче.
Установки полей через Field.set() или вызова сеттеров.
Jackson оптимизирует это через SerializerCache и DeserializerCache — кэши, хранящие скомпилированные сериализаторы и десериализаторы. После первого использования класса его метаданные кэшируются, и последующие операции не требуют полной рефлексии. Однако первый парсинг класса — дорогая операция, создающая множество временных объектов.

5. Работа GC с JSON-объектами
После десериализации JSON-строка и промежуточные структуры парсера (токены, узлы дерева) становятся мусором. Если использовался Jackson в режиме потокового парсинга (Streaming API), дерево не строится целиком — объекты создаются по мере чтения и сразу собираются GC. В режиме древовидного парсинга (Tree Model) всё дерево JSON хранится в памяти до явного освобождения.
Для высоконагруженных систем критично минимизировать аллокации:

// Потоковый парсинг Jackson — минимум аллокаций
public void processLargeJson(InputStream in) throws IOException {
    // JsonFactory — лёгкий фабричный объект для создания парсеров
    JsonFactory factory = new JsonFactory();
    
    // JsonParser — потоковый парсер, читает JSON без построения дерева
    try (JsonParser parser = factory.createParser(in)) {
        while (parser.nextToken() != JsonToken.END_OBJECT) {
            String fieldName = parser.getCurrentName();
            if ("users".equals(fieldName)) {
                parser.nextToken(); // переходим к массиву
                while (parser.nextToken() == JsonToken.START_OBJECT) {
                    // Обрабатываем каждый объект пользователя
                    int id = 0;
                    String name = null;
                    while (parser.nextToken() != JsonToken.END_OBJECT) {
                        String key = parser.getCurrentName();
                        parser.nextToken();
                        if ("id".equals(key)) {
                            id = parser.getIntValue();
                        } else if ("name".equals(key)) {
                            name = parser.getValueAsString();
                        }
                    }
                    // Обрабатываем пользователя без создания промежуточных объектов
                    processUser(id, name);
                }
            }
        }
    }
}

В этом примере JsonParser читает JSON как поток токенов, не создавая дерево объектов. Память используется минимально, и давление на GC снижается на порядки по сравнению с mapper.readValue(json, UserList.class).

6. Сериализация: обратный путь
При сериализации Java-объекта в JSON происходит обратный процесс:
Jackson обходит поля объекта через кэшированные сериализаторы.
Генерирует JSON-текст как char[] или byte[] внутри StringWriter или OutputStream.
Если вывод идёт в OutputStream (HTTP-ответ, файл), байты записываются напрямую без промежуточной строки.
Если вывод идёт в String, создаётся объект String в куче, который затем передаётся дальше.
При сериализации в HTTP-ответ через Spring Boot используется MappingJackson2HttpMessageConverter, который пишет JSON напрямую в OutputStream ответа, минуя создание промежуточной строки. Это экономит аллокации и снижает нагрузку на GC.

7. Ключевые строки и пул строк
Ключи JSON-объектов ("id", "name", "users") — это строки, которые повторяются в каждом документе. Jackson может интернировать часто встречающиеся ключи через JsonFactory.Feature.INTERN_FIELD_NAMES. Интернирование помещает строки в пул строк (String Pool) в Metaspace, делая их доступными для повторного использования между запросами. Это снижает аллокации, но увеличивает потребление Metaspace — пул строк не собирается обычным GC.
Интернирование строк — это процесс помещения строки в пул строк JVM через метод String.intern(). Если строка с таким содержимым уже есть в пуле, возвращается существующий объект; иначе строка добавляется в пул. Интернирование экономит память при множестве одинаковых строк, но может привести к утечке памяти в Metaspace при интернировании уникальных строк.

8. Бинарные JSON-форматы и память
Для снижения давления на GC и размера данных используются бинарные форматы на основе JSON:
BSON (Binary JSON) — используется в MongoDB. Содержит типовые теги и длины полей, что ускоряет навигацию без полного парсинга.
MessagePack — бинарный формат, совместимый с JSON по структуре, но более компактный.
CBOR (Concise Binary Object Representation) — стандарт RFC 8949, разработанный IETF как бинарная альтернатива JSON.
Эти форматы парсятся быстрее, так как не требуют посимвольного разбора текста, и создают меньше объектов в куче.


#Java #для_новичков #beginner #IO #NIO #Serialize #JSON

Раздел 11. Работа с файлами, I/O и сетью (NIO.2)

Глава 3. Сериализация и форматы обмена

YAML — формат для конфигураций

YAML (YAML Ain't Markup Language) — это текстовый формат сериализации данных, ориентированный на максимальную читаемость для человека. Первая спецификация YAML 1.0 была выпущена в 2001 году, текущая актуальная версия — YAML 1.2.2 (октябрь 2021). В отличие от JSON, YAML использует отступы для обозначения структуры вместо фигурных скобок и квадратных скобок, что делает документы визуально чище и ближе к естественному языку.

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

YAML не является языком разметки в строгом смысле: он не содержит тегов разметки текста, как HTML или XML. Вместо этого YAML — это формат представления графа данных (data graph), где узлами являются скаляры, последовательности и отображения (маппинги).

Граф данных — это абстрактная структура, состоящая из узлов (данных) и рёбер (связей между данными). В YAML узел может быть скаляром (строка, число, булево, null), последовательностью (упорядоченный список) или отображением (ассоциативный массив, пары ключ-значение).

Где используется YAML

YAML стал де-факто стандартом для конфигурационных файлов в современной инфраструктуре и разработке:
Spring Boot: файл application.yml — альтернатива application.properties. Spring Boot использует SnakeYAML под капотом для парсинга YAML-конфигураций и маппинга их на @ConfigurationProperties.
Docker Compose: файл docker-compose.yml описывает мультиконтейнерные приложения: сервисы, сети, тома, переменные окружения.
Kubernetes: манифесты ресурсов (pods, deployments, services) пишутся в YAML. kubectl apply -f deployment.yml — стандартная операция развёртывания.
Ansible: playbooks и inventories — YAML-файлы, описывающие сценарии автоматизации конфигурации серверов.
GitHub Actions: workflow-файлы .github/workflows/ci.yml описывают пайплайны CI/CD.
Helm: чарты Kubernetes используют YAML для шаблонов и values-файлов.

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


Библиотека SnakeYAML

В Java-экосистеме стандартной библиотекой для работы с YAML является SnakeYAML. Она разработана сообществом и широко используется как самостоятельно, так и как транзитивная зависимость Spring Boot. На момент 2026 года актуальные версии:
SnakeYAML 2.x — классическая реализация, поддерживающая YAML 1.1 и частично YAML 1.2. Используется в Spring Boot 3.x.
SnakeYAML Engine — отдельный проект, полностью реализующий YAML 1.2. Более строгий парсер, но менее распространён в прикладной разработке.
SnakeYAML 2.x (выпущенная в 2023 году) внесла критическое изменение безопасности: по умолчанию отключена возможность десериализации произвольных Java-объектов через теги !! (tag handles). Это закрыло классическую уязвимость YAML deserialization remote code execution (RCE), когда злоумышленник мог внедрить в YAML тег !!javax.script.ScriptEngineManager и выполнить произвольный код. В SnakeYAML 2.x для загрузки произвольных классов требуется явная настройка LoaderOptions.

RCE (Remote Code Execution) — это класс уязвимостей, позволяющий атакующему выполнить произвольный код на целевой системе удалённо. В контексте десериализации RCE возникает, когда формат данных позволяет указать класс для инстанцирования, и этот класс имеет опасный конструктор или сеттер.

#Java #для_новичков #beginner #IO #NIO #Serialize #YAML