The garbage collector is a low-priority process that runs periodically and frees memory used by objects that are no longer needed. The garbage collector runs in the background, in parallel with the program, in a separate thread. The basis for garbage collection is not reference counting, but the separation of objects into two types - reachable and unreachable. An object is considered reachable (alive) if it is referenced by another reachable (living) object. Reachability is counted from threads. Running threads are always considered reachable (alive), even if no one references them. All objects in Java are stored in a special memory area called the heap. All objects in programs can be divided into two types - relatively speaking, simple objects and “long-lived” ones. “Long-lived” objects are those that have survived many garbage collections. Most often they will exist until the end of the program. As a result, the common heap, where all created objects are stored, was divided into several parts. The first part has a beautiful name - Eden (biblical “Garden of Eden”), objects go here after they are created. It is in this part that memory is allocated for new objects when we write new. Many objects can be created, and when space runs out in this area, the first, “fast” garbage collection begins. It must be said that the garbage collector is very smart and chooses a work algorithm depending on what is more in the heap - garbage or working objects. If almost all objects are garbage, the collector marks the “live” objects and moves them to another memory area, after which the current area is completely cleaned up. If there is little garbage and most of it is occupied by living objects, it marks the garbage, cleans it, and arranges the remaining objects. The memory area where all objects that survive at least one garbage collection are transferred is called Survival Space. Survival Space, in turn, is divided into generations. Each object is assigned a generation based on how many garbage collections it has experienced. If there is one, it belongs to “Generation 1”, if 5 – to “Generation 5”. Together, Eden and Survival Space form an area called Young Generation. In addition to Young Generation, there is another memory area in the heap - Old Generation (“old generation”). These are the very long-lived objects that have survived many garbage collections. It is more profitable to store them separately from all the others. And only when the Old Generation area is full, i.e. Even there are so many long-lived objects in the program that there is not enough memory, a complete garbage collection is performed. It processes not just one memory area, but generally all objects created by the Java machine. Naturally, it takes much more time and resources. That is why it was decided to store long-lived objects separately. When space runs out in other areas, so-called “rapid garbage collection” is carried out. It covers only one area, and due to this it is more economical and faster. At the end, When even the area for long-lived residents is already clogged, full cleaning enters the fray. Thus, the most “heavy” tool is used by the assembler only when it is no longer necessary.
2. What types of garbage collectors are there?
Java has seven types of garbage collectors:
Serial Garbage Collector
Parallel Garbage Collector
CMS Garbage Collector
G1 Garbage Collector
Epsilon Garbage Collector
Z garbage collector
Shenandoah Garbage Collector
3. What are “generations” of objects
All objects in Survival Space are divided into generations. Each object is assigned a generation based on how many garbage collections it has experienced. If there is one, it belongs to “Generation 1”, if 5 – to “Generation 5”.
4. What is SoftReference used for?
An object referenced only by soft references can be garbage collected if the program runs out of memory. If a program suddenly runs out of memory, before throwing an OutOfMemoryException, the garbage collector will delete all objects referenced by soft links and try to allocate memory to the program again. An object that is kept from dying only by SoftReference can survive any number of garbage collections and will most likely be destroyed if the program runs out of memory.
5. Example of using SoftReference
SoftReferences were specifically designed for caching. Let's assume that a client program frequently requests various data from a server program. Then the server program can cache some of them, using SoftReference for this. If objects kept from death by soft references take up most of the memory, then the garbage collector will simply delete them and that’s it.
6. Example of using WeakReference
If there are only weak references to an object, then this object is alive, but it will be destroyed during the next garbage collection. An object that is kept from dying by WeakReference alone will not survive the next garbage collection. But until it happens, you can get it by calling a method get()on WeakReference and calling its methods or doing something else. An example of using WeakReference is WeakHashMap.
7. Why WeakHashMap is needed
WeakHashMap is a HashMap whose keys are weak references - WeakReference. You store pairs of objects in a WeakHashMap - a key and a value. But WeakHashMap does not refer to the keys directly, but through WeakReference. Therefore, when objects used as keys become unreachable, they will be destroyed during the next garbage collection. This means that their values will be automatically removed from the WeakHashMap. WeakHashMap is very convenient for storing additional information for some objects. Firstly, it is very easy to obtain if you use the object itself as a key. Secondly, if an object is destroyed, both it and all data associated with it will disappear from the HashMap. For example, the program has a thread that monitors the work of some task objects and writes information about them to the log. Then this thread can store the tracked objects in such a WeakHashMap. As soon as objects are no longer needed, the garbage collector will delete them, and references to them from the WeakHashMap will be automatically deleted.
8. What is a logger
A Logger object is used to log messages for a specific system or application component. A log is a list of events that occurred. Most often, information about the method parameters with which it was called, all intercepted errors, and a lot of intermediate information is written to the log. The entire logging process consists of three parts.
The first part is collecting information.
The second part is filtering the collected information.
The third part is a recording of the selected information.
9. How to set up a logger
Add dependency to pom.xml.
Add the log4j.properties file to resources.
Typically, log4j logger settings are set in the log4j.properties file. In this file you can specify several appenders - objects into which data will be written.
Add to class with business logic private static final Logger log = Logger.getLogger(ххх.class);.
GO TO FULL VERSION