The transient keyword in Java

It's a small keyword with a surprising number of interview follow-ups, because it sits on top of Java serialization, one of the most misunderstood (and most exploited) parts of the platform. Interviewers ask about it to check whether you know what serialization actually writes, why a field initialiser doesn't run on deserialize, how to rebuild skipped state, and whether you realise transient means nothing to Jackson unless you configure it.

For this lesson, we'll focus on how Java serialization works at a high level, what transient skips and what you get back, the real use cases, transient combined with final and static, restoring state with readObject, serialVersionUID, Externalizable, how JSON libraries treat transient, and the security problems with Java serialization.

01Picture it first: packing a suitcase for a move

Think of serialization as packing a suitcase for an object that's moving to another JVM, a file or a cache. You pack the things that define who the object is: its ID, its items, its settings. You don't pack the things that make no sense at the destination or are dangerous to carry: the key to your current flat (a session token), the milk in your fridge (a cache), or the house itself (an open database connection). transient is the "don't pack" sticker.

When the suitcase is unpacked, the unpacked slots aren't magically refilled. They're empty, and it's your job to restock them. The diagram below shows a session object going through that round trip.

Fig. 1

A UserSession object with fields userId, authToken, cache and failedAttempts passes through ObjectOutputStream; only userId is written to the byte stream, and after ObjectInputStream reads it back, authToken and cache are null and failedAttempts is 0

Notice three things:

• Only non-transient, non-static instance fields go into the stream.
• The deserialized copy gets type defaults, not the values from the field initialisers (= new HashMap<>(), = 3).
• userId survives even though it's final: serialization writes and restores final fields that aren't transient.

02Under the hood: what serialization skips and what you get back

class UserSession implements Serializable {
    private static final long serialVersionUID = 1L;
    static String region = "ap-south-1";                  // static: never serialized

    private final String userId;
    private transient String authToken;                   // secret
    private transient Map<String, Object> cache = new HashMap<>();
    private transient int failedAttempts = 3;
    private transient boolean verified = true;
    private final transient Object lock = new Object();

    UserSession(String userId, String authToken) {
        this.userId = userId;
        this.authToken = authToken;
    }
}

var bytes = new ByteArrayOutputStream();
try (var out = new ObjectOutputStream(bytes)) {
    out.writeObject(new UserSession("u-42", "eyJhbGciOi..."));
}
UserSession.region = "eu-west-1";                         // change the static after writing

try (var in = new ObjectInputStream(new ByteArrayInputStream(bytes.toByteArray()))) {
    UserSession copy = (UserSession) in.readObject();
    // copy.userId          -> "u-42"
    // copy.authToken       -> null
    // copy.cache           -> null    (initialiser did not run)
    // copy.failedAttempts  -> 0       (not 3)
    // copy.verified        -> false   (not true)
    // copy.lock            -> null    (final, and still null)
    // UserSession.region   -> "eu-west-1" (whatever the class has now)
}

Here's why. When ObjectInputStream creates the object, it doesn't call UserSession's constructor. It allocates the object and runs only the no-arg constructor of the first non-serializable superclass, which here is Object(). Field initialisers are compiled into UserSession's constructors, so they don't run either. Then it fills the non-transient fields from the stream. Everything else keeps the default the JVM gave it at allocation time.

Notice three things:

• cache is null, not empty. Code that calls cache.get(key) after deserialization throws NullPointerException. This is the most common real bug with transient.
• static fields aren't part of any object's state, so the stream never contains them. You see the class's current value, whatever it is in the receiving JVM. Adding transient to a static field is legal and does nothing.
• final transient is a trap. The field can't be assigned in readObject with a normal assignment (it's final, and you're not in a constructor), so it stays null. Options: drop final, restore it in readResolve by returning a freshly constructed object, or don't make it transient at all.

Those rules compose into one decision the runtime makes per field, shown below.

Fig. 2

A decision tree: if the class is Externalizable only what writeExternal writes is stored, otherwise a static field is never written, a transient field is skipped and returns a default, and any remaining field is written and restored including final fields

03Restoring transient state with readObject

The standard way to rebuild skipped fields is a private readObject method. The serialization machinery finds it reflectively (it must be exactly private void readObject(ObjectInputStream)), calls it instead of the default field restore, and you call defaultReadObject() first to read the normal fields.