skip to content

What does the transient keyword do during serialization, and when would you use it?

level: middleimportance: must knowfreq 68%

answer

  1. Field-level opt-out of serialization
  2. Comes back as default value (null/0/false)
  3. Use for secrets, caches, non-serializable refs
  4. Constructor doesn't re-init it
  5. Restore via readObject/readResolve

basics

~10 s

transient marks an instance field to be skipped during serialization. Its value is not written out, and after deserialization it comes back as the default for its type (0, false, or null).

solid answer

~40 s

transient is a field modifier that tells default serialization to exclude that field from the byte stream. You use it for data that should not or cannot be persisted: sensitive values like passwords, large caches or derived fields you can recompute, and references to non-serializable objects (e.g. a Thread, a database connection, or a logger) that would otherwise cause NotSerializableException. On deserialization, a transient field is not restored from the stream; it gets the JVM default value (null for objects, 0/0.0/false for primitives). If you need a custom value restored, implement readObject (or readResolve) to recompute or reinitialize it. transient applies only to instance fields; static fields are already excluded because they belong to the class, not the object.

code

java · 13 lines
java
class Session implements Serializable {
    private static final long serialVersionUID = 1L;
    String userId;                 // serialized
    transient String password;     // skipped -> null after load
    transient Connection db;        // non-serializable -> skipped

    private void readObject(ObjectInputStream in)
            throws IOException, ClassNotFoundException {
        in.defaultReadObject();    // restores userId
        this.db = openConnection(); // reinitialize transient state
    }
    private Connection openConnection() { /* ... */ return null; }
}

go deeper

for a junior

Knows transient skips a field during serialization and that it becomes null/0/false afterward.

for a middle

Lists the real use cases (secrets, caches, non-serializable references) and knows the constructor isn't run, so defaults persist unless restored.

for a senior

Explains restoring state via readObject/defaultReadObject and readResolve, the final+transient pitfall, and the staleness/security rationale for excluding fields.

for a principal

Treats transient as part of a deliberate serialized-form contract: what crosses the boundary, invariant restoration, security of excluded secrets, and how the serialized form is an API that must evolve safely.

## Quick recap of serialization When you serialize a `Serializable` object with `ObjectOutputStream`, the JVM uses reflection to write each **instance field** to a byte stream. **`transient`** is a Java keyword (a field modifier) that opts a single field **out** of this process. ## What transient does Write `transient int cacheSize;` and default serialization **will not write that field's value** to the stream. There is no placeholder for the real value. On **deserialization**, because nothing was written, the field is set to the **default value for its type**: - object references → `null` - `int`/`long`/`short`/`byte` → `0` - `double`/`float` → `0.0` - `boolean` → `false` - `char` → `''` Importantly, the constructor does **not** run during deserialization, so transient fields are *not* re-initialized by constructor code — they stay at the type default unless you intervene. ## When to use transient 1. **Sensitive data** — a password, secret key, or token you don't want written to disk or sent over the wire. 2. **Derived / cached fields** — values you can recompute from other state (a memoized hash, a cached formatted string). Storing them wastes space and risks staleness. 3. **Non-serializable references** — fields holding objects whose class isn't `Serializable` (a `Thread`, an open socket/`Connection`, a `Logger`, a UI widget). Without `transient`, serializing the owner throws `NotSerializableException`. Marking them transient lets the owner serialize cleanly. 4. **Resources tied to the current JVM/process** — file handles, sockets — which are meaningless after transport. ## Restoring transient state after deserialization If a transient field needs a real value after load (e.g. reopen a connection, recompute a cache), implement a private method the serialization mechanism calls: ``` private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException { in.defaultReadObject(); // read the non-transient fields this.cache = recompute(); // reinitialize transient state } ``` Or use `readResolve()` to substitute a fully built replacement object. These hooks are how you reconcile the transient defaults with the object's real invariants. ## transient vs static Both are excluded from default serialization, but for different reasons. `static` fields belong to the **class**, not any instance, so there's nothing instance-specific to serialize. `transient` is an **explicit instance-level opt-out** you choose. Marking a static field transient is redundant. ## Gotcha: final + transient A `final` transient reference field can't be reassigned in `readObject` (it's final), so you can't easily recompute it there without reflection — a reason to avoid `final` on transient fields you intend to restore.

  • After deserializing an object, what value does a transient String field have?
    null. transient object fields are not written to the stream and are not restored, so they take the default value for their type — null for references, 0/false for primitives. The constructor does not run to re-initialize them.
  • How can you give a transient field a meaningful value after deserialization?
    Implement a private readObject(ObjectInputStream) that calls in.defaultReadObject() then sets the field (recompute a cache, reopen a connection), or use readResolve() to return a fully constructed substitute object.

transient is like a 'do not pack' tag on a drawer when you're moving house — the movers (the JVM) skip it, and at the new house that drawer arrives empty.

saying these in an interview costs you the question

  • Thinking transient zeroes the field but keeps 'some' encrypted value
  • Expecting the constructor to re-initialize transient fields on load
  • Marking static fields transient (redundant)
  • Forgetting that a final transient field can't be reassigned in readObject
  • Believing transient affects how the field behaves at normal runtime (it only affects serialization)

context

resolving links…