What hazards arise from the shared, interned instances that the Flyweight pattern creates — around identity comparison, mutability, locking, serialization and multi-tenancy?

## The root cause **Flyweight** deliberately makes one object reachable from many unrelated places. Everything below is a consequence of that single fact: *shared references create coupling between code paths that were never designed to know about each other*. ## Hazard 1 — mutability turns a field into a global variable If a flyweight exposes any writable state, writing it from one call site changes what every other occurrence observes. Typical symptoms: an attribute "randomly" changes between reads; a rendering artifact appears only under load; a test passes alone and fails in a suite. These reproduce poorly because they depend on interleaving and on which occurrences happen to share a key. Defences: - **Deep immutability.** Final/`val` fields are not enough: an immutable object holding a mutable list or array is mutable. Copy on construction and expose unmodifiable views, or store primitive arrays that are never handed out. - **No lazy caching of context-dependent values.** A tempting `lastComputedLayout` field inside the flyweight is extrinsic state in disguise. Lazy caching of *intrinsic-derived* values is fine if it is idempotent and safely published; anything derived from arguments is not. - **Safe publication.** Another thread must not be able to see a partially constructed flyweight. Immutable objects with final fields get this from most memory models; objects populated after construction do not. ## Hazard 2 — the identity trap Interning creates a tempting invariant: "equal values are the same object, so I can compare with `==`/`is`". Reference comparison is fast and it works — until an instance appears that did not come from the factory. Sources of uninterned duplicates: - **Deserialization.** Reading an object from bytes, JSON, or an RPC frame constructs a fresh instance. Unless you re-canonicalize on the read path (a `readResolve`-style hook or an explicit `intern()` in your mapper), you now hold a value-equal but reference-distinct twin. - **Reflection, cloning, copy constructors, direct `new`.** Any path that bypasses the factory. Make constructors private/internal so the factory is the only door. - **Eviction or weak references.** If the cache can drop entries, the same key can yield a different instance later, and two live instances for one value can coexist. - **Multiple class loaders / modules / processes.** Distinct loaders create distinct classes and distinct interning tables; "the same" constant is not the same object across them. Nothing is shared across process boundaries at all. - **Compile-time vs runtime construction.** In several runtimes, literal constants are automatically interned while values built at runtime are not — which is exactly why comparing strings by reference is a classic beginner bug that hides for months. The rule: **publish value equality as the contract; treat reference identity as a private optimization** that only code inside the flyweight's own module may exploit, and only if it controls every construction path. ## Hazard 3 — locking and unintended contention Synchronizing on an interned object is a well-known anti-pattern. Because the instance is globally reachable, any other component — including third-party libraries that intern the same values — can lock the same monitor. Results: contention between unrelated subsystems, priority inversion, and genuine deadlock via lock-ordering conflicts you cannot see in your own code. Use a private lock object, or better, keep flyweights immutable so no locking is needed at all. The same applies to using a flyweight as a key in an identity-keyed side table with different lifecycle assumptions. ## Hazard 4 — scope, tenancy and lifecycle A process-global flyweight table is shared by every request, tenant, test and background job. - **Tenancy/security.** If flyweights encode tenant-derived data, or if the *presence* of a key is observable (via metrics, timing, or a size limit), you have a cross-tenant information channel. Key on tenant or scope the factory per tenant. - **Tests.** Global interning makes tests order-dependent: one test's entries change another's memory profile or eviction behaviour. Prefer injectable, scoped factories. - **Reachability pinning.** Flyweights that transitively reference contexts, connections or class loaders keep them alive forever, which is a classic redeploy-time leak in containerized application servers. - **Reload/versioning.** If the intrinsic data can change (a font is updated, a tax rule is amended), a permanent interned instance is now stale. Version the key or scope the cache to a configuration generation, and be explicit about whether existing occurrences see the old or new value. ## Hazard 5 — debuggability and ownership Shared objects make heap analysis and blame assignment harder: a retained-size report attributes shared bytes ambiguously, and an unexpected value in a flyweight gives you no clue which of a million call sites wrote it (if it was mutable). Logging is also affected — a flyweight's `toString` appears identically in unrelated log lines. Build in observability: factory metrics (`K`, hit ratio, retained bytes), an assertion or test that equal keys return identical instances, and a test that the flyweight type has no mutable state. ## The governing principle Flyweight buys memory with **coupling through shared references**. Every hazard above is that coupling escaping the boundary you intended. Keep the boundary tight: deep immutability, private constructors, factory-only construction, no locking on shared instances, scoped rather than global tables where isolation matters, and value equality as the public contract.