Created
July 12, 2011 19:09
-
-
Save kimchy/1078717 to your computer and use it in GitHub Desktop.
native memory leak with GarbageCollectorMXBean#getLastGcInfo
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
import java.lang.management.GarbageCollectorMXBean; | |
import java.lang.management.ManagementFactory; | |
import java.util.List; | |
public class TestMemoryLeak { | |
public static void main(String[] args) throws Exception { | |
while (true) { | |
List<GarbageCollectorMXBean> gcMxBeans = ManagementFactory.getGarbageCollectorMXBeans(); | |
for (GarbageCollectorMXBean gcMxBean : gcMxBeans) { | |
((com.sun.management.GarbageCollectorMXBean) gcMxBean).getLastGcInfo(); | |
} | |
} | |
} | |
} |
No, since there is nothing to clean.
Not entirely true - that List of MBeans will hang around for a while until the GC runs and evicts it. If you loop fast enough before the GC is triggered, you can wipe your memory.
Thats heap memory, not RES memory. Heap wise all is well, and things get collected.
Time to fire up YourKit!
I stumbled across this gist while looking for more information about this HotSpot bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7066129
Thats the bug I opened :)
Hah, I wondered whether that was the case—I just figured there should be a connection between the two!
@kimchy: do you have a workaround for this? Can you confirm such kind of bugs for the other MXBeans, too?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Could this just be that GC isn't having enough time to clean up as you loop through?