I keep seeing the same class of bug in Java code reviews: someone says “I created an object,” but what they really created is a reference; or they say “this instance is shared,” when the sharing is happening through multiple references pointing at the same runtime allocation. These sound like word games—until you’re debugging a production issue where state “mysteriously” changes, caches return unexpected results, or a test passes alone but fails in a suite.\n\nThe terms object and instance are closely related in Java—so close that many developers treat them as synonyms. That’s usually fine for casual conversation, but it’s not fine when you need precision. When I’m teaching this (or using it myself while reasoning about code), I focus on one core idea: a class is a promise (shape + behavior), and an instance/object is the runtime thing that exists in memory and carries state.\n\nIf you internalize how Java ties together class, instance, object identity, and references, you’ll write clearer APIs, avoid aliasing bugs, and debug faster when a heap dump or a stack trace is all you’ve got.\n\n## The mental model I use: blueprint, runtime allocation, and handles\nA Java class is like a blueprint: it describes fields (state) and methods (behavior). At runtime, when you create something with new, the JVM allocates memory for it and runs initialization.\n\nNow the key distinction that prevents confusion:\n\n- I treat instance as “a specific occurrence of a class at runtime.”\n- I treat object as “the runtime entity you interact with through references—an instance with identity and behavior.”\n\nIn Java, those two are effectively describing the same runtime thing from two angles.\n\nWhere people get tripped up is a third concept:\n\n- A reference is the variable value that points to an object.\n\nIf you remember only one sentence, make it this: you don’t store objects in local variables; you store references to objects.\n\nThat single fact explains:\n\n- why a = b; doesn’t copy the object,\n- why passing an object to a method can mutate shared state,\n- why null is a valid value for a reference but not an “empty object.”\n\n### What “lives where” (stack vs heap)\nI don’t want you to memorize JVM internals, but I do want you to picture what your code means. A practical way to visualize Java at runtime is:\n\n- Objects/instances (for normal new allocations) live on the heap.\n- Local variables in methods live in stack frames, and if a local variable has an object type, its value is a reference (a handle/pointer-ish value) that points into the heap.\n- Fields live “inside” the object (instance fields) or “beside the class” (static fields) depending on whether they’re instance or static.\n\nThis is why aliasing happens: you can create a second variable without creating a second allocation.\n\n## Class vs instance: what exists when\nA class can exist (as a loaded type) even when no instances exist. The JVM can load Person.class, resolve it, link it, and keep it ready—while the heap contains zero Person instances.\n\nAn instance begins its life at runtime when you create it (typically with new, sometimes indirectly through reflection, deserialization, proxies, or native code).\n\nHere’s a concrete example that you can run as-is:\n\njava\npublic final class Person {\n private String name;\n private int age;\n\n public Person(String name, int age) {\n this.name = name;\n this.age = age;\n }\n\n public void sayHello() {\n System.out.println("Hello, my name is " + name + " and I‘m " + age + " years old.");\n }\n\n public static void main(String[] args) {\n // Two distinct instances of the Person class\n Person kumar = new Person("Kumar", 27);\n Person bob = new Person("Bob", 32);\n\n kumar.sayHello();\n bob.sayHello();\n }\n}\n\n\nWhen I say “two instances,” I mean:\n\n- two separate runtime allocations,\n- two independent copies of instance fields (name, age),\n- two identities (two different objects), even though they share the same class.\n\n### One class, many instances; one instance, one class\nIn everyday Java, each object is an instance of exactly one concrete runtime class (obj.getClass() returns a single Class). But one class can have many instances over time. That’s the whole point of using a class as a reusable definition.\n\nThere’s a related subtlety that becomes relevant when you use interfaces or inheritance: a reference has a static type and an object has a runtime type.\n\njava\nList xs = new ArrayList();\n// static type: List (the reference type)\n// runtime type: ArrayList (the object‘s class)\n\n\nWhen someone says “this is a List object,” I translate: the reference is typed as List, the object is an instance of some concrete class that implements List.\n\n## “Object” in Java: identity + state + behavior\nIn day-to-day Java, calling something an object emphasizes that it’s a full OOP entity:\n\n- Identity: it’s distinct from every other object, even if it has the same field values.\n- State: it carries instance fields.\n- Behavior: it can execute instance methods.\n\n### Identity: the part that matters for correctness\nIdentity is easiest to see with references and ==:\n\njava\npublic final class IdentityDemo {\n static final class Counter {\n int value;\n }\n\n public static void main(String[] args) {\n Counter a = new Counter();\n Counter b = new Counter();\n Counter c = a;\n\n a.value = 10;\n\n System.out.println(a == b); // false: different objects\n System.out.println(a == c); // true: same object, two references\n System.out.println(c.value); // 10\n }\n}\n\n\n- a and b refer to different objects (different instances).\n- c refers to the same object as a.\n\nWhen someone tells me “instances are unique,” I translate that into something operational: each object has exactly one identity, but it can have many references.\n\n### Equality: instance identity vs logical equality\nIn Java, == compares reference identity (same object or not). .equals() (when implemented) compares logical equality (same content, same business meaning).\n\nIf your domain is “customers,” two distinct instances might represent the same customer record:\n\n- same customerId (logical equality)\n- different objects (different identities)\n\nThat’s a common source of bugs in caches and sets.\n\nHere’s the thing I insist on in reviews: if a type is going to be used as a key in a HashMap or stored in a HashSet, it must have a correct and stable equals()/hashCode() story, and the fields used for equality must not change while the object is in the collection.\n\n## “Instance” in Java: a runtime occurrence of a class\nWhen I’m being precise, I say instance to highlight the runtime fact: it’s a specific occurrence created during execution.\n\nWhat comes with an instance:\n\n- instance fields (each instance gets its own copy)\n- instance methods (executed with a specific receiver: this)\n- instance initialization (constructors and field initializers)\n\n### Instance members vs static members (where confusion shows up)\nStatic members belong to the class, not the instance. This is where “object vs instance” discussions become useful, because the JVM’s behavior is not ambiguous.\n\njava\npublic final class StaticVsInstanceDemo {\n static final class Circle {\n // Instance state: each Circle has its own radius\n int radius;\n\n // Class state: shared across all Circle instances\n static int circlesCreated = 0;\n\n Circle(int radius) {\n this.radius = radius;\n circlesCreated++;\n }\n\n double area() {\n return Math.PI radius radius;\n }\n }\n\n public static void main(String[] args) {\n Circle small = new Circle(5);\n Circle large = new Circle(10);\n\n System.out.println("small area = " + small.area());\n System.out.println("large area = " + large.area());\n\n // Same static field accessed through two different instances (not recommended stylistically)\n System.out.println(small.circlesCreated);\n System.out.println(large.circlesCreated);\n\n // Recommended: access static through the class\n System.out.println(Circle.circlesCreated);\n }\n}\n\n\nI recommend always accessing static members through the class (Circle.circlesCreated) to keep your own mental model honest: static is class-level, instance is object-level.\n\n### The most common static/instance bug I see\nSomebody adds a static field because “I need to access it from a static method,” and now state is shared across every request, every test, and every thread. If the data is supposed to be per-user, per-request, or per-entity, static is a footgun.\n\nWhen I’m uncertain, I ask myself: “If I create 10 instances, should they share this state?” If the answer is no, it’s not static.\n\n## The “difference” in practice: object and instance are almost the same word—until they aren’t\nMost of the time in Java, an object is an instance of a class. The nuance I care about is what you’re trying to emphasize in a given conversation:\n\n- Say instance when you mean “a runtime occurrence of a class (with per-instance fields).”\n- Say object when you mean “an entity with identity that can be referenced, compared, synchronized on, and garbage-collected.”\n\nHere’s a table I use when mentoring:\n\n
I say…
\n
—
\n
Instance
\n
Object
\n
Reference
\n\nAnd here’s a “common interview table” rephrased in a way that matches real debugging:\n\n
Object
\n
—
\n
Runtime entity you interact with
\n
Usually via new (or indirectly)
\n
Identity (one object)
\n
Through references
\n\nIf you’re thinking “these look the same,” you’re not wrong. In Java, they generally describe the same thing. The practical win is recognizing when the real culprit is neither word—it’s the reference.\n\n## The part that prevents bugs: references are not objects\nThis is where I see the most expensive mistakes.\n\n### Aliasing: two names, one instance\njava\npublic final class AliasingBugDemo {\n static final class UserPreferences {\n boolean darkMode;\n }\n\n public static void main(String[] args) {\n UserPreferences prefs1 = new UserPreferences();\n prefs1.darkMode = false;\n\n // No copy happens here. prefs2 points to the same object.\n UserPreferences prefs2 = prefs1;\n\n prefs2.darkMode = true;\n\n // prefs1 changed because there‘s only one instance.\n System.out.println(prefs1.darkMode); // true\n }\n}\n\n\nIf you say “I created another object,” you’ll misdiagnose the issue. You created another reference.\n\n### Parameter passing: Java passes references by value\nJava is pass-by-value, but the value being passed can be a reference. The result is that methods can mutate shared instance state:\n\njava\npublic final class PassByValueDemo {\n static final class Account {\n int balanceCents;\n }\n\n static void deposit(Account account, int amountCents) {\n // Mutates the instance that the reference points to\n account.balanceCents += amountCents;\n\n // Reassigning the parameter changes only the local reference\n account = new Account();\n account.balanceCents = 0;\n }\n\n public static void main(String[] args) {\n Account a = new Account();\n a.balanceCents = 1000;\n\n deposit(a, 250);\n\n System.out.println(a.balanceCents); // 1250\n }\n}\n\n\nIn my experience, once you can explain why reassigning account doesn’t “replace” the caller’s object, you’ve graduated from memorizing rules to understanding the runtime.\n\n### null: absence of a reference, not an “empty instance”\nA reference can be null. An object cannot be “null.”\n\nSo this:\n\njava\nPerson p = null;\n\n\nmeans “p points to nothing.” It does not mean there is a Person instance with empty fields.\n\nI recommend two modern practices (still relevant in 2026):\n\n- Use Optional for return values where absence is expected.\n- Use nullness annotations (and IDE/static analysis) for boundaries where null is unavoidable.\n\n## How instances are created in real systems (not just new)\nMost teaching examples stop at new. Real applications create instances in other ways, and those pathways often affect identity, lifecycle, and expectations.\n\n### 1) Factories (including static factories)\nFactories are my default recommendation when:\n\n- you want validation before creation,\n- you may return cached instances,\n- you want different implementations behind an interface.\n\njava\npublic final class EmailAddress {\n private final String value;\n\n private EmailAddress(String value) {\n this.value = value;\n }\n\n public static EmailAddress of(String raw) {\n String normalized = raw == null ? "" : raw.trim().toLowerCase();\n if (!normalized.contains("@")) {\n throw new IllegalArgumentException("Invalid email: " + raw);\n }\n return new EmailAddress(normalized);\n }\n\n public String value() {\n return value;\n }\n}\n\n\nYou still get an instance/object. The difference is you didn’t expose new, so you control the rules.\n\nA deeper point: a factory can return an existing instance. That means “call constructor” and “get instance” are not equivalent once you introduce factories. That matters for identity-sensitive code (like synchronization or == checks).\n\n### 2) Dependency injection containers\nDI containers create instances for you and may control their scope:\n\n- singleton: one instance shared\n- request-scoped: one per request\n- prototype: a new instance each time\n\nIf your teammate says “this object is a singleton,” what they often mean is: “the container returns the same instance each time.” That’s object identity, not class structure.\n\nThis is also where I see confusion between “stateless service” and “singleton instance.” A singleton can be stateless (safe to share). A singleton that holds per-request state is a production incident waiting to happen.\n\n### 3) Serialization/deserialization\nDeserialization can produce instances without calling your constructors the way you expect (depending on mechanism), which affects invariants and initialization logic. When debugging “how did we get this impossible state,” the creation path matters.\n\nIf you use Java serialization (or any serializer that bypasses constructors), I recommend explicitly defending invariants:\n\n- validate after deserialization (where your framework allows it)\n- consider using a serialization proxy pattern\n- keep serialized classes immutable when possible\n\n### 4) Proxies and bytecode-generated classes\nAOP, mocking frameworks, and ORM libraries can wrap your classes in proxies. The runtime object might not be the class you wrote, but it’s still an object with identity and behavior. When you compare classes with getClass() or rely on exact types, proxies can surprise you.\n\nIf you want “is this logically a Foo,” prefer instanceof Foo (or better, program to an interface). If you want “is this exactly Foo,” understand you’re opting into proxy pain.\n\n## Modern Java patterns that make the object/instance story clearer\nJava has pushed more developers toward immutability and value-style modeling. That changes how often identity matters.\n\n### Records: instances that represent values well\nRecords are excellent when you want instances that are primarily data carriers with well-defined equality.\n\njava\npublic record Money(String currency, long cents) {\n public Money {\n if (currency == null| currency.isBlank()) {\n throw new IllegalArgumentException("currency is required");\n }\n if (cents < 0) {\n throw new IllegalArgumentException("cents must be non-negative");\n }\n }\n\n public Money add(Money other) {\n if (!this.currency.equals(other.currency)) {\n throw new IllegalArgumentException("currency mismatch");\n }\n return new Money(this.currency, this.cents + other.cents);\n }\n}\n\n\nThis still creates objects/instances, but your code tends to rely less on identity and more on value equality—meaning fewer aliasing surprises.\n\n### Immutability reduces “shared instance changed under me” bugs\nWhen instances can’t change state after construction, aliasing becomes far less dangerous:\n\n- Two references to the same immutable instance are usually fine.\n- Two references to the same mutable instance often cause subtle bugs.\n\nIf you’re building modern services, I recommend defaulting to immutable types for domain models and reserving mutability for narrowly-scoped components (buffers, builders, caches).\n\n### Virtual threads and concurrency: identity becomes a debugging anchor\nWith modern concurrency (including virtual threads), you can have huge numbers of concurrent tasks. When logs show “same instance across tasks,” that’s a critical signal.\n\nI don’t want you obsessing over the word “instance,” but I do want you to be able to answer:\n\n- Is this shared state or just shared class code?\n- Do multiple threads touch the same object identity?\n- Is the object safe to share?\n\nIf you can’t answer those, concurrency bugs will eat your week.\n\n## Common mistakes I watch for (and how I fix them)\n### Mistake 1: Confusing “two variables” with “two objects”\nSymptom: state changes in one place unexpectedly show up somewhere else.\n\nRoot cause: aliasing (multiple references to the same instance).\n\nHow I fix it depends on the intent:\n\n1) If you truly need a separate instance, I make the copy explicit.\n\njava\npublic final class CopyDemo {\n static final class Settings {\n int timeoutMs;\n boolean retriesEnabled;\n\n Settings(int timeoutMs, boolean retriesEnabled) {\n this.timeoutMs = timeoutMs;\n this.retriesEnabled = retriesEnabled;\n }\n\n // Explicit copy constructor (shallow copy)\n Settings(Settings other) {\n this.timeoutMs = other.timeoutMs;\n this.retriesEnabled = other.retriesEnabled;\n }\n }\n\n public static void main(String[] args) {\n Settings a = new Settings(1000, true);\n Settings b = new Settings(a); // new instance\n\n b.timeoutMs = 500;\n\n System.out.println(a.timeoutMs); // 1000\n System.out.println(b.timeoutMs); // 500\n }\n}\n\n\n2) If sharing is desired but mutation is the problem, I make the shared object immutable.\n\n3) If sharing is accidental, I narrow the scope of the reference so it can’t leak (return copies, not internals).\n\n### Mistake 2: Using == for “same content”\nSymptom: comparisons randomly fail, especially with String, boxed numbers, or objects loaded from different layers (DB vs cache vs API).\n\nReality: == is identity. If you want logical equality, you need .equals().\n\nI keep this rule simple:\n\n- Use == only when you mean identity (or for enums).\n- Use .equals() for value comparison (and handle null safely).\n\njava\nString a = new String("hi");\nString b = new String("hi");\nSystem.out.println(a == b); // false\nSystem.out.println(a.equals(b)); // true\n\n\nAnd yes, string interning can make == appear to “work” sometimes. That’s a trap, not a feature.\n\n### Mistake 3: Mutable keys in hash-based collections\nSymptom: HashMap.get(key) returns null even though you “just put it in.”\n\nCause: the key’s hashCode() changes after insertion because fields used for equality were mutated.\n\njava\nimport java.util.;\n\npublic final class MutableKeyBug {\n static final class UserKey {\n String tenant;\n String userId;\n\n UserKey(String tenant, String userId) {\n this.tenant = tenant;\n this.userId = userId;\n }\n\n @Override public boolean equals(Object o) {\n if (!(o instanceof UserKey other)) return false;\n return Objects.equals(tenant, other.tenant) && Objects.equals(userId, other.userId);\n }\n\n @Override public int hashCode() {\n return Objects.hash(tenant, userId);\n }\n }\n\n public static void main(String[] args) {\n Map m = new HashMap();\n UserKey k = new UserKey("t1", "u1");\n m.put(k, "value");\n\n k.userId = "u2"; // key mutated after insert\n\n System.out.println(m.get(k)); // null (usually)\n }\n}\n\n\nFix: use immutable keys (records are great here), or never mutate fields used in equality.\n\n### Mistake 4: “Defensive copy” isn’t optional for mutable internals\nSymptom: a caller passes a List into a constructor, and later changes the list, silently mutating your object’s state.\n\nFix: copy on the way in, copy (or expose unmodifiable views) on the way out.\n\njava\nimport java.util.;\n\npublic final class DefensiveCopyDemo {\n public static final class Team {\n private final List members;\n\n public Team(List members) {\n // copy-in to prevent caller aliasing\n this.members = List.copyOf(members);\n }\n\n public List members() {\n // safe to return: it‘s already unmodifiable\n return members;\n }\n }\n}\n\n\nWhen I see a class store a mutable reference directly, I assume a future bug unless the class is clearly documented as “views over mutable state.”\n\n### Mistake 5: Treating “singleton instance” as “thread-safe”\nSymptom: data races, weird counters, occasional corrupted state under load.\n\nSingleton is about how many instances exist. Thread-safety is about how the object behaves when shared. They’re orthogonal.\n\nFix: either make the singleton stateless/immutable, or guard mutable state with concurrency primitives, or confine state per-thread/per-request.\n\n## A deeper look at identity (because it leaks into real code)\nEven if you never talk about “object identity” explicitly, the JVM and standard library use it all over the place. Three common examples:\n\n1) synchronized (lock) { ... } uses the identity of the object chosen as the monitor.\n2) System.identityHashCode(obj) gives you an identity-based hash independent of obj.hashCode().\n3) Garbage collection traces and heap dumps care about identities and references.\n\n### hashCode() vs System.identityHashCode()\nIf a class overrides hashCode() to represent value semantics, then hashCode() is no longer about identity. When I need a debugging ID for “this specific object,” I use System.identityHashCode(obj) in logs.\n\njava\nstatic String id(Object o) {\n return o == null ? "null" : o.getClass().getSimpleName() + "@" + Integer.toHexString(System.identityHashCode(o));\n}\n\n\nThis won’t give a globally unique identifier, but it’s good enough to spot aliasing and “same instance reused across requests” issues quickly.\n\n### Why choosing the lock object matters\nIf you do this:\n\njava\nsynchronized (new Object()) {\n // ...\n}\n\n\nYou have effectively no synchronization, because every thread locks a different instance.\n\nIf you do this:\n\njava\nprivate final Object lock = new Object();\n\npublic void critical() {\n synchronized (lock) {\n // ...\n }\n}\n\n\nNow you have a stable identity serving as a lock. The entire mechanism relies on object identity, which is one reason I sometimes say “object” instead of “instance” in concurrency conversations: I want the team to picture the monitor/identity, not just “some class occurred.”\n\n## Copying: “new reference” vs “new instance”\nWhen people say “copy,” they often mean one of three different operations. I make them choose which one they mean:\n\n1) Copy the reference (aliasing): b = a;\n2) Shallow copy (new object, same nested references): new Foo(a) where fields are copied as-is\n3) Deep copy (new object graph): recursively copy nested objects\n\n### Shallow copy is common (and often correct)\nShallow copy is the right choice when nested state is immutable or intentionally shared.\n\n### Deep copy is expensive and easy to get wrong\nDeep copy is only correct when you need isolation from mutations across an entire object graph. It’s also expensive: it increases allocations and GC pressure, and it can be O(n) or worse depending on structure size. I only deep-copy when the bug cost is higher than the runtime cost—and I document the reason.\n\n### Cloning is rarely my first choice\nCloneable and Object.clone() exist, but they’re not a modern Java design sweet spot. I prefer:\n\n- copy constructors\n- static factories like Foo.copyOf(foo)\n- builders for complex objects\n- immutability to avoid copying in the first place\n\n## Production scenarios where “object vs instance” precision pays off\n### Scenario 1: Cache bugs (identity vs equality)\nIf your cache key is “customerId,” your key type should behave like a value. If your key is “this specific request handler instance,” it behaves like an identity. Mixing these is how you get memory leaks or zero cache hits.\n\nThe question I ask is: “Do we want multiple instances with the same logical data to map to the same cache entry?” If yes, your key uses .equals(). If no, you’re in identity-land.\n\n### Scenario 2: ORMs and entities (identity is part of the model)\nIn persistence layers, you often have entities where identity matters (a row in a DB) and value objects where content matters (like Money, Email, Address).\n\n- Value object: I want equality by value; records are excellent.\n- Entity: I want an identifier (like id) and I am careful about equality semantics, because equality that changes after persistence causes collection bugs.\n\nThis isn’t just academic. It affects whether Set.contains() works and whether dirty-checking works predictably.\n\n### Scenario 3: Test suite flakiness (shared mutable singletons)\nIf tests pass individually but fail as a suite, I look for shared mutable objects:\n\n- static mutable state\n- singletons holding caches\n- reused fixtures\n- mutable global configuration\n\nNine times out of ten, the fix is: reduce sharing, reset between tests, or make the shared object immutable.\n\n## Performance considerations (practical, not micro-benchmark theater)\nI don’t want you to fear object allocation, but I do want you to recognize when identity-heavy design creates performance costs.\n\n### Allocation and GC pressure\nCreating many short-lived instances increases allocation rate and garbage collection work. In a typical service, the difference between “allocate 10 objects per request” and “allocate 10,000 objects per request” is the difference between steady p99 latency and occasional latency spikes.\n\nI use ranges, not fake precision:\n\n- A design that reduces allocations by 20%–60% can produce noticeable latency improvements under load.\n- A design that increases allocations by 2x–10x often shows up as GC churn and worse tail latency.\n\n### Escape analysis and optimization\nModern JVMs can optimize away some allocations (scalar replacement) when an object doesn’t “escape” a method or thread. Identity-sensitive features block this optimization. For example, if you synchronize on an object or call System.identityHashCode() on it, the JVM must preserve identity, which reduces optimization options.\n\nMy rule: don’t contort design for escape analysis, but be aware that “identity as a feature” has a runtime cost.\n\n### Object pooling is usually the wrong lever\nPeople reach for object pools to “reduce allocation.” In modern Java, pooling normal objects often hurts more than it helps because it:\n\n- increases contention\n- increases complexity\n- keeps objects alive longer (worsening GC behavior)\n\nI reserve pooling for specialized cases (large buffers, direct memory, expensive-to-create native resources) where I can prove it helps.\n\n## A debugging playbook: how I tell references from instances in minutes\nWhen I suspect aliasing or unintended sharing, I do a few concrete things.\n\n### 1) Log identity intentionally\nI add a temporary log with System.identityHashCode() (or use a debugger watch) so I can see if two code paths touch the same object.\n\n### 2) Check .equals() usage where identity is required\nIf code uses .equals() to decide whether to synchronize, or to decide whether two references “are the same object,” that’s wrong. Identity uses ==.\n\n### 3) Check hashCode() usage where value equality is required\nIf code uses == for business comparisons, I fix it to .equals() (or compare IDs).\n\n### 4) Look for the stateful singleton\nIn services, the most common accidental sharing is a singleton with mutable fields: counters, caches, “current user,” “last request,” etc. If it’s truly shared, it must be thread-safe and test-safe.\n\n### 5) Minimize reference leaks\nIf an object exposes internal mutable references (getters returning a mutable list, map, array), I assume aliasing bugs. I lock it down with immutable wrappers or copies.\n\n## Alternative approaches that prevent object/instance confusion entirely\nIf your team keeps hitting aliasing and identity issues, I don’t try to “teach harder.” I change the design to make the wrong thing difficult.\n\n### Approach 1: Prefer immutable domain models\nImmutable objects make sharing safe. Two references to the same instance are not scary if the instance cannot change.\n\n### Approach 2: Use value-based types for keys and DTOs\nRecords and small final classes with correct equals()/hashCode() reduce the number of identity-related bugs.\n\n### Approach 3: Confine mutable objects\nIf something must be mutable (builders, buffers, accumulators), I keep it local:\n\n- method-local variables\n- thread-local confinement\n- request scope\n\nI avoid sharing mutable instances across threads unless I have a clear concurrency model.\n\n## Quick recap (the version I want you to remember)\n- A class is a definition (fields + methods).\n- An instance is a runtime occurrence of a class.\n- An object is that runtime entity with identity/state/behavior (in Java, usually the same thing as “instance”).\n- A reference is the value stored in variables/fields that points to an object.\n\nIf you want one diagnostic question that catches most bugs: Did we create a new instance, or did we create a new reference to an existing instance?\n\n## FAQ (the common “but what about…” questions)\n### “Are object and instance always identical in Java?”\nIn normal Java programming, yes: when you say “object” you mean an instance. I only separate the words to communicate intent: “instance” highlights instantiation and per-instance state; “object” highlights identity and interactions (locking, GC reachability, aliasing).\n\n### “Is Java pass-by-reference?”\nNo. Java is pass-by-value. When the value is a reference, you can mutate the object through that reference, but you cannot rebind the caller’s variable by reassigning the parameter.\n\n### “Why does a = b not copy the object?”\nBecause a and b are references. Assignment copies the reference value, not the heap allocation it points to.\n\n### “When is == correct?”\n- Identity comparisons: “are these the same object?”\n- Enums\n- null checks\n\nFor content equality, use .equals() (or compare stable IDs).\n\n### “What’s the best way to avoid these bugs on a team?”\nIf I had to choose only three rules:\n\n1) Default to immutable types for domain data.\n2) Don’t expose mutable internals; use defensive copies.\n3) Treat static mutable state as hazardous material (use it only with strong reasons).\n\nIf you build around those, you’ll stop caring about the object/instance terminology because the design makes the dangerous cases rare—and when they do happen, you’ll diagnose them quickly by thinking in references and identity.
