Memory leak using autoboxing
I followed the tutorial and below was an example of a memory leak for autoboxing.
package com.example.memoryleak;
public class Adder {
public long addIncremental(long l) {
Long sum=0L;
sum =sum+l;
return sum;
}
public static void main(String[] args) {
Adder adder = new Adder();
for(long ;i<1000;i++) {
adder.addIncremental(i);
}
}
}
Now I could figure out that unnecessary objects would be created due to autoboxing, but how this caused a memory leak, since I understand that a memory leak occurs when you hold a reference to a dead object. Now, in this case, once I get out of the FOR loop, there are no strong references to those objects Long
, how did this cause the memory leak?
Please note that I want to understand how this caused the memory leak, I know these objects are not needed.
source to share
The other answers are correct: this is not a memory leak.
The code you are showing creates an object at a very high speed; and they are garbage collected immediately . None of these "temporary" objects are forgotten; they all get the right to collect; and the GC collects them at some point.
Memory leak refers to situations in which the used memory is constantly increasing - without the objects ever being eligible for garbage collection.
Given a comment that asks for a "cache" example that uses a map:
- as long as there is only one (strong!) reference to a map object from another object "alive" in terms of GC, this map is "alive". And therefore: all objects stored in this map are alive (not entitled to GC)
- when the last reference to that map disappears, the map itself becomes GC-friendly. The same is true for values within a map - unless there is another reference to such a value that is still alive.
source to share
Please provide the link you provided:
Can you spot a memory leak?
This is where I made a mistake. Instead of using a primitive for the sum, I took the long (wrapper class) which is causing the memory leak. Due to automatic boxing sum = sum + l; creates a new object on each iteration, so 1000 unnecessary objects will be created. Please avoid mixing and matching between primitive and wrapper classes. Try to use the primitive as much as possible.
In fact, there is no memory leak here. Better to say, it produces some excess memory usage and garbage collection.
If you want to simulate real memory leak, refer to this question: Creating a memory leak with Java .
Also, as a result of being ignored adder.addIncremental(i);
, there may be some JVM optimizations for this code.
If you look at the memory plots, you can see that the memory usage is quite stable from the GC cycle to the cycle.
For example:
source to share
Can you spot a memory leak?
This is where I made a mistake. Instead of primitively long sum, I took Long (wrapper class), which is the reason for the memory leak. Due to automatic boxing sum = sum + l; creates a new object in each iteration, so 1000 unnecessary objects will be created.
This snippet from the tutorial is incorrect. In this example, you won't have memory leaks, but you won't have effective memory.
source to share