A Java back-end system is faced with such a big load that garbage collector cannot handle and there are memory leaks. How can this be resolved?
Asked
Active
Viewed 374 times
0
-
3That's not how the Java GC works... – Adrian Petrescu Jan 09 '11 at 04:03
-
How to find a Java Memory Leak: http://stackoverflow.com/questions/40119/how-to-find-a-java-memory-leak – Mitch Wheat Jan 09 '11 at 05:16
-
1Are you using finalizers? The GC can behave strangely (and often very non-optimally) when finalizers are in the mix. – Daniel Pryden Jan 09 '11 at 06:23
-
1Its easy to prove to yourself that the GC doesn't leak under load. I suggest you do that as an exercise and you can move onto finding the real problem. – Peter Lawrey Jan 09 '11 at 08:57
-
Agree with Peter - take a heap dump and analyse with JHAT... – Fakrudeen Jan 09 '11 at 09:28
-
This seems a bit too much like homework, like those "case studies" in which they give you a scenario and ask for what might be the cause. The text is even worded like that... – user541686 Jan 09 '11 at 22:32
4 Answers
2
i highly doubt that. memory leaks, unless by native code, is really a case of memory bloat. Memory bloat is just objects having strong references that are never nulled out.
MeBigFatGuy
- 28,272
- 7
- 61
- 66
2
In Java, the only way you can end up with a memory leak is by holding onto a reference that you no longer need. Since your application still has access to the reference, the garbage collector won't be able to clean it up, and there is really no way from the garbage collector's perspective to know it is a leak.
The only thing to be done about it is to fix the leaks. As to how to find and detect them... I unfortunately don't have very many suggestions. Perhaps you could add code to your unit tests to verify that functions release memory that they don't need anymore? Or you could run your unit tests with the VM memory greatly reduced to determine which units are responsible for the most allocations? There are some patterns that can commonly result in a leak. For example, holding onto a substring of a larger string (e.g. if you read a file into a string), since the substring mainains a reference to the string it comes from. I suppose a program could be written to detect this and other common patterns that lead to leaks. However, I am not aware of any currently available program that does this sort of likely leak detection.
Michael Aaron Safyan
- 93,612
- 16
- 138
- 200
1
Unless you're using an unusual JVM implementation, memory "leaks" only really occur when you hold on to objects much longer than needed. If Java detects that an object is still reachable, it will never collect it as it might affect program semantics.
If you're interested in cutting down on memory usage, try breaking references to objects you don't need any more, or use WeakReferences or WeakHashMaps to have objects stored in a way that they can be reclaimed automatically.
If you'd like to try to track down what exactly is sitting in memory wasting space, you might want to check out this paper on detecting potential memory leaks by looking at object accesses. This tool apparently works quite well, though I'm not that familiar with it.
Hope this helps!
templatetypedef
- 362,284
- 104
- 897
- 1,065
-
so the tool the paper references, SWAT, sounds interesting, but Googling doesn't reveal an actual implementation to download. Or am I missing something? – orangepips Jan 09 '11 at 05:02
-
Hmmm... I don't actually know where to get a copy. :-( I'll let you know if I find anything. – templatetypedef Jan 09 '11 at 05:07
0
jmap is your friend. There are some leaks in the current (sun/oracle) JVM but I highly doubt the OP is speaking about. Finalizers are just similar to phantom references (impl by java.lang.ref.FinalReference; they dont mess the GC on its right own, making an object available by finalize method is something different)
bestsss
- 11,796
- 3
- 53
- 63