Что проверяет вопрос про serialVersionUID

Этим вопросом проверяют, понимаете ли вы, что сериализация в Java — контракт между версией класса на момент записи и версией на момент чтения, а не просто дамп байт.

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

Явный serialVersionUID фиксирует версию вручную. Вы сами решаете, когда старый формат несовместим, а не компилятор за вас.

transient исключает поле из сериализации — оно не пишется в поток и восстанавливается со значением по умолчанию (null, 0, false). Если полю нужна инициализация после чтения — переопределяют readObject.

private void readObject( ObjectInputStream in) throws IOException, ClassNotFoundException { in.defaultReadObject(); if (balance < 0) { throw new InvalidObjectException( "balance"); } }

Следующий вопрос обычно про readResolve() и защиту singleton от десериализации — новый объект через readObject нарушает гарантию единственного инстанса, если явно не вернуть существующий.

Сериализация даёт совместимость между версиями класса только если о ней думают заранее, а не когда уже нужно прочитать старый файл.

Тренажёр: 600 вопросов, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки