Java design pattern deep dive
Flyweight Pattern in Java: 100 interview questions on sharing state efficiently.
Learn how to split intrinsic and extrinsic state, build a safe FlyweightFactory, and decide when sharing immutable objects actually beats simply allocating more memory or tuning the garbage collector.
What makes a good Flyweight answer?
Interviewers want to see that you can correctly separate shared, immutable intrinsic state from per-call extrinsic state, and that you know when sharing is actually worth the added indirection.
new.| Approach | Use when | Watch out for |
|---|---|---|
| Classic Flyweight (factory + shared immutable objects) | Many objects share identical, reusable intrinsic state fields. | Extrinsic state must be threaded through every method call. |
| Object pooling | Objects are mutable and expensive to construct, but not shared concurrently. | Pooled objects must be checked out and returned; no two callers hold one at once. |
String interning / String.intern() | Many identical string values arrive from parsing or I/O. | The global string pool is a shared, hard-to-tune resource; abuse can hurt more than help. |
| Plain unbounded caching | The key space is small and known ahead of time. | No eviction means the cache can grow without bound if the key space is not actually small. |
Topics
Interview questions and answers
Each answer explains the intrinsic/extrinsic split, the factory mechanics, and the production trade-off that makes the answer stronger.
1. Explain the Flyweight design pattern in your own words and describe the specific problem it solves in a Java application dealing with millions of small objects.
Flyweight is a structural pattern that lets you support a huge number of logical objects by sharing the parts of their state that are identical across many of them, instead of allocating one full object per logical instance. You split each object's data into intrinsic state, the part that is shareable and context-independent, and extrinsic state, the part that varies per use and is supplied by the caller at the moment of use.
The specific problem it solves is heap exhaustion and GC pressure: if you render, say, ten million characters in a document and each has its own font, size, and color object, you pay for ten million redundant copies of data that is actually drawn from a small set of distinct combinations. Flyweight collapses that to a handful of shared objects plus lightweight per-position data.
2. What is the difference between intrinsic and extrinsic state in the Flyweight pattern, and how would you decide which fields of a class belong in each category?
Intrinsic state is data that is independent of the object's context: it does not change based on where or how the object is used, so it can safely be shared by every caller that needs the same value. Extrinsic state is context-dependent: it changes per call site, per instance, or per invocation, and must be supplied by the client rather than stored on the shared object.
To classify a field, ask whether two logically different usages could ever need different values for it while still wanting to share the rest of the object. If yes, it is extrinsic and belongs in a parameter or a small companion object; if the value would always be identical for every user of that flyweight, it is intrinsic and can live inside the shared instance.
// Character glyph example
final class GlyphFlyweight { // intrinsic: shared, immutable
private final char symbol;
private final String fontFamily;
private final int baseSize;
}
// Extrinsic, supplied per draw call:
// x, y position, color, current zoom level3. Walk through how you would refactor a naive Character class used to render a text editor's glyphs into a Flyweight-based design, including the factory that manages shared instances.
The naive version stores the character, font family, size, style, and screen position all on one object per glyph instance, which means one object per character typed. The refactor pulls out the character, font family, size, and style as intrinsic state into a shared Glyph flyweight, and moves position and any per-occurrence formatting to an extrinsic parameter passed at draw time.
final class Glyph {
private final char symbol;
private final String fontFamily;
private final int size;
Glyph(char symbol, String fontFamily, int size) {
this.symbol = symbol;
this.fontFamily = fontFamily;
this.size = size;
}
void draw(Graphics g, int x, int y) { // x, y are extrinsic
g.setFont(new Font(fontFamily, Font.PLAIN, size));
g.drawString(String.valueOf(symbol), x, y);
}
}
final class GlyphFactory {
private final Map<String, Glyph> cache = new ConcurrentHashMap<>();
Glyph getGlyph(char symbol, String fontFamily, int size) {
String key = symbol + "|" + fontFamily + "|" + size;
return cache.computeIfAbsent(key, k -> new Glyph(symbol, fontFamily, size));
}
}The document then stores a lightweight list of (glyph reference, x, y) tuples instead of a full object per character, which is where the memory savings come from.
4. Why must Flyweight objects be effectively immutable, and what concrete bugs occur in production if a shared flyweight's intrinsic state is accidentally mutated by one client?
Because a single flyweight instance is referenced by many unrelated callers simultaneously, any mutation to its intrinsic state is instantly visible to every one of those callers, whether or not they intended the change. Immutability is what makes sharing safe: if the object never changes after construction, handing out the same reference to a thousand callers is equivalent to handing each of them their own copy.
A concrete production bug: a shared Font-like flyweight cached by family and size gets a "bold" flag toggled in place by one rendering call for a single heading, and suddenly every other paragraph in the document that shares that same cached flyweight renders bold too, because they were never distinct objects to begin with. These bugs are especially nasty because they are timing- and order-dependent, showing up only after the shared instance has been mutated by some earlier code path.
5. Describe the role of the FlyweightFactory in the pattern and show how you would implement one in Java using a ConcurrentHashMap to cache and reuse flyweight instances.
The FlyweightFactory is the single gatekeeper for flyweight creation: clients ask it for a flyweight matching some intrinsic key, and the factory either returns an existing cached instance or creates one, caches it, and returns it. Its job is to guarantee that equivalent intrinsic state always maps to the same shared object, which is the entire point of the pattern.
public final class TreeFactory {
private static final ConcurrentMap<String, TreeType> CACHE = new ConcurrentHashMap<>();
private TreeFactory() {}
public static TreeType get(String name, String texture, String color) {
String key = name + "|" + texture + "|" + color;
return CACHE.computeIfAbsent(key, k -> new TreeType(name, texture, color));
}
public static int cacheSize() {
return CACHE.size();
}
}computeIfAbsent on a ConcurrentHashMap gives you atomic get-or-create semantics without a manual lock, which is exactly the contract a factory needs under concurrent access.
6. How does Java's Integer.valueOf() caching of values between -128 and 127 relate to the Flyweight pattern, and where does the analogy break down?
Integer.valueOf() is a textbook example of flyweight-style sharing: the JVM pre-populates a cache of boxed Integer objects for the range -128 to 127 and returns the same shared instance for any request in that range, avoiding a fresh allocation for very common small values. The intrinsic state here is simply the numeric value itself, and since Integer is immutable, sharing is completely safe.
The analogy breaks down because this caching is implicit, fixed-size, and not something you configure or extend: you cannot ask the JVM to widen the cache without a system property, there is no explicit factory API you control, and unlike a real Flyweight there is no separate extrinsic state being passed around, it is simply value caching of a single immutable type rather than a decomposition into shared plus context-specific parts.
7. Compare the Flyweight pattern with simple object pooling. What fundamentally distinguishes sharing immutable flyweights from pooling mutable objects?
Object pooling reuses mutable objects sequentially: a caller checks one out, mutates it freely while it holds it, and returns it to the pool when done, at which point another caller may reuse the same instance, but never two callers concurrently. Flyweight sharing hands the exact same instance to many callers simultaneously and forever, which only works because the shared object is immutable and therefore incapable of being corrupted by concurrent use.
| Aspect | Flyweight | Object pool |
|---|---|---|
| Object lifecycle | Created once, shared indefinitely | Checked out, reset, and reused |
| Mutability | Immutable | Mutable between checkouts |
| Concurrent holders | Many, simultaneously | One at a time per instance |
8. In a game engine rendering thousands of trees in a forest, design a Flyweight-based solution where tree type is intrinsic and position/scale/rotation is extrinsic, and show the client-side rendering loop.
The intrinsic TreeType flyweight holds the mesh, texture, and material, which are identical for every oak tree in the forest. Each individual tree in the world is represented by a tiny Tree value holding a reference to its shared TreeType plus its own position, scale, and rotation, which are extrinsic and unique per placement.
record Tree(TreeType type, float x, float y, float z, float scale, float rotationDeg) {
void render(Renderer r) {
type.render(r, x, y, z, scale, rotationDeg); // extrinsic passed in
}
}
List<Tree> forest = ...; // hundreds of thousands of entries
for (Tree t : forest) {
t.render(renderer);
}Only a handful of TreeType instances exist no matter how many trees are placed, so the forest's memory footprint scales with the number of placements times a few small numbers, not with the size of the mesh and texture data.
9. What are the memory-versus-CPU trade-offs introduced by the Flyweight pattern, and under what circumstances could applying it actually make performance worse?
Flyweight trades a small amount of CPU and code complexity, the factory lookup and the need to pass extrinsic state through every call, for a potentially large reduction in memory footprint and allocation rate. When the intrinsic state is large or expensive to construct and there is genuine repetition, this trade is a clear win.
It can make things worse when the "sharing" ratio is low, meaning most requested combinations are actually distinct, because then you pay factory lookup overhead and extra indirection without meaningfully reducing object count, and you have added a layer of hashing and map maintenance that a plain constructor call would have avoided entirely.
10. Describe a scenario where the overhead of a factory lookup in the Flyweight pattern could outweigh the memory savings it provides.
Imagine a hot loop rendering a UI where the "intrinsic" object is a tiny two-field value object, cheap to allocate, and the workload rarely repeats the same combination twice, such as randomly generated debug markers with unique colors. Here, every call to the factory computes a composite key, hashes it, and probes a concurrent map, all of which costs more CPU time than simply constructing the small object directly would have.
The lesson is that Flyweight pays off specifically when the object being shared is nontrivial in size or construction cost and the same intrinsic combinations recur frequently; for tiny, mostly-unique objects a plain constructor is both simpler and faster.
11. How would you use Java's String.intern() method to illustrate flyweight-style string sharing, and what are the pitfalls of relying on the string pool this way in a long-running server application?
String.intern() looks up a string's contents in the JVM's global string pool and returns the canonical shared instance if one already exists, or adds the current string and returns it otherwise, which mirrors exactly the factory-lookup behavior of a Flyweight factory but operating on String content as the intrinsic key.
String a = new String("high-priority").intern();
String b = new String("high-priority").intern();
System.out.println(a == b); // true, same pooled instance12. Explain how you would combine the Flyweight pattern with the Factory Method pattern so that clients never directly instantiate flyweight objects.
Factory Method defines an interface or method for creating an object while letting the concrete creation logic live in one place; combining it with Flyweight means that single creation point is also where sharing is enforced. You give the flyweight class a package-private or private constructor, and expose only a static or instance factory method that first checks the shared cache before ever calling the constructor.
public abstract class Shape {
static Shape create(String type) { // factory method
return ShapeFactory.get(type); // delegates to flyweight cache
}
}
final class ShapeFactory {
private static final Map<String, Shape> CACHE = new ConcurrentHashMap<>();
static Shape get(String type) {
return CACHE.computeIfAbsent(type, ConcreteShape::new);
}
}Because the constructor is not public, the only path to obtaining an instance goes through the factory method, which is exactly where the sharing guarantee lives.
13. What thread-safety concerns arise when multiple threads concurrently request flyweights from a shared factory, and how would you make the factory's getFlyweight() method safe without over-synchronizing?
The main concern is a race between two threads both discovering that a given key is absent and both proceeding to construct and insert a new flyweight, which produces two distinct objects for what should be one shared instance, silently defeating the pattern. A secondary concern is partially-constructed objects becoming visible to other threads if publication is not safe.
private final ConcurrentMap<Key, Flyweight> cache = new ConcurrentHashMap<>();
Flyweight getFlyweight(Key key) {
return cache.computeIfAbsent(key, Flyweight::new); // atomic get-or-create
}ConcurrentHashMap.computeIfAbsent guarantees the mapping function runs at most once per key under contention, giving you correctness without wrapping the whole method in a coarse synchronized block, which would serialize every lookup even for already-cached keys.
14. Design a Flyweight implementation for a spreadsheet application where cell formatting is shared across thousands of cells, and describe the extrinsic state passed in from each Cell object.
A CellStyle flyweight holds the intrinsic formatting data that repeats across many cells: font, border style, background color, and number format. Individual Cell objects hold a reference to a shared CellStyle plus their own extrinsic data: row index, column index, and the actual value stored in that cell.
final class CellStyle { // intrinsic, shared
private final Font font;
private final Color background;
private final String numberFormat;
}
final class Cell { // per-cell, extrinsic
private final int row, col;
private Object value;
private CellStyle style; // shared reference
}In a spreadsheet where only a few dozen distinct styles are used across a million cells, this collapses the formatting memory cost from a million style objects down to a few dozen.
15. What common mistake do developers make when they put mutable or client-specific data into what should be the intrinsic state of a flyweight, and how does this defeat the purpose of the pattern?
A common mistake is adding a field like lastUsedByUserId or a mutable currentHighlight flag directly onto the flyweight class because it seemed convenient at the call site, without realizing that field is now shared across every caller of that flyweight. This either forces you to stop sharing the object entirely, defeating the point, or causes cross-contamination bugs where one caller's data leaks into another's view.
The fix is always the same: if a piece of data is specific to one usage context, it must be passed as extrinsic state through the method call, or stored in a separate small object the caller owns, never baked into the shared instance.
16. How can improper use of the Flyweight pattern lead to a memory leak, for example when a factory cache is never evicted and flyweights reference large intrinsic data that is rarely reused?
If the factory's cache is an unbounded map that only ever grows, and the intrinsic state space is effectively unbounded, such as caching by a user-generated string or a rarely-repeating composite key, then every distinct request permanently adds an entry that is never reclaimed even after nothing else references that particular combination. Because the factory itself holds a strong reference in its map, the flyweight and any large intrinsic data it carries, such as a decoded image or a parsed template, can never be garbage collected.
17. Compare the Flyweight pattern to the Prototype pattern. When would cloning objects be more appropriate than sharing them via a flyweight factory?
Flyweight shares one instance among many callers who all use identical, immutable data. Prototype instead gives each caller their own independent copy by cloning a pre-configured template object, which is appropriate exactly when the caller needs to subsequently mutate their instance without affecting anyone else.
| Situation | Preferred pattern |
|---|---|
| Data is identical and never mutated per caller | Flyweight (share one instance) |
| Data starts identical but each caller customizes it afterward | Prototype (clone, then mutate the copy) |
18. In a Java text-rendering library, how would you decide whether to key your flyweight cache by a composite key versus by individual attributes, and what are the performance implications of each?
A composite key, such as a small immutable record combining font family, size, and style, gives you a single well-defined hash and equals, which keeps the factory's map simple and correct, at the cost of allocating a small key object per lookup unless you cache or intern the keys themselves. Keying by individual attributes, such as nested maps per font family then per size then per style, can avoid that allocation but multiplies the code complexity and the number of map lookups per request.
record GlyphKey(char symbol, String font, int size) {}
private final Map<GlyphKey, Glyph> cache = new ConcurrentHashMap<>();For most applications, a composite key using a Java record, which gets free structural equals/hashCode, is the simpler and more maintainable choice, and the extra small allocation per lookup is negligible next to the savings from sharing the flyweight itself.
19. Describe how you would use WeakReference or SoftReference values in a Flyweight factory's cache to allow the JVM to reclaim rarely used flyweights under memory pressure, and what risks this introduces.
Instead of storing flyweights directly as map values, you wrap each in a SoftReference, which the garbage collector is permitted to clear when the JVM is under memory pressure but will otherwise leave alone, giving you a self-shrinking cache without manual eviction logic.
private final Map<Key, SoftReference<Flyweight>> cache = new ConcurrentHashMap<>();
Flyweight get(Key key) {
SoftReference<Flyweight> ref = cache.get(key);
Flyweight fw = (ref != null) ? ref.get() : null;
if (fw == null) {
fw = new Flyweight(key);
cache.put(key, new SoftReference<>(fw));
}
return fw;
}ReferenceQueue to remove dead entries, and GC-dependent eviction timing makes cache-hit behavior non-deterministic.20. What testing strategy would you use to verify that a FlyweightFactory actually returns the same shared instance for equivalent intrinsic state rather than creating duplicates?
The core test is an identity assertion: request a flyweight for a given key twice and assert that the two references are the same object using assertSame, not merely assertEquals, since equal-but-distinct objects would silently pass a value-equality check while failing the actual sharing guarantee. Complement this with a cache-size assertion after many repeated requests to confirm the cache did not grow proportionally to the number of calls.
@Test
void sameKeyReturnsSameInstance() {
Flyweight a = factory.get("oak");
Flyweight b = factory.get("oak");
assertSame(a, b);
}21. How would you write a unit test asserting that two logically equal flyweight requests return an identical object reference, and why does this matter for correctness?
You construct two separate but logically equivalent keys, for example two distinct String objects with the same characters, request flyweights for each, and assert reference identity with assertSame or the == operator rather than assertEquals.
@Test
void distinctButEqualKeysShareInstance() {
String key1 = new String("bold-12pt");
String key2 = new String("bold-12pt");
assertNotSame(key1, key2); // sanity check on the keys
assertSame(factory.get(key1), factory.get(key2));
}This matters because the whole memory-saving premise of Flyweight rests on identity sharing, not value equality; a factory that returns equal-but-different objects has silently become a plain object creator and provides none of the intended benefit.
22. Explain how the Flyweight pattern interacts with equals() and hashCode() overrides. Should flyweight objects rely on identity equality or value equality, and why?
Once a factory guarantees that equal intrinsic state always maps to the same shared instance, identity equality (the default Object.equals, i.e. reference comparison) and value equality become equivalent for correctly-obtained flyweights, so many flyweight classes deliberately do not override equals/hashCode at all and rely on default identity semantics.
Where you do need value-based equals/hashCode is on the lookup key type used by the factory's internal map, since that map must recognize two differently-constructed but logically identical keys as the same entry; that is separate from the flyweight object itself, which should generally be compared, and used in identity-sensitive collections, by reference.
23. Describe a real production bug where a team assumed flyweight objects were being reused but profiling revealed the factory was creating a new object per call because equals/hashCode of the key type were not implemented.
A team built a factory keyed by a custom StyleKey class holding a few fields, but forgot to override equals and hashCode, so it fell back to Object's identity-based implementations. Every lookup constructed a new StyleKey instance at the call site, which meant the map's get never matched an existing entry even for logically identical requests, and computeIfAbsent happily created a brand-new flyweight every single time.
equals/hashCode to StyleKey (or switching it to a record), after which cache hit rate jumped and memory usage dropped sharply.24. How would you measure, using a Java heap profiler, whether a Flyweight refactor actually reduced the memory footprint of an application, and what metrics would you look at?
Take a heap dump before and after the refactor under an equivalent workload, then in a tool such as VisualVM, JFR, or Eclipse MAT, compare the instance count and retained size of the class that used to be duplicated. A successful Flyweight refactor shows instance count for the shared class collapsing from proportional-to-workload down to roughly the number of distinct intrinsic combinations, with a corresponding drop in retained heap size.
Also watch allocation rate (bytes/sec allocated, visible in JFR's allocation profiling) and GC pause frequency/duration, since fewer short-lived objects typically means fewer and shorter young-generation collections, which is often the more user-visible win compared to raw heap size.
25. What is the risk of using mutable objects as intrinsic fields inside a flyweight, even if the flyweight itself is never reassigned after construction?
Making the flyweight's own fields final only prevents reassignment of the reference; it does nothing to stop the object that reference points to from being mutated internally. If a flyweight holds a final List<String> tags, any caller with access to that list can call tags.add(...) and mutate state visible to every other holder of the same shared flyweight.
final class Style {
private final List<String> tags; // final reference, but mutable contents!
List<String> getTags() {
return tags; // leaks a mutable reference
}
}The fix is to store defensive, immutable copies (List.copyOf(tags)) and expose them through unmodifiable views, so that true immutability, not just reference immutability, is guaranteed all the way down.
26. In a document processing system that renders millions of characters with shared glyph metadata, explain why per-character formatting like highlight color should NOT be baked into the flyweight.
Highlight color is a property of a specific occurrence of a character in a specific document at a specific moment, such as a user selecting a word and applying yellow highlighting; it is not a property shared by every occurrence of the letter "e" rendered in Arial 12pt. If highlight color were stored on the shared Glyph flyweight, highlighting one occurrence would incorrectly highlight every other occurrence of that same glyph everywhere in the document.
The correct design keeps highlight color as extrinsic state, stored alongside the position information for each character occurrence, and passed to the glyph's render method at draw time, exactly like x/y coordinates.
27. How would you extend a Flyweight-based icon cache in a desktop GUI application to support unloading icons that haven't been used recently, without breaking existing references held by clients?
You cannot forcibly invalidate a reference a client already holds in Java, so "unloading" really means the factory removing its own strong reference from the cache map so the icon becomes eligible for GC once no client references remain, while any client still actively holding a reference keeps a perfectly valid object.
private final Map<String, IconEntry> cache = new ConcurrentHashMap<>();
record IconEntry(Icon icon, AtomicLong lastAccess) {}
Icon get(String name) {
IconEntry entry = cache.computeIfAbsent(name, n -> new IconEntry(loadIcon(n), new AtomicLong(System.nanoTime())));
entry.lastAccess().set(System.nanoTime());
return entry.icon();
}
// background sweep evicts entries whose lastAccess() exceeds a thresholdA scheduled sweep evicts map entries whose lastAccess is older than a threshold, and any client that requests that icon again afterward simply triggers a fresh load and re-caching.
28. Discuss how the Flyweight pattern can be combined with the Composite pattern to represent a large tree of UI components where leaf nodes share rendering flyweights but the tree structure itself is not shared.
Composite builds a tree of nodes where leaves and composite containers implement a common interface; each individual node in that tree is a distinct object because it has a unique position in the hierarchy, unique children, and unique parent. What can still be shared is the rendering data each leaf delegates to, such as an icon or a style flyweight, so the leaf node itself stays lightweight and unique while the heavy visual data behind it is reused.
class LeafComponent implements UiNode {
private final IconFlyweight icon; // shared, looked up from factory
private final int x, y; // unique per node
void render(Graphics g) { icon.draw(g, x, y); }
}This way the tree's structural cost scales with the number of nodes, which is unavoidable, while the visual/rendering cost per node collapses to a shared reference.
29. What are the downsides of using an enum to implement flyweights in Java, and when is an enum-based flyweight a good fit versus a poor fit?
An enum is a natural, JVM-guaranteed singleton-per-constant mechanism, which makes it a convenient way to implement a small, fixed, compile-time-known set of flyweights, such as suit types in a card game or a handful of fixed log levels.
enum Suit { HEARTS, DIAMONDS, CLUBS, SPADES } // fixed, known set: good fitThe downside is that enum constants must all be known at compile time and cannot be created dynamically at runtime based on data, so it is a poor fit when the intrinsic key space is discovered at runtime, such as font-family-plus-size combinations parsed from a document, where a ConcurrentHashMap-backed factory is the correct tool instead.
30. Describe how you would implement a Flyweight pattern for HTTP header value objects in a high-throughput web server to reduce allocation pressure from common header combinations.
Many HTTP headers repeat identical values across huge numbers of requests, such as Content-Type: application/json or a fixed Cache-Control policy, so a header-value factory can intern these strings or wrapper objects rather than allocating a new object per request per header.
final class HeaderValues {
private static final ConcurrentMap<String, String> POOL = new ConcurrentHashMap<>();
static String intern(String value) {
return POOL.computeIfAbsent(value, v -> v);
}
}
response.setHeader("Content-Type", HeaderValues.intern("application/json"));Per-request data such as request IDs, timestamps, and correlation tokens remain extrinsic and are never pushed through this pool, since they are unique per request by definition and sharing them would be meaningless.
31. How does the Flyweight pattern differ from simple caching? Is every flyweight factory technically a cache, and is every cache a flyweight factory?
Every flyweight factory is technically a cache, in that it stores computed results keyed by input to avoid recomputation. But not every cache is a flyweight factory: a typical cache (like an HTTP response cache or a memoized computation) stores results for performance and may store mutable or context-specific data, whereas a Flyweight factory specifically enforces a design discipline around separating intrinsic from extrinsic state and guaranteeing the cached objects are immutable and safely shareable across unrelated callers.
The distinguishing feature of Flyweight is the design-level state split, not just the caching mechanism, which is why we call it a design pattern rather than merely an optimization technique.
32. What issues can arise from unbounded growth of a Flyweight factory's internal map when the intrinsic state space is effectively unbounded?
If the key space is effectively unbounded, for example keying flyweights by a user-supplied string that is rarely repeated, the cache map grows forever, consuming more memory than the naive unshared approach would have, since you now pay for both the map's bookkeeping overhead and the retained objects, with no compensating sharing benefit because few keys actually repeat.
33. Explain how you would apply an LRU eviction policy to a Flyweight factory cache using LinkedHashMap, and what trade-offs this introduces regarding flyweight lifecycle guarantees.
LinkedHashMap supports access-order iteration and an overridable removeEldestEntry hook, making it a simple way to cap a cache at a maximum size and evict the least-recently-used entry once that cap is exceeded.
Map<Key, Flyweight> cache = new LinkedHashMap<>(16, 0.75f, true) {
protected boolean removeEldestEntry(Map.Entry<Key, Flyweight> eldest) {
return size() > 500;
}
};
Map<Key, Flyweight> syncCache = Collections.synchronizedMap(cache);The trade-off is that this breaks the "once obtained, a given key always returns the same instance for the life of the process" guarantee, because eviction followed by a fresh request for the same key produces a new, distinct object; any code relying on long-term identity stability across the whole application lifetime must account for this, and LinkedHashMap itself is not thread-safe without external synchronization.
34. In a map-rendering application where map tile icons for thousands of points of interest need to be drawn, design a Flyweight solution and identify what state must be passed at render time versus stored on the flyweight.
A PoiIcon flyweight stores the intrinsic visual data: the icon bitmap, its category (restaurant, gas station, hospital), and its default color scheme, since these are identical for every restaurant marker on the map. Each point of interest instance stores only its own latitude, longitude, and a reference to the shared icon.
record PointOfInterest(PoiIcon icon, double lat, double lon) {
void render(MapCanvas canvas, double zoom) {
icon.drawAt(canvas, lat, lon, zoom); // lat/lon/zoom are extrinsic
}
}Zoom level is also extrinsic and passed at render time, since the same icon must scale differently depending on the current viewport, which is a property of the render call, not the icon itself.
35. What garbage collection implications does the Flyweight pattern have, and how can converting many short-lived objects into references to long-lived shared flyweights change GC pause behavior?
Without Flyweight, a workload that constructs and discards millions of small objects generates heavy churn in the young generation, which increases the frequency of minor GC cycles even though each pause may be short; with Flyweight, the shared objects are constructed once and become long-lived, quickly promoted to the old generation, while the per-use data left behind (extrinsic state) is typically much smaller and simpler.
The net effect is usually fewer, and often shorter, young-generation collections, because far less garbage is being produced per unit of work; however, if the shared objects are numerous enough to matter for old-generation occupancy, tuning may shift toward optimizing full/major GC behavior instead, so it is worth re-measuring GC logs after the refactor rather than assuming the change is purely beneficial.
36. Describe the anti-pattern of a 'god flyweight' where a class accumulates so many extrinsic-state parameters passed into its methods that the design becomes harder to use than the original unshared object. How would you refactor it?
A "god flyweight" happens when, in the effort to keep everything shareable, a team keeps moving fields to extrinsic state until a single render or compute method takes ten or fifteen parameters, at which point call sites become unreadable and error-prone, and the supposed simplification has made the API worse than the original monolithic object ever was.
// anti-pattern: too many extrinsic parameters
void render(Graphics g, int x, int y, int scale, int rotation,
Color tint, boolean selected, boolean hovered, float alpha, int zOrder) { ... }The fix is to group related extrinsic parameters into a small, purpose-built value object, such as a RenderContext record, so the method signature stays manageable while the underlying data is still supplied per call rather than shared on the flyweight.
37. How would you use the Flyweight pattern in a particle system simulation to represent millions of particles efficiently, distinguishing between per-particle-type intrinsic data and per-instance extrinsic data like position and velocity?
A ParticleType flyweight holds the sprite texture, blend mode, and base lifetime curve shared by every "spark" or "smoke puff" particle of that kind. The actual particle instances are represented not as full objects but as entries in primitive arrays: position, velocity, age, and a small integer index into the array of particle types, which keeps per-particle overhead to a handful of primitives rather than an object header plus fields.
float[] posX, posY, velX, velY, age;
int[] typeIndex; // references shared ParticleType[] table
ParticleType[] types; // small, fixed set, intrinsic dataThis combination of Flyweight for the type data with a structure-of-arrays layout for the extrinsic per-instance data is how particle systems handle millions of live particles without allocating millions of objects.
38. What role does immutability enforcement play in guaranteeing the correctness of a Flyweight implementation, and how would you enforce it with Java's type system?
Immutability is the safety property that makes sharing correct in the first place, so enforcing it at the type level, rather than trusting convention, removes an entire class of bugs. In Java, that means marking the class final to prevent subclasses from adding mutable state, marking all fields private final, never exposing mutable internals through getters, and using immutable collection types like those returned by List.copyOf.
public final class FontStyle {
private final String family;
private final int size;
private final boolean bold;
public FontStyle(String family, int size, boolean bold) {
this.family = family; this.size = size; this.bold = bold;
}
// only getters, no setters, no mutable fields exposed
}Java record types give you most of this for free: final fields, no setters, and a canonical constructor, which is why records are a natural fit for simple flyweights.
39. Explain the trade-off between using a HashMap-based flyweight factory versus a pre-populated array/enum-based lookup when the set of possible intrinsic states is small and known in advance.
When the intrinsic state space is small and fully known ahead of time, such as the 13 ranks or 4 suits in a card game, a pre-populated array or enum gives you O(1) direct-index or constant-reference lookup with zero hashing overhead and zero risk of cache-miss allocation races, at the cost of flexibility if the set ever needs to grow dynamically.
A HashMap-based factory is more flexible and handles an open-ended or runtime-discovered key space, but pays for that flexibility with hashing, bucket traversal, and (in the concurrent case) the overhead of thread-safe map operations. The right choice is to use the array/enum approach whenever the set is genuinely fixed and small, and reserve the map-based factory for cases where the key space is not known until runtime.
40. Describe a scenario in a font-rendering engine where failing to apply the Flyweight pattern for glyph objects caused an out-of-memory error, and how the fix restructured the class into intrinsic/extrinsic parts.
A PDF-rendering engine created a new RenderedGlyph object, complete with a rasterized bitmap for that character at that font/size, for every single character occurrence across a multi-thousand-page document, rather than once per distinct (character, font, size) combination. With a handful of fonts and sizes but millions of character occurrences, this produced millions of redundant bitmap copies and eventually an OutOfMemoryError during batch processing.
RenderedGlyph into an intrinsic GlyphBitmap (character, font, size, rasterized pixels) cached by a factory, and extrinsic per-occurrence data (page number, x, y) stored in a lightweight array. Memory usage dropped from scaling with character count to scaling with the much smaller number of distinct glyph/font/size combinations.41. How would you design the API of a FlyweightFactory so that client code cannot bypass it and construct flyweight objects directly, using Java access modifiers and package structure?
Put the flyweight class and its factory in the same package, give the flyweight class a package-private (or private, if the factory is a nested class) constructor, and expose only the factory's public get/getInstance method to the outside world. This makes it a compile error for code outside the package to call new Flyweight(...) directly.
package com.example.render;
public final class GlyphFactory {
private static final Map<GlyphKey, Glyph> CACHE = new ConcurrentHashMap<>();
public static Glyph get(GlyphKey key) {
return CACHE.computeIfAbsent(key, Glyph::new);
}
}
final class Glyph { // package-private constructor
Glyph(GlyphKey key) { ... }
}This is the same access-control technique used to make a Singleton's constructor unreachable from outside, applied here to guarantee the factory is the only path to instance creation.
42. What is the impact of the Flyweight pattern on CPU cache locality and object header overhead in the JVM, and why can reducing the number of live objects sometimes improve throughput beyond just saving heap space?
Every object on the Java heap carries a header, typically 12 to 16 bytes on a modern 64-bit JVM with compressed oops, regardless of how little actual data it holds; for very small objects, this header overhead can dwarf the payload itself. Flyweight reduces the sheer count of live objects, which directly reduces total header overhead and also reduces pointer-chasing, since many extrinsic-state records can now reference one shared object instead of each holding its own separately-allocated copy scattered across the heap.
Fewer, more centrally-located shared objects also improve CPU cache locality when iterating over collections of extrinsic-state entries, since the shared flyweight data is likely to already be warm in cache after the first access, whereas thousands of individually allocated near-duplicate objects would each cause a fresh cache line load.
43. Compare implementing the Flyweight pattern via a ConcurrentHashMap.computeIfAbsent() call versus double-checked locking with a plain HashMap. What subtle bugs can occur with each approach?
ConcurrentHashMap.computeIfAbsent is the simpler and generally safer choice, guaranteeing the mapping function runs atomically per key; its one subtle pitfall is that the mapping function must not attempt to modify the same map (including via recursive calls), or it can throw IllegalStateException or deadlock in some JDK versions.
// Double-checked locking with plain HashMap — error-prone
Flyweight get(Key key) {
Flyweight fw = cache.get(key);
if (fw == null) {
synchronized (this) {
fw = cache.get(key);
if (fw == null) {
fw = new Flyweight(key);
cache.put(key, fw); // plain HashMap: unsafe publication without proper memory barriers
}
}
}
return fw;
}Double-checked locking on a plain HashMap is much easier to get wrong: without the map itself providing safe publication guarantees, other threads can observe a partially-initialized map structure, and forgetting to synchronize the read path (only guarding the write) reintroduces the exact race the pattern was meant to prevent.
44. Describe how you would apply the Flyweight pattern to represent recurring log message templates in a logging framework, sharing the template/format string while keeping per-invocation arguments external.
A logging call site like log.info("Order {} shipped to {}", orderId, address) uses the same format string, "Order {} shipped to {}", every single time that line of code executes, potentially millions of times, so the parsed/compiled representation of that template is a natural flyweight, while orderId and address are extrinsic arguments supplied fresh on each call.
final class LogTemplate { // intrinsic: parsed once, shared
private final String[] segments;
private final int placeholderCount;
String format(Object... args) { // args are extrinsic
// interpolate segments with args
}
}Frameworks like SLF4J effectively do this internally: the format string is parsed once (or cached) rather than being re-parsed on every single logging call.
45. In a chess or board game engine, how would you use the Flyweight pattern to represent piece types while keeping board position as extrinsic state managed by the board itself?
There are only twelve distinct chess piece types (six per color), and every white pawn behaves identically to every other white pawn in terms of movement rules, valid captures, and point value, so PieceType is a natural flyweight holding movement rules and value as intrinsic state. The board itself is an 8x8 array of references to shared PieceType instances (or null for empty squares), with the square coordinates being the extrinsic context.
enum PieceType { WHITE_PAWN, BLACK_PAWN, WHITE_KNIGHT, /* ... */ }
PieceType[][] board = new PieceType[8][8];
board[1][4] = PieceType.WHITE_PAWN; // position is extrinsic, in the board array itselfSince the set of piece types is small and fixed, an enum-based flyweight (see question 29) is an especially good fit here.
46. What are the risks of applying the Flyweight pattern prematurely, before profiling shows an actual memory problem, and how would you justify or avoid this kind of speculative optimization to a team?
Applying Flyweight before you have evidence of a real memory or allocation problem adds indirection, a factory to maintain, and a stricter immutability discipline, all for a benefit that may never materialize if the object count or duplication rate turns out to be modest. It also makes the codebase harder to reason about, since developers must now remember which fields are intrinsic versus extrinsic even in code paths that never actually needed sharing.
The way to justify the pattern to a team is with a measurement: a heap dump or allocation profile showing a specific class dominating instance count or retained size, ideally quantified as "class X accounts for N% of live objects and Y MB retained," which turns the decision from speculative into evidence-based, and also gives you a concrete before/after metric to validate the refactor afterward.
47. How would you unit test that a Flyweight factory's cache does not grow without bound under a workload that generates many distinct intrinsic-state combinations, some of which repeat and some of which don't?
Drive the factory with a synthetic workload that mixes a small set of repeating keys with a stream of one-off unique keys, simulating realistic traffic, then assert that the cache size stabilizes near the expected bound (if using an LRU-capped cache) or, for an uncapped cache used deliberately with a known-small key space, assert the size matches the count of distinct keys rather than the total number of requests.
@Test
void cacheDoesNotExceedConfiguredBound() {
for (int i = 0; i < 100_000; i++) {
factory.get("key-" + (i % 50)); // only 50 distinct repeating keys
}
assertEquals(50, factory.cacheSize()); // not 100_000
}48. Explain how serialization interacts poorly with the Flyweight pattern, and how would you implement readResolve() to preserve sharing across deserialization?
Default Java serialization reconstructs a brand-new object graph on deserialization, meaning if you serialize two references to the same shared flyweight and deserialize them, by default you get two separate, non-identical objects, silently breaking the sharing guarantee the whole pattern depends on.
final class Suit implements Serializable {
static final Suit HEARTS = new Suit("Hearts");
private final String name;
private Suit(String name) { this.name = name; }
private Object readResolve() {
return switch (name) {
case "Hearts" -> HEARTS;
// ... other canonical instances
default -> throw new IllegalStateException("Unknown suit: " + name);
};
}
}readResolve() lets the class substitute the freshly deserialized object with the canonical shared instance immediately after deserialization, restoring the identity guarantee; enum-based flyweights get this behavior automatically and are generally the simpler choice when serialization is involved.
49. What is the difference between structural sharing as in Flyweight and copy-on-write strategies, and when would copy-on-write be a better alternative to a classic Flyweight implementation?
Flyweight shares one immutable object across many holders indefinitely; no holder ever expects to change it, so no copying is ever needed. Copy-on-write instead lets holders share a structure optimistically, but transparently makes a private copy the moment any holder wants to mutate its own view, which is useful precisely when you cannot guarantee upfront that a given piece of state will never need to diverge for one caller.
Copy-on-write is the better alternative when most callers only read the shared data but a minority occasionally need to apply local, caller-specific modifications without affecting others, such as a base configuration object that most services use unmodified but a few override selectively; classic Flyweight assumes no caller ever needs to diverge, which is a stronger and simpler guarantee when it actually holds.
50. How would you refactor a legacy Java codebase that instantiates a new Color or Font object on every paint call in a Swing/AWT application to use a Flyweight cache, and what performance improvement would you expect to measure?
A common Swing anti-pattern is g.setColor(new Color(230, 230, 230)) inside a paintComponent method that runs on every repaint, potentially dozens of times per second, allocating a new, functionally-identical Color object each time. The fix hoists these into cached constants or a small factory keyed by RGB value.
private static final Map<Integer, Color> COLOR_CACHE = new ConcurrentHashMap<>();
static Color colorOf(int rgb) {
return COLOR_CACHE.computeIfAbsent(rgb, Color::new);
}
// paintComponent now does:
g.setColor(colorOf(0xE6E6E6));Since Color and Font are already immutable in the JDK, this refactor is purely about reuse: expect a measurable drop in young-generation allocation rate and GC pause frequency during heavy repaint activity, visible in JFR allocation profiling or a simple -Xlog:gc comparison before and after.
Subscribe via email
About Rajesh
Senior Java developer with 10+ years of experience in enterprise application development, Spring Boot, and microservices architecture. I write in-depth Java and system design interview guides to help engineers crack technical interviews at top product companies.
Post a Comment
Add