AI Course
    NEW
    Placements

    Progress

    0%

    What is Software Design?High-Level vs Low-Level Design — Drawing the BoundarySoftware Architecture vs Software DesignFunctional vs Non-Functional RequirementsThe Software Design Process and Design ThinkingCharacteristics of Good Software DesignCommon Software Design MistakesHow to Read and Write Design DocumentsThe Framework: How to Approach LLD Problems

    Introduction to OOP and the Java Memory ModelClasses, Objects, and the this KeywordConstructors and Object InitializationEncapsulation and Access ModifiersAbstraction : Interfaces vs Abstract ClassesInheritance and Its TypesPolymorphism : Compile-Time vs RuntimeAssociation, Aggregation, and CompositionDependency RelationshipsGenerics and Type SafetyThe Golden Rule : Composition Over Inheritance

    Introduction to Design PrinciplesSingle Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion PrincipleDRY, KISS, and YAGNI PrinciplesHigh Cohesion and Loose CouplingLaw of DemeterSeparation of Concerns and Information HidingDesigning for Testability : The Ultimate Proof of Loose Coupling

    Why UML Matters in LLDClass DiagramsSequence DiagramsActivity DiagramsState DiagramsComponent and Object DiagramsUsing UML Effectively in InterviewsCommon UML Mistakes to Avoid

    What Are Design Patterns?History and the Gang of FourCategories of Design PatternsHow to Choose a Design PatternAnti-Patterns and Common MisuseDesign Patterns Interview Strategy

    Creational Patterns OverviewSingleton Pattern: Including Thread-Safe and Bill Pugh ImplementationsFactory Method PatternAbstract Factory PatternBuilder and Fluent Builder PatternPrototype PatternFactory vs Builder : When to Use WhichReal-World Usage of Creational Patterns

    Structural Patterns OverviewAdapter PatternBridge PatternComposite PatternDecorator PatternFacade PatternProxy PatternFlyweight PatternAdapter vs Facade vs ProxyReal-World Usage of Structural Design Patterns — How Spring Security Uses Filters and Proxies

    Behavioral Patterns OverviewStrategy PatternObserver PatternCommand PatternChain of ResponsibilityTemplate Method PatternState PatternMediator PatternIterator PatternMemento PatternVisitor PatternStrategy vs State — Key DifferencesReal-World Usage of Behavioral Patterns

    Introduction to Domain ModelingIdentifying Entities and Value ObjectsAggregates and Aggregate RootsDomain ServicesRepositories in Domain DesignBusiness Rules ModelingDomain EventsDesigning Rich vs Anemic Domain ModelsPutting It Together — Full Domain Model Walkthrough

    Introduction to API Design — Principles and GoalsREST Principles and Resource ModelingDTO Design and Mapping Strategies — MapStruct and JacksonRequest and Response DesignInput Validation DesignError Handling and Standardized Error ResponsesPagination, Filtering and SortingAPI Versioning StrategiesIdempotency in APIsAPI Security BasicsDesigning Internal vs External APIs

    Introduction to Persistence DesignThe Repository Pattern — Spring Data JPA Under the HoodDAO vs Repository PatternTransactions and ACID PropertiesUnit of Work PatternOptimistic vs Pessimistic LockingLazy Loading vs Eager Loading and the N+1 ProblemCaching FundamentalsWrite-Through vs Write-Back vs Cache-AsidePersistence Design Best PracticesDesigning for Data Consistency in Concurrent Systems

    Introduction to Concurrency — Threads vs ProcessesThread LifecycleThread Class vs Runnable vs CallableThe Executor Framework and Thread PoolsSynchronization and LocksReentrantLock and ReadWriteLockSemaphores and Countdown LatchesConcurrent Collections — ConcurrentHashMap and FriendsFuture and CompletableFuture for Async DesignThread Communication — Wait, Notify, NotifyAllCommon Concurrency Problems — Deadlock, Starvation, Race ConditionsDesigning Thread-Safe ClassesConcurrency Design Best Practices

    Introduction to Event-Driven ArchitectureThe Publisher-Subscriber ModelObserver Pattern vs Pub-Sub — Where They DifferEvent Modeling — Designing Good EventsMessage Queues — Concepts and Internal DesignEventual Consistency and What It Means for Object DesignEvent Sourcing — Concepts and When to Use ItCQRS — Command Query Responsibility SegregationCommon Pitfalls in Event-Driven Systems

    Logging Fundamentals and Best PracticesAudit LoggingMonitoring and Metrics DesignHealth ChecksRetry Mechanisms and Backoff StrategiesCircuit Breaker PatternRate Limiting AlgorithmsFeature FlagsDesigning for Observability — Putting It All Together

    How to Approach Any LLD Case Study — The 45-Minute FrameworkDesign a Parking LotDesign an Elevator SystemDesign a Vending MachineDesign an ATM MachineDesign a Chess GameDesign Tic-Tac-ToeDesign Snake and LadderDesign a Library Management SystemDesign a Logging FrameworkDesign an Inventory Management SystemDesign a Car Rental SystemDesign a Hotel Booking SystemDesign a URL ShortenerDesign Splitwise

    Advanced LLD — What Changes at the Senior LevelDesign a Movie Ticket Booking System — Handling Concurrency and LockingDesign an E-Commerce Shopping Cart and Order FlowDesign a Notification System — Internal Class OrchestrationDesign a Rate LimiterDesign a Job SchedulerDesign a Real-Time Chat System — WebSocket Handlers and Message Queues at the Class LevelDesign a Pub-Sub System Like Kafka — Internal Data Structures of the BrokerDesign a Payment Processing SystemRequirement Gathering Techniques for InterviewsIdentifying Entities and Relationships Under PressureChoosing Design Patterns in an InterviewDiscussing Trade-Offs ConfidentlyCommon LLD Interview MistakesMock LLD Interview Walkthrough — End to EndWhat to Do After the Interview — Learning from Every Session

    Introduction to OOP and the Java Memory Model

    Learning Objectives#

    1. State what object-oriented programming gives you that structured code does not, and what it costs.
    2. Trace where every variable actually lives, on the stack or on the heap, and explain why primitives and references behave differently.
    3. Explain why most Java "memory bugs" are reference bugs, not allocation bugs.

    Introduction#

    Object-oriented programming is a way of organizing a program around objects, bundles of state and behavior that can be created, referenced, and discarded independently. Java is a language that forces the model on you. Everything except the primitives is an object, every object lives in a heap, and every variable you touch is either a primitive value or a reference to something in that heap.

    The Java memory model is the physics under that abstraction. You can write correct code for years without naming it, and you can write confident buggy code for years without naming it too. This article is the foundation for everything else in the chapter: classes, inheritance, polymorphism, all of them assume you know what an object is, where it lives, and what a reference actually is.

    Problem Statement#

    A junior engineer is asked why a method returns an old value after another method already updated it. The answer "it was a copy" is accepted and nothing changes. The real answer lives in the memory model. The value was a primitive, so it was copied by value into the method. Or the value was an object, so the reference was copied and both names point at the same heap object. The two cases behave completely differently, and the engineer who cannot see the difference is guessing at every synchronization bug, every stale cache, every accidental shared mutation.

    The failure is concrete. A team debugs a race for a week. The field is mutable and shared, and everyone who reads the code reads the variable, not the reference. The fix, "make it immutable," is applied as a rule, not as a consequence. The engineer who understands that a reference is the only thing standing between two threads and one heap object fixes it in an afternoon and can explain why.

    Core Concept#

    Start with the two regions where your program's data lives.

    The stack is per-thread, fast, and tiny. Every time a method is called, the JVM pushes a frame onto the thread's stack. The frame holds the method's local variables and bookkeeping. When the method returns, the frame is popped and its contents are gone. Stack storage is allocated by moving a pointer and freed by moving it back. Under the base model, primitives and references that are local to a method are stored on the stack, and object data lives on the heap; the escape analysis section below is the one place the JVM breaks that rule.

    The heap is shared by all threads, slower, and large. Every object created with new lives there. Objects in the heap are not freed by the programmer. The garbage collector reclaims them when nothing references them anymore. A reference is a handle, a pointer in disguise, that tells the JVM where in the heap the object lives.

    Here is the shape of it.

    Diagram: where stack variables and heap objects sit, and how references connect them.

    STACK HEAP doSomething() String s -> int x = 7 main() int total = 42 Person p -> int flag = 1 Person name: String age: int = 29 String value: "Alice"

    Read the diagram from the bottom left. main() holds a primitive total and a reference p. The primitive is a value sitting in the frame. The reference is a pointer to a Person object in the heap. A second method doSomething() has its own frame with its own primitive x and its own reference s. Nothing is shared between the frames except what the references point at. The Person object holds its own references too, one to a String for the name. Every arrow is a reference, and a reference is the only way two parts of the program see the same object.

    The rule that follows, and it is the rule this whole article stands on: primitives are copied by value, references are copied by value, and objects are never copied by assignment. When you assign Person q = p, you copy the reference. Now two names point at one object. When you pass p to a method, you copy the reference again. Mutating q.age changes what p sees, because there is only one object. Mutating a local int changes nothing outside the method, because the int was copied as a value.

    That single distinction explains most Java behavior that looks like magic or bugs. The stale value returned from a method is usually a primitive copy or an object reference whose state was read at the wrong time. The "shared state" bug is usually a reference that escaped a scope and is now reachable from two threads. The immutable class is the design that makes the reference safe to share, because nobody can reach through it to mutate.

    A few consequences of the model that engineers trip on repeatedly. Local primitives and references are thread-safe by default because each thread has its own stack; the danger is always an object reached through a shared reference. Method-local objects are not thread-safe just because they are local, if the reference escapes and someone else gets it. And == on references compares the pointer, not the contents, which is why two Strings with the same text can fail == while .equals succeeds.

    Real Production Usage#

    java.util.concurrent is the standard library's answer to the shared-reference problem. The classes in that package exist because objects on the heap are reachable from multiple threads and the reference gives no protection on its own. ConcurrentHashMap exists because a plain HashMap shared through references will corrupt itself under concurrent writes. The point is not the classes, it is the underlying model they assume: shared heap, reference-based access, no implicit synchronization.

    The JVM's escape analysis is a quiet confirmation of the model. When the JVM proves an object never escapes the method that created it, it can allocate that object on the stack or in registers instead of the heap, and it can even avoid allocating it at all. You cannot see this happening, and you should not try to control it. It is evidence that the model is exactly what the earlier diagram drew: the stack holds whatever cannot be seen elsewhere, and the heap holds whatever can.

    Strings deserve a mention because they are the most common object in every Java program and the source of the most "is it a copy" confusion. A String is an object on the heap, but its contents are immutable, so sharing a reference to a String is safe. The language even interns string literals, reusing one object for the same literal text, which is why == can sometimes work on strings and usually should not be relied on.

    Common Mistakes#

    The most common mistake is treating primitives and references as if they behave the same. Engineers who learned C think of everything as a value and are surprised when an object "changes" through a copied reference. Engineers who learned Python think of everything as a reference and are surprised that int arithmetic never affects the caller. Java sits in the middle: primitives are values, objects are reached by reference, and there is no keyword that changes that.

    The second mistake is thinking new allocates on the stack or that you can somehow control where things go. You cannot. The JVM decides, the escape analyzer decides, the garbage collector decides. The only thing you control is whether you hand the reference to someone else. Most "memory leaks" in Java are not allocations, they are references kept alive by a collection or a cache when the object is no longer needed.

    The third mistake is using == on objects to test equality. On primitives == compares values. On references it compares addresses. The two strings that look identical and compare unequal are not a JVM quirk, they are two objects. The engineer who memorized "use equals" without the memory model behind it will still be surprised by the next reference trap.

    Interview Perspective#

    Every OOP interview opens with the model whether the interviewer says so or not. The question "is Java pass by value or pass by reference" is the memory model wearing an interview costume. The weak answer is the one-word version, "by value," because it is technically right and explains nothing. The strong answer says: primitives are passed by value, references are passed by value, and because objects are only ever reached through references, what you can do through the reference survives the call.

    The stronger candidate demonstrates it. "When I pass an object to a method and the method mutates it, the caller sees the mutation, because both hold copies of the same reference to one heap object. When I reassign the reference inside the method, the caller does not see it, because reassignment only changed the local copy." That sentence contains the whole model.

    Expected follow-ups: what happens when you assign one object variable to another, and why can two strings with the same characters be different objects? Both reward the candidate who answers from the model, stack, heap, reference, not from a memorized rule.

    Knowledge Check#

    A method receives an int and a List, increments the int, and adds an element to the list. Back in the caller, the int is unchanged and the list has the new element. Explain both outcomes using stack, heap, and references.

    Two threads each run the same method. The method creates a local HashMap, writes to it, and returns it to no one. Why is this safe? Then change one line so the map is assigned to a field, and explain why it stops being safe.

    String a = "hi"; String b = new String("hi"); Then a == b is false. Using the memory model, explain what == actually compared, and whether a and b could ever be the same reference.

    Key Takeaways#

    • Primitives live in the stack frame as values; objects live in the heap and are reached only through references.
    • Assignment and method calls copy values, including references, so copying a reference shares one object.
    • == compares references on objects, which is why equality needs .equals.
    • Most concurrency and stale-data bugs are reference bugs: a shared object reached from two places.

    What's Next#

    The model says objects live in the heap and variables reach them through references, which is all well drawn, but none of it says where an object's shape comes from. That shape is the class. The next article, Classes, Objects, and the this Keyword, takes the first step from the model to code: what a class declares, what an object actually instantiates, and why the this reference is the handle an instance uses to find its own fields.

    Want to Master Spring Boot and Land Your Dream Job?

    Struggling with coding interviews? Learn Data Structures & Algorithms (DSA) with our expert-led course. Build strong problem-solving skills, write optimized code, and crack top tech interviews with ease

    Learn more

    Last updated on Aug 18, 2026

    Was it helpful?

    Subscribe to our newsletter

    Read articles from Coding Shuttle directly inside your inbox. Subscribe to the newsletter, and don't miss out.

    Previous
    The Framework: How to Approach LLD Problems
    Next
    Classes, Objects, and the this Keyword