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

1. Загрузка YAML-файла
Когда приложение читает application.yml из classpath или файловой системы, данные проходят следующий путь:
Файл считывается через InputStream — байты передаются из кэша страниц ОС через нативную память в буфер byte[] в куче JVM (аналогично Files.readAllBytes(), описанному в предыдущих уроках).
SnakeYAML использует Reader (обычно InputStreamReader с кодировкой UTF-8) для декодирования байтов в символы char[]. Этот массив создаётся в Young Generation, в Eden.
Парсер SnakeYAML читает символы и строит внутреннее представление документа — дерево узлов (Node graph). Каждый узел YAML (скаляр, последовательность, отображение) представлен объектом в куче: ScalarNode, MappingNode, SequenceNode. Для конфигурации размером 5 КБ количество узлов может достигать нескольких десятков.

Node graph — это промежуточное представление YAML-документа в памяти парсера перед маппингом на Java-объекты. Оно отражает структуру документа независимо от целевого типа данных.

2. Маппинг на Java-объекты
После построения дерева узлов начинается фаза конструирования:
Constructor обходит дерево узлов. Для каждого MappingNode он создаёт целевой Java-объект через рефлексию: вызов Class.newInstance() (или Constructor.newInstance() в современных версиях) аллоцирует объект в куче.
Для каждого ключа отображения Constructor ищет соответствующий сеттер через Introspector (механизм JavaBeans introspection). Introspector анализирует класс и кэширует PropertyDescriptor — дескрипторы свойств. Эти дескрипторы создаются при первом обращении к классу и хранятся в кэше, но первое использование класса порождает множество временных объектов рефлексии.

Introspection (интроспекция) — это механизм Java, позволяющий во время выполнения анализировать структуру классов: получать список методов, полей, конструкторов, аннотаций. java.beans.Introspector — стандартный класс для JavaBeans-интроспекции.

Значения узлов преобразуются в целевые типы: строки остаются строками, числа конвертируются через Integer.parseInt() или аналогичные методы, вложенные отображения рекурсивно конструируются.
Промежуточные структуры — дерево узлов, массивы символов, объекты рефлексии — становятся мусором после завершения конструирования. Если конфигурация читается один раз при старте приложения, все эти объекты собираются при первой Minor GC после инициализации.

3. Работа GC с конфигурационными объектами
Объект конфигурации (например, LibraryConfig) обычно сохраняется в Old Generation (Tenured), так как он живёт всё время жизни приложения. Ссылки на него хранятся в контексте Spring (singleton-бины) или в статических полях.

Singleton — это паттерн проектирования, гарантирующий, что у класса есть только один экземпляр, и предоставляющий глобальную точку доступа к нему. В Spring Boot все бины по умолчанию — singleton.

Промежуточные объекты парсинга (дерево узлов, char[] исходного файла, временные объекты рефлексии) создаются в Young Generation и уничтожаются Minor GC. Важно, что SnakeYAML не использует пул строк для ключей YAML — каждый ключ создаётся как новый объект String в куче. При большом количестве ключей это создаёт давление на Eden, но так как конфигурация читается редко, это не критично.

4. Потенциальная утечка: кэш классов SnakeYAML
SnakeYAML кэширует TypeDescription и конструкторы классов во внутренних Map. Эти кэши растут по мере обработки новых классов. В долгоживущих приложениях, которые динамически загружают множество различных YAML-схем, кэш может занимать значительный объём Old Generation. Это не утечка в классическом смысле (кэш необходим), но требует мониторинга через heap dump.

Heap dump — это снимок всей кучи JVM в определённый момент времени. Он содержит все объекты, их размеры, ссылки между ними и классы. Анализ heap dump позволяет находить утечки памяти и понимать распределение объектов по поколениям.

5. Запись YAML: обратный путь
При сериализации Java-объекта в YAML:
Representer обходит поля объекта и строит дерево узлов в памяти (аллокации в Young Generation).
Emitter преобразует дерево узлов в поток символов char[].
Writer кодирует символы в UTF-8 байты и записывает в OutputStream.
Байты уходят в файловую систему или сетевой сокет через системные вызовы ОС.
Все промежуточные структуры (дерево узлов, буферы символов) создаются в Young Generation и собираются при следующей Minor GC.


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

