https://sematext.com/blog/java-garbage-collection/
In this tutorial, we will talk about how different Java Garbage Collectors work and what you can expect from them. This will give us the necessary background to start tuning the garbage collection algorithm of your choice.
Before going into Java Garbage Collection tuning we need to understand two things. First of all, how garbage collection works in theory and how it works in the system we are going to tune. Our system’s garbage collector work is described by garbage collector logs and metrics from observability tools like Sematext Cloud for JVM. We talked about how to read and understand Java garbage collection logs in a previous blog post.
Java Garbage Collection is an automatic process during which the Java Virtual Machine inspects the object on the heap, checks if they are still referenced and releases the memory used by those objects that are no longer needed.
Let’s take a quick look on when the object is ready to be collected by the garbage collection and how to actually request the Java Virtual Machine to start garbage collection.
To put it straight – you don’t have to do anything explicitly to make an object eligible for garbage collection. When an object is no longer used in your application code, the heap space used by it can be reclaimed. Look at the following Java code:
public Integer run() {
Integer variableOne = 10;
Integer variableTwo = 20;
return variableOne + variableTwo;
}
In the run() method we explicitly create two variables. They are first put on the heap, in the young generation heap. Once the method finishes its execution they are no longer needed and they start being eligible for garbage collection. When a young generation garbage collection happens the memory used by those variables may be reclaimed. If that happens the previously occupied memory will be visible as free.
The best thing regarding Java garbage collection is that it is automatic. Until the time comes, and you want and need to control and tune it, you don’t have to do anything. When the Java Virtual Machine will decide it’s time to start reclaiming the space on the heap and throwing away unused objects it will just start the garbage collection process.
If you want to force garbage collection you can use the System object from the java.lang package and its gc() method or the Runtime.getRuntime().gc() call. As the documentation states – Java Virtual Machine will do its best efforts to reclaim the space. This means that the garbage collection may actually not happen, this depends on the JVM. If the garbage collection happens it will be a Major collection which means that we can expect a stop-the-world event to happen. In general, using the System.gc() is considered a bad practice and we should tune the work of the garbage collector instead of calling it explicitly.
No matter what implementation of the garbage collector we use, to clean up the memory, a short pause needs to happen. Those pauses are also called stop-the-world events or STW in short. You can envision your JVM-based application’s working cycles in the following way:
[](data:image/svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20width%3D%221462%22%20height%3D%22191%22%20viewBox%3D%220%200%201462%20191%22%3E%3Cfilter%20id%3D%22c%22%3E%3CfeGaussianBlur%20stdDeviation%3D%2255%22%20%2F%3E%3C%2Ffilter%3E%3Cpath%20fill%3D%22%23bbb%22%20d%3D%22M0%200h1462v188H0z%22%2F%3E%3Cg%20filter%3D%27url(%23c)%27%20fill-opacity%3D%27.5%27%3E%3Cellipse%20fill%3D%22%23868686%22%20fill-opacity%3D%22.5%22%20rx%3D%221%22%20ry%3D%221%22%20transform%3D%22matrix(-145.29415%20-.18377%20.5719%20-452.15684%2066.2%2096.2)%22%2F%3E%3Cellipse%20fill%3D%22%23c5c5c5%22%20fill-opacity%3D%22.5%22%20rx%3D%221%22%20ry%3D%221%22%20transform%3D%22matrix(150.39258%20638.46464%20-635.64435%20149.72825%20865.7%2099.6)%22%2F%3E%3Cellipse%20fill%3D%22%239f9f9f%22%20fill-opacity%3D%22.5%22%20rx%3D%221%22%20ry%3D%221%22%20transform%3D%22matrix(161.1356%20-40.07414%2064.82996%20260.6772%2038.8%20110.5)%22%2F%3E%3Cpath%20stroke%3D%22%23a1a1a1%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M89.5%20187Q222.4%2082.8%20211.5%203.9%22%20stroke-width%3D%222.9%22%2F%3E%3Cpath%20fill%3D%22silver%22%20fill-opacity%3D%22.5%22%20d%3D%22M214.2%202.9h108.5v188.4H214.2z%22%2F%3E%3Cpath%20fill%3D%22%239f9f9f%22%20fill-opacity%3D%22.5%22%20d%3D%22M202.7%2065.7l5.7-80L140-82.8z%22%2F%3E%3Cpath%20stroke%3D%22%23bcbcbc%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M211.9%20149.5Q228.2%20277%20282.7%20277%22%20stroke-width%3D%222.9%22%2F%3E%3Cellipse%20fill%3D%22%23a0a0a0%22%20fill-opacity%3D%22.5%22%20rx%3D%221%22%20ry%3D%221%22%20transform%3D%22matrix(174.5817%20-52.37702%2028.96686%2096.55156%2033.2%2047.2)%22%2F%3E%3Cpath%20fill%3D%22silver%22%20fill-opacity%3D%22.5%22%20d%3D%22M214.2%202.9h188.4v188.4H214.2z%22%2F%3E%3Cpath%20fill%3D%22silver%22%20fill-opacity%3D%22.5%22%20d%3D%22M214.2%20168.5h45.6v22.8h-45.6z%22%2F%3E%3Cellipse%20fill%3D%22%23a0a0a0%22%20fill-opacity%3D%22.5%22%20rx%3D%221%22%20ry%3D%221%22%20transform%3D%22matrix(-143.3181%2028.4257%20-14.7028%20-74.12926%2066%2082.1)%22%2F%3E%3Cpath%20fill%3D%22silver%22%20fill-opacity%3D%22.5%22%20d%3D%22M271.2%2062.2l43.1-77.8%2030%2053.3L175.2-38z%22%2F%3E%3Cpath%20stroke%3D%22%23bebebe%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M298.7-31.5q-95.3-8.6-81.8%20253.8%22%20stroke-width%3D%222.9%22%2F%3E%3Cpath%20fill%3D%22silver%22%20fill-opacity%3D%22.5%22%20d%3D%22M304.8%20119l-30.1%2052.4L460%20.4%20208.8%20135.7z%22%2F%3E%3Cpath%20stroke%3D%22%23a1a1a1%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M-22-17Q43%204.8%20212.1%2049%22%20stroke-width%3D%222.9%22%2F%3E%3Cellipse%20fill%3D%22%23a0a0a0%22%20fill-opacity%3D%22.5%22%20rx%3D%221%22%20ry%3D%221%22%20transform%3D%22matrix(-33.51656%20-19.19586%2036.1986%20-63.20389%20161.2%2027.1)%22%2F%3E%3Cpath%20stroke%3D%22%23a0a0a0%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M-9.3%203q-24.2%2054.4%20352.5%20266.5%22%20stroke-width%3D%222.9%22%2F%3E%3Cpath%20stroke%3D%22%23bfbfbf%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M213.7%20144.1q44.5%2043.5%20167.4%2095%22%20stroke-width%3D%222.9%22%2F%3E%3Cpath%20stroke%3D%22%23a1a1a1%22%20stroke-opacity%3D%22.5%22%20fill%3D%22none%22%20d%3D%22M114.7%20145.1q74.5%2060%2094.3-29.7M88.4-15.2q127.1%20118%20119.5%20183.4%22%20stroke-width%3D%222.9%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
The first step of the cycle starts when your application threads are started and your business code is working. This is where your application code is running. At a certain point in time, an event happens that triggers garbage collection. To clear the memory, application threads have to be stopped. This is where the work of your application stops and the next steps start. The garbage collector marks objects that are no longer used and reclaims the memory. Finally, an optional step of heap resizing may happen if possible. Then the circle starts again, application threads are started. The full cycle of the garbage collection is called the epoch.