{"id":73668,"date":"2025-08-04T21:14:52","date_gmt":"2025-08-04T15:44:52","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=73668"},"modified":"2025-09-17T11:48:44","modified_gmt":"2025-09-17T06:18:44","slug":"java-memory-management-and-garbage-collection-explained","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/java-memory-management-and-garbage-collection-explained\/","title":{"rendered":"Java Memory Management and Garbage Collection Explained (Part 1)"},"content":{"rendered":"

Introduction<\/h2>\n

Java memory management refers to the process by which the Java Virtual Machine (JVM) allocates, organizes, and reclaims memory used by variables, methods, classes, and objects during program execution. It ensures efficient memory use by automatically managing object creation and destruction, helping developers avoid manual memory handling and common pitfalls like memory leaks.<\/p>\n

Types of Memory<\/h2>\n

In Java, memory is mainly divided into two core regions: the Heap<\/strong> and the Stack<\/strong>.<\/p>\n

Both are managed internally by the JVM to ensure efficient execution and memory allocation for various program components.<\/p>\n

Stack Memory :<\/h3>\n

Stack memory is a section of JVM memory that holds method call information along with their local variables. It follows the Last-In-First-Out (LIFO) principle, meaning the most recently called method is the first to be removed once execution completes.<\/p>\n

Stack memory is used to store:<\/strong><\/p>\n

    \n
  • Basic primitive data types<\/strong> such as int, long, double, and others.<\/li>\n
  • References<\/strong> to objects that reside in the heap memory<\/li>\n<\/ul>\n

    Additionally, variables in the stack have a specific scope <\/strong>\u2014 which defines where they are accessible. Whenever a method is invoked, the JVM creates a new stack frame to hold its local variables. These variables live only within the method\u2019s scope and are cleared from the stack when the method completes.. Once the method completes, its frame is removed from the stack, and all associated variables are cleared. Control then returns to the calling method, restoring its stack frame and scope.<\/p>\n

    Heap Memory :<\/h3>\n

    Within the JVM, the heap is used to hold all instances<\/strong> of objects<\/strong> that are created while the application runs. These objects are referenced by variables that reside in stack memory.<\/strong><\/p>\n

    Let’s take a simple example:\u00a0User userObj = new User();<\/strong><\/p>\n

    Here\u2019s what happens:<\/p>\n

      \n
    • Using the new<\/strong> keyword instructs the JVM to reserve memory in the heap for a newly created User object.<\/li>\n
    • The object is created in heap memory.<\/li>\n
    • A reference to that object is stored in the stack under the variable userObj<\/strong>.<\/li>\n<\/ul>\n

      The heap is a unified memory area shared across all threads within a JVM instance. This makes it essential to handle object access carefully in multi-threaded environments. Whereas S<\/strong>tack memory is created per thread<\/strong>. Every thread maintains its own separate stack, which keeps method calls and local variables isolated from those of other threads.<\/p>\n

      \"Diagram

      Diagram showing the relationship between stack and heap memory in Java.<\/p><\/div>\n

      Example :\u00a0<\/strong><\/p>\n

      \"Java

      Java code snippet demonstrating how variables in stack memory reference objects in heap memory, including primitives, string literals, and user-defined objects.<\/p><\/div>\n

      \"Diagram

      Diagram illustrating how variables in stack memory reference objects stored in heap memory during Java program execution.<\/p><\/div>\n

      As shown in the example above:<\/strong><\/p>\n

        \n
      • Primitive integer value is stored in stack memory.<\/li>\n
      • The string literals “Mohit” and “Ramtari” are stored in the String Pool<\/strong>, a part of the method area used for storing string literals.<\/li>\n
      • A MemoryManagement object is created in the heap memory<\/strong> and is referenced by the memoryManagement variable in the stack.<\/li>\n
      • A User object is also created in the heap and is referenced<\/strong> by two variables: userObject from the main method and user2Object from the dummyMethod.<\/li>\n
      • Once the dummyMethod completes execution and its closing bracket is reached, its stack frame is removed in Last-In First-Out (LIFO)<\/strong> order. As a result, all local variables within that method, including user2Object, are discarded, and control returns to the calling method (main in this case).<\/li>\n<\/ul>\n
        \"Diagram

        Diagram illustrating the state of memory after the execution of dummyMethod, showing the removal of its stack frame and how object references are affected.<\/p><\/div>\n

        Once the dummyMethod completes execution, control returns to the main method. Since there is no further code to execute after the call to dummyMethod, the closing bracket of the main method is reached. As a result, its scope also ends, and the corresponding stack frame is removed following the Last-In-First-Out (LIFO)<\/strong> order.<\/p>\n

        At this point, the stack memory is completely cleared, and all references stored in it are removed. The memory now looks like this:<\/p>\n

        \"Diagram

        Diagram showing the final memory state after the execution of both dummyMethod and main method, with the stack cleared and only heap objects remaining.<\/p><\/div>\n

        Now that the stack memory is cleared and all references have been removed, the objects in the heap memory remain without any active links<\/strong> pointing to them. This is the stage where the Garbage Collector (GC) steps in to manage unused objects. The Garbage Collector is responsible for automatically identifying and removing objects in the heap that are no longer referenced by any part of the program.<\/p>\n

        The JVM determines when the Garbage Collector should run. When the GC runs, it reclaims memory by cleaning up all unreachable objects, helping to ensure efficient memory utilization and prevent memory leaks.<\/p>\n

        Divisions of Heap Memory :<\/h3>\n

        The heap memory in Java is primarily divided into two main areas:<\/p>\n

          \n
        • Young Generation<\/li>\n
        • Old Generation (Tenured Generation)<\/li>\n<\/ul>\n

          In addition to the heap, there is also a separate memory area known as Metaspace<\/strong>, which is considered non-heap memory. It holds information about classes, including their structure, defined methods, and runtime constants. (Note: Metaspace replaced PermGen starting from Java 8.)<\/p>\n

          Young Generation : <\/strong>Young Generation refers to the section of heap memory where objects are first allocated upon creation.
          \nIt is further divided into:<\/p>\n

            \n
          1. Eden Space – It is the region where the new objects are first allocated in memory.<\/li>\n
          2. Survivor Space 0 (S0)<\/li>\n
          3. Survivor Space 1 (S1)<\/li>\n<\/ol>\n

            The two Survivor spaces (S0 and S1) work in a ping-pong fashion during garbage collection. During a Minor GC<\/strong>, objects that are still alive in the Eden space are moved to one of the Survivor spaces. Objects that survive multiple collections may eventually be promoted to the Old Generation<\/strong>.<\/p>\n

            \"Diagram

            Diagram illustrating the division of heap memory in Java, including Young Generation (Eden, Survivor 0, Survivor 1), Old Generation, and Metaspace (non-heap memory).<\/p><\/div>\n

            Let\u2019s explore how memory behaves when new objects are created.<\/strong><\/p>\n

            Suppose we create five objects: O1, O2, O3, O4,<\/strong> and O5<\/strong>.
            \nWhen these objects are instantiated, they are initially stored in the Eden space<\/strong> of the Young Generation within the heap memory.<\/p>\n

            The Eden space is specifically designed to hold newly created (short-lived) objects. Most of these objects will become unreachable quickly and are candidates for garbage collection during the next minor GC cycle.<\/p>\n

            \"Diagram

            Diagram showing the allocation of five objects within the Eden region of the Young Generation in Java’s heap memory.<\/p><\/div>\n

            Now, let\u2019s assume that objects O1<\/strong> and O2<\/strong> are no longer referenced by any variable. When the Garbage Collector (GC) runs, it applies the Mark and Sweep<\/strong> algorithm:<\/p>\n

            Mark Phase:<\/strong> The GC first scans the heap and marks all unreferenced objects, such as O1 and O2 in this case.
            \nSweep Phase:<\/strong> It then performs two actions:<\/p>\n

              \n
            • Removes the marked (unreachable) objects \u2014 O1 and O2 \u2014 from memory.<\/li>\n
            • Moves the surviving objects (O3, O4, and O5) to one of the Survivor spaces (either S0 or S1) and increments their age, which helps determine their eligibility for promotion to the Old Generation over time.<\/li>\n
            • After this GC cycle, the memory state changes accordingly:<\/li>\n<\/ul>\n
              \"Diagram

              Diagram showing the effect of Garbage Collection using the Mark and Sweep algorithm. Unreferenced objects O1 and O2 are removed from Eden, while surviving objects O3, O4, and O5 are moved to a Survivor space with their age incremented.<\/p><\/div>\n

              Object Movement and Promotion to Old Generation<\/strong>
              \nOn subsequent runs of the Garbage Collector (GC), if any of the objects (O3, O4, or O5) become unreferenced, they will be removed from memory. If they are still referenced, they will be moved to the other Survivor space (e.g., from S0 to S1), and their age is incremented by 1.<\/p>\n

              Objects continue moving back and forth between S0 and S1 across multiple GC cycles. This process continues until either:<\/p>\n

                \n
              1. The object becomes unreferenced (and is collected), or<\/strong><\/li>\n
              2. The object\u2019s age reaches a specified limit known as the tenuring threshold<\/strong>.
                \nOnce the threshold is reached, and the object is still alive, it is promoted to the Old Generation \u2014 a section of the heap meant for long-lived objects.<\/li>\n<\/ol>\n

                Minor GC vs. Major GC<\/strong><\/p>\n

                  \n
                • Minor GC takes place in the Young Generation and usually runs quickly and often, since most objects in this region have a short lifespan.<\/li>\n
                • Major GC (also called Full GC) occurs in the Old Generation, where long-lived objects reside. It is less frequent but more time-consuming, as it deals with a larger memory space and performs more thorough cleanup.<\/li>\n<\/ul>\n

                  Conclusion<\/h3>\n

                  Java\u2019s memory management efficiently handles object allocation and cleanup through stack and heap memory, along with automated garbage collection. Understanding how objects move through Eden, Survivor spaces, and into the Old Generation\u2014and the roles of Minor and Major GC\u2014helps developers write more optimized and reliable applications.<\/h3>\n

                  What\u2019s Next<\/p>\n

                  Stay tuned for Part 2, where we\u2019ll uncover how different garbage collectors work, when to use them, and how they manage memory over time.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

                  Introduction Java memory management refers to the process by which the Java Virtual Machine (JVM) allocates, organizes, and reclaims memory used by variables, methods, classes, and objects during program execution. It ensures efficient memory use by automatically managing object creation and destruction, helping developers avoid manual memory handling and common pitfalls like memory leaks. Types […]<\/p>\n","protected":false},"author":1843,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":164},"categories":[446],"tags":[7697,7700,4781,4844,7698,7695,7694,7696,3836,7703,7701,7699,7702,5823],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73668"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1843"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=73668"}],"version-history":[{"count":5,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73668\/revisions"}],"predecessor-version":[{"id":75884,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/73668\/revisions\/75884"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=73668"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=73668"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=73668"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}