Java Garbage Collection

Java Memory Management, với garbage collection được tích hợp sẵn, là một trong những ngôn ngữ tốt nhất hiện nay. Nó cho phép developer tạo ra các đối tượng mới mà không cần phải quan tâm tới allocation và deallocation, bởi vì garbage collector tự động thu hồi bộ nhớ để tái sử dụng. Cho phép phát triển nhanh các ứng dụng với ít dòng code hơn, trong khi loại bỏ memory leak và nhưng vấn đề về memory-related. Ít nhất là trên lý thuyết.

Trên thực tế, java garbare collection dường như hoạt động quá tốt, tạo và xóa rất nhiều đối tượng. Phần lớn các vấn đề về memory-management được giải quyết, nhưng phải trả giá bởi các vấn đề nghiêm trọng về performance. Để khiến garbage collection có thể sử dụng trong tất cả các tình huống sẽ dẫn tới một hệ thống phức tạp và khó có thể tối ưu hóa. 

How Garbage Collection Really Works

• Track tất cả các đối tượng LIVE, và các đối tượng khác coi là GARBAGE

HEAP

• Là vùng nhớ được sử dụng để cấp phát động
• Trong hầu hết các cấu hình hệ điều hành cho phép JVM quản lý HEAP
• Có 2 khía cạnh quan trọng:
• Việc tạo đối tượng xảy ra nhanh hơn bởi vì không cần đồng bộ hóa với hệ điều hành cho từng đối tượng. Một lần cấp phát đơn giản là lấy một vài phần trong một mảng bộ nhớ sau đó dịch con trỏ lên phía trước.
• Khi một đối tượng không còn được sử dụng nữa, garbage collector lấy tại bộ nhớ và sử dụng nó cho việc phát đối tượng sau này. Có nghĩa là không hề có việc xóa hay lấy lai bộ nhớ đối với hệ điều hành

• Tất cả đối tượng được cấp phát trên heap đều được quản lý bởi JVM bao gồm class object, static variables, thập chí cả code của nó. Chừng nào mà đối tượng còn được tham chiêu tới thì JVM sẽ xem nó ALIVE. Nếu một đối tượng không còn được tham chiếu tới nghĩa là unreachable bởi application code, garbage collector xóa nó đi và lấy lại bộ nhớ. What is the first reference in the tree???!!!

Garbage-Collection Roots — The Source of All Object Trees

• Mỗi một object tree phải có một hoặc nhiều root object. Chừng nào application còn reach root thì toàn bộ tree reachable. Nhưng khi nào thì root object được xem như reachable??? Các đối tượng đặc biệt gọi là garbage-collection root lúc nào cũng reachable vì thế bất kì đối tượng nào có một garbage-collection root tại root của nó.
• Có 4 loại GC root trong java:
1. Local variables: are kept alive by the stack of a thread. This is not a real object virtual reference and thus is not visible. For all intents and purposes, local variables are GC roots
2. Active java threads: are always considered live objects and are therefore GC roots. This is especically important for thread local variables.
3. Static variables: are referenced by their classes. This fact makes them de facto GC roots. Classes themselves can be garbage-collected, which would remove all referenced static variables. This is of special importance when we use application servers, OSGi containers or class loaders in general. We will discuss the related problems in the Problem Patterns section
4. JNI Refercences are Java objects that the native code has created as part of a JNI call. Objects thus created are treated specially because the JVM does not know if it is being referenced by the native code or not. Such objects represent a very special from of GC root, which we will examine in more detail in the Problem Patterns section. 

Một ứng dụng Java đơn giản sẽ có các GC root:

• Các local variable trong hàm main
• Main thread
• Các static variable của main class

Marking and Sweeping Away Garbage

• Để chỉ ra các đối tượng không còn được sử dụng, JVM chạy liên tục thuật toán mark-and-sweep. Có hai bước thực hiện:
1. The algorithm traverses all object references, starting with the GC roots, and marks every object found as alive
2. All of the heap memory that is not occupied by marked objects is relaimed. It is simply marked as free, essentially swept free of unused object.
   

Garbage collection is intended to remove the cause for classic memory leaks: unreachable-but-not-deleted objects in memory. However, this works only for memory leaks in the original sense. It’s possible to have unused objects that are still reachable by an application because the developer simply forgot to dereference them. Such objects cannot be garbage-collected. Even worse, such a logical memory leak cannot be detected by any software . Even the best analysis software can only highlight suspicious objects