How does object serialization handle shared references, cyclic references, and transient fields in an object graph?

## The object graph When you serialize one object, you rarely serialize just that object. It references other objects, which reference others — a connected web called the **object graph**. Serialization must reproduce this whole web faithfully when it deserializes, including two tricky cases: **shared references** and **cycles**. ## How identity is tracked: the handle table `ObjectOutputStream` maintains an internal **handle table**: a map from each object it has written to a small integer **handle**. The algorithm is: 1. About to write object X. Look it up in the handle table. 2. **Not seen before:** assign X a new handle, record it, and write X's full contents (class descriptor + field values). While writing those fields, the same algorithm runs recursively for each referenced object. 3. **Already seen:** write **only the handle** (a back-reference), not the contents again. `ObjectInputStream` mirrors this on read, building its own handle-to-object table so a back-reference resolves to the **same instance** it already created. ## Why this matters: shared references Suppose two `Order` objects both reference the **same** `Customer` instance. Without identity tracking you'd get two separate `Customer` copies after deserialization, breaking the invariant "these two orders share one customer." With the handle table, the customer is written once; the second reference is a handle; on read both orders point at the **one** reconstructed customer. Identity (`==`) is preserved within a single serialization. ## Why this matters: cycles If A references B and B references A, a naive recursive writer would loop forever. The handle table breaks the cycle: when serialization revisits A (already in the table), it writes a handle instead of recursing. So cyclic graphs serialize and deserialize correctly. ## transient fields A field declared `transient` is **excluded** from the default serialized form. Its bytes are never written. On deserialization it receives the **default value** for its type: `null` for references, `0`/`0.0` for numerics, `false` for boolean. Use cases: - Data that **can't** be serialized (a `Thread`, an open socket, a `java.sql.Connection`). - Data that **shouldn't** be persisted (a password/secret, a security token). - **Derived/cacheable** data that can be recomputed cheaply (a memoized hash, a cached formatted string). If a transient field must be restored to a meaningful value, implement a private `readObject(ObjectInputStream in)`: call `in.defaultReadObject()` first, then recompute or re-read the transient field. ## static fields `static` fields belong to the **class**, not to any instance, so they are never written as part of an instance's serialized state. Don't rely on serialization to carry class-level state. ## The reset() subtlety Because the handle table caches by **reference identity for the life of the stream**, a long-lived `ObjectOutputStream` can surprise you. If you `writeObject(x)`, then **mutate** `x`, then `writeObject(x)` again, the second call sees `x` already in the table and writes only a back-reference — the **new state is not sent**. Calling `out.reset()` clears the handle table so the next `writeObject` re-serializes full contents. This is a classic bug in streaming/caching code that reuses one stream. ## Summary mental model Think of serialization as a graph traversal that memoizes visited nodes by identity. Memoization gives you correct shared/cyclic handling and avoids duplication; `transient`/`static` prune nodes/fields out of the traversal; `reset()` clears the memo when you intentionally want to re-send.