[Совет по Java #069]

Тема: Всегда переопределяйте compareTo() в соответствии с equals(), если планируете использовать объекты в TreeSet/TreeMap.

Проблема: Интерфейс Comparable и его метод compareTo() определяют естественный порядок объектов. Контракт Comparable требует, чтобы compareTo() был согласован с equals(), то есть для любых двух объектов a и b должно выполняться: a.compareTo(b) == 0 тогда и только тогда, когда a.equals(b) == true.

Если это правило нарушено, то TreeSet и TreeMap, которые используют compareTo() для сравнения и упорядочивания, перестают корректно работать. Например, если два объекта имеют одинаковый compareTo (возвращают 0), но разные equals, они будут считаться дубликатами, и второй не будет добавлен в TreeSet, либо TreeMap перезапишет значение. Это противоречит ожиданиям, основанным на equals. Ошибка проявляется в виде "потери" элементов, неправильного размера множества или некорректного поиска по ключу.

Решение: При реализации Comparable для классов, которые будут использоваться в упорядоченных коллекциях, всегда проверяйте, что compareTo возвращает 0 для объектов, которые считаются равными по equals.

Для этого используйте в compareTo те же поля, что и в equals, и в одинаковом порядке. Если поля не могут быть сравнимы (например, null), обработайте это явно. Если невозможно достичь согласованности (например, у вас сложная логика сравнения), используйте отдельный Comparator с четкой документацией, но лучше пересмотреть дизайн.

Для примитивных полей используйте Integer.compare, Double.compare и т.д. Для строк — String.compareTo. Также помните, что compareTo должно быть транзитивным и антисимметричным.

import java.util.Objects;

public class Person implements Comparable<Person> {
    private final String name;
    private final int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    //Нарушение: compareTo не согласован с equals
    // @Override
    // public int compareTo(Person o) {
    //     return this.age - o.age; // Только по возрасту
    // }
    // // equals по имени и возрасту
    // public boolean equals(Object o) {
    //     if (!(o instanceof Person)) return false;
    //     Person p = (Person) o;
    //     return name.equals(p.name) && age == p.age;
    // }

    //Корректно: compareTo использует те же поля, что и equals
    @Override
    public int compareTo(Person o) {
        int nameComp = this.name.compareTo(o.name);
        if (nameComp != 0) return nameComp;
        return Integer.compare(this.age, o.age);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Person)) return false;
        Person p = (Person) o;
        return age == p.age && name.equals(p.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }

    @Override
    public String toString() {
        return name + "(" + age + ")";
    }

    public static void main(String[] args) {
        // Демонстрация нарушения
        Person p1 = new Person("Alice", 30);
        Person p2 = new Person("Bob", 30);

        // Если compareTo только по возрасту, то p1.compareTo(p2) == 0,
        // хотя equals вернет false (имена разные).
        // TreeSet считает их одинаковыми
        TreeSet<Person> set = new TreeSet<>();
        set.add(p1);
        set.add(p2);
        System.out.println("Size: " + set.size()); // Должно быть 1, если compareTo=0
        System.out.println("Contains Alice? " + set.contains(p1)); // true
        System.out.println("Contains Bob? " + set.contains(p2));   // true? Зависит от реализации
        // На самом деле, если compareTo=0, то при добавлении второго он будет считаться дубликатом
        // и не будет добавлен, но contains для Bob вернет true, потому что TreeSet использует compareTo
        // для поиска, а не equals. Это делает поведение непредсказуемым.
    }
}

Объяснение: TreeSet и TreeMap хранят элементы в красно-черном дереве, где сравнение выполняется через compareTo или Comparator. При добавлении элемента дерево проверяет, существует ли уже узел с тем же значением compareTo (т.е. возвращает 0). Если существует, то новый элемент считается дубликатом, и в TreeSet он не добавляется, а в TreeMap перезаписывается значение.

При этом equals вообще не используется для проверки дубликатов; она применяется только для contains и remove? На самом деле, TreeSet использует compareTo для поиска: если compareTo возвращает 0, объект считается равным, и возвращается существующий, без вызова equals. Поэтому нарушение контракта приводит к тому, что объекты, которые по логике должны быть разными, становятся неразличимыми для коллекции.

Это нарушает принцип "Set не содержит дубликатов" — фактически дубликаты по equals могут быть, но они не добавляются из-за compareTo. И наоборот, объекты с одинаковым equals, но разным compareTo, будут восприниматься как разные, что нарушает контракт Set. Поэтому всегда используйте в compareTo те же поля, что и в equals, и в том же порядке, чтобы обеспечить согласованность. Если поля могут быть null, используйте Objects.compare или явные проверки.


#Java #советы