Ответ.

История вопроса:

Java с самого начала поддерживает механизм сериализации объектов через интерфейс Serializable. Иногда необходимо сохранить состояние объекта, но не все поля стоит сериализовать — например, они могут быть чувствительными к безопасности или вычисляться динамически. Для таких случаев и был придуман модификатор transient.

Проблема:

Если сериализовать объект целиком, без учёта особенностей отдельных полей, можно допустить утечку приватных или неустойчивых к сериализации данных. Кроме того, сериализация и десериализация тяжёлых или временных полей (например, потоков, соединений с БД) может привести к ошибкам или снижению производительности.

Решение:

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

Пример кода:

import java.io.*;

class User implements Serializable {
    private String username;
    private transient String password; // Не сериализуется!
    public User(String username, String password) {
        this.username = username;
        this.password = password;
    }
}

Ключевые особенности:

transient применяется только к полям, а не к методам или классам
transient поля теряют своё значение при передаче объекта по сети/загрузке из файла
transient не защищает данные вне механизма стандартной сериализации (например, при ручном копировании)

Вопросы с подвохом.

Может ли статическое поле быть transient?

Ответ: Можно объявить поле как static transient, но смысла это не имеет: статические поля и так не сериализуются, потому что принадлежат классу, а не объекту.

Можно ли сделать полный контроль над сериализацией transient-полей?

Ответ: Да, реализовав методы private void writeObject(ObjectOutputStream out) и private void readObject(ObjectInputStream in), можно самостоятельно сериализовать даже transient поля при необходимости.

Пример кода:

private void writeObject(ObjectOutputStream out) throws IOException {
    out.defaultWriteObject();
    // out.writeObject(password); // если нужно явно сериализовать transient-поле
}

Что будет с final transient полем после десериализации?

Ответ: final transient-поля также получают значения по умолчанию (обычно ноль или null), но потом их невозможно изменить без специальных ухищрений, что часто приводит к багам.

Типовые ошибки и анти-паттерны

Отмечать transient все приватные поля по привычке
Не учитывать, что после десериализации transient-поля надо инициализировать заново вручную (например, в методе readObject)

Пример из жизни

Негативный кейс

Сериализовали объект с transient-полем DatabaseConnection. После десериализации попытались вызвать методы этого соединения — получили NullPointerException.

Плюсы:

Сохранили объект без чувствительной информации

Минусы:

Потеря работоспособности объекта, требуется дополнительная инициализация

Позитивный кейс

Сериализовали объект User с transient-паролем, при десериализации в readObject запросили пароль у пользователя или восстановили соединение.