Records, sealed и switch в Java

record: объект-значение без обвязки

record - неизменяемый носитель данных. Объявляешь компоненты и получаешь готовыми канонический конструктор, аксессоры, equals, hashCode и toString по значениям. Я напечатал: new Point(1, 2) выводится как Point[x=1, y=2], а две одинаковые точки равны и дают одинаковый хеш. Поля финальны, наследоваться от record нельзя.

Проверки кладут в компактный конструктор - это тело без списка параметров, которое выполняется до присваивания полей. Замер подтвердил: record Range с проверкой lo > hi ловит некорректный диапазон прямо в момент создания.

// И главный подвох: неизменяемость тут по ссылкам. Я создал record с обычным списком внутри, потом добавил элемент в исходный список снаружи - и содержимое record изменилось. Тот же record с List.copyOf в компактном конструкторе остался прежним. Хочешь честную неизменяемость - копируй коллекции.

record SafeBox(List<String> items) {
    SafeBox { items = List.copyOf(items); }  // копия, а не ссылка
}

компактный конструктор

тело без параметров, выполняется до присваивания

дырявая неизменяемость

record хранит ссылку, а её содержимое мутируется

sealed и switch: компилятор следит за полнотой

Модификатор sealed закрывает иерархию: список permits перечисляет всех наследников, других не будет. Компилятор знает полный набор вариантов, поэтому switch по такой иерархии не требует ветки default.

И проверяет полноту всерьёз. Я убрал одну ветку из такого switch и получил ошибку компиляции: the switch expression does not cover all possible input values. То есть добавили в домен новый вид платежа - код не соберётся, пока не обработаешь его везде. Это то самое, ради чего конструкция и придумана.

Рядом живут выражения switch со стрелками (возвращают значение, без проваливания между ветками) и сопоставление с образцом: case по типам, разбор record на компоненты, условия when. Связка record плюс sealed плюс switch - идиома моделирования доменных вариантов.

// Сюда же instanceof с привязкой переменной: if (o instanceof String s) проверяет и приводит одной конструкцией. И var - вывод типа локальной переменной. Именно локальной: в поле класса var не поставить, я проверил, компилятор говорит 'var' is not allowed here. Тип при этом остаётся статическим, никакой динамики.

sealed interface Payment permits Card, Sbp {}
return switch (p) {          // default не нужен
    case Card c -> c.pan();
    case Sbp  s -> s.phone();
};

sealed и permits

закрытый список наследников, известный компилятору

сопоставление с образцом

проверка типа и структуры с привязкой переменных

Виртуальные потоки: масштаб ожидания, а не вычислений

Вернёмся к замеру из начала. Виртуальные потоки - дешёвые потоки, которые виртуальная машина мультиплексирует поверх немногих потоков операционной системы, их называют несущими. Блокирующий вызов не занимает несущий поток: виртуальный отцепляется, несущий обслуживает других. Отсюда 0,51 секунды против 5,08 на пуле из двухсот - и арифметика сходится, 20 000 задач разделить на 200 потоков умножить на 50 миллисекунд как раз даёт 5 секунд.

Граница применимости жёсткая: это про пропускную способность ОЖИДАНИЯ. Задачам, которые считают, виртуальные потоки не дают ничего - ядер и несущих потоков столько же, вычисления быстрее не станут.

И вторая граница, про которую спрашивают отдельно. Блокировка внутри synchronized прибивает виртуальный поток к несущему. Замерил на 100 виртуальных потоках, каждый спит 50 миллисекунд со своей собственной блокировкой: под synchronized прогон занял 2,51 секунды, под ReentrantLock - 0,05 секунды. Разница в 50 раз, и она равна ровно числу ядер: под synchronized одновременно работали только два.

// Это поведение версии 21, в 24-й его починили. Но код обычно живёт на долгих версиях, поэтому правило пока такое: в местах, где виртуальный поток может заблокироваться, берём ReentrantLock, а не synchronized.

виртуальный поток

лёгкий поток для блокирующего ввода-вывода

прибивание к несущему

synchronized не даёт виртуальному потоку отцепиться

Как отвечать: «Чем record отличается от обычного класса и когда его берёшь?»

record это неизменяемый носитель данных: компоненты финальны, а канонический конструктор, аксессоры, equals, hashCode и toString генерируются по значениям, наследование запрещено. Беру его для объектов-значений: DTO (data transfer object), ключи мап, результаты методов, доменные значения вроде суммы денег. Валидацию кладу в компактный конструктор - тело без параметров, которое отрабатывает до присваивания полей. Про подвох помню и проверял его специально: неизменяемость у record по ссылкам, поэтому если компонент это коллекция, снаружи её можно изменить и содержимое record поедет следом. Лечится копией через List.copyOf прямо в компактном конструкторе. Не беру record там, где нужна изменяемая сущность с жизненным циклом - например, JPA (Java Persistence API) -сущности: у них контракт на мутабельность, пустой конструктор и прокси, record туда не годится по конструкции.

Сильный ответ: перечислена механика, названы конкретные места применения и показаны два подвоха - дырявая неизменяемость и несовместимость с сущностями. Это уровень «использовал», а не «слышал».

На чём валят

• −Считают record обычным POJO (plain old Java object). Сеттеров и наследования у него нет по замыслу, поля финальны.
• −Считают record с полем-списком неизменяемым. Список мутируется снаружи, спасает List.copyOf в компактном конструкторе.
• −Пишут default в switch по sealed «на всякий случай». Главный бонус потерян: компилятор перестаёт проверять полноту при добавлении наследника.
• −Пробуют var в поле или в сигнатуре. Компилятор отвечает 'var' is not allowed here - это только локальные переменные.
• −Ждут ускорения от виртуальных потоков на вычислениях. Их выигрыш только в ожидании, а synchronized и вовсе сводит его к числу ядер.