These problems fall into two categories:
premature deallocation (corrupted pointers) and incomplete deallocation (memory leaks).
In the case of incomplete deallocation, there are two subcases:
coding bugs and design bugs.
Coding bugs are language dependent.
In the case of C, this would involve free()ing less than was malloc()ed,
while in C++ this might involve using delete in lieu of delete[].
Design bugs, on the other hand, do not depend on the language;
instead, they involve simple programmer negligence.
In languages like C/C++, all memory management is handled by the programmer, so all of these problems can arise
the Java language and runtime together entirely eliminate the problems of corrupted pointers and code-level memory leaks.Here's how:
1-In Java, memory is allocated only to objects. There is no explicit allocation of memory, there is only the creation of new objects. (Java even treats array types as objects.)
2-The Java runtime employs a garbage collector that reclaims the memory occupied by an object once it determines that object is no longer accessible.
This automatic process makes it safe to throw away unneeded object references because the garbage collector does not collect the object if it is still needed elsewhere.
Therefore, in Java the act of letting go of unneeded references never runs the risk of deallocating memory prematurely.
3-In Java, it's easy to let go of an entire "tree" of objects by setting the reference to the tree's root to null; the garbage collector will then reclaim all the objects (unless some of the objects are needed elsewhere).
This is a lot easier than coding each of the objects' destructors to let go of its own dependencies (which is a coding-level problem with C++).
what about memory leaks caused by poor program design?
unnecessary object references originating in long-lived parts of the system prevent the garbage collector from reclaiming objects that are in fact no longer needed.
Another design flaw occurs "in the small," at the level of a faulty algorithm; the use of Collections objects in such cases will typically magnify the error.
As the technology improves, a suitably implemented JVM could help reduce the effects of such designed-in memory leaks by using the garbage collector to track object usage over time.
In conclusion: Design problems can be mitigated by letting go of object references in one's own classes as soon as one can
References:
http://www.javaworld.com/javaworld/javaqa/1999-08/04-qa-leaks.html?page=2
http://olex.openlogic.com/wazi/2009/how-to-fix-memory-leaks-in-java/
- Actually there is not to worry about the memory leak in Java.It is handled by Garbage Collector in Java.
But sometimes if there is java.lang.OutOfMemoryError Exception , memory leak is certainly strong suspect.
IF any application eats more & more system memory and never seems to return memory back to the system untill large amount ot physical memory allocation to that application then this is the sign of memory leak.
Also there is a common problem when we register a class as an event listener without bothering to unregister when the class is no longer needed.
We can prevent memory leaks by watching for some common problems
Collection classes, such as hashtables and vectors, are common places to find the cause of a memory leak
This is particularly true if the class has been declared static and exists for the life of the application. and many times member variables of a class that point to other classes simply need to be set to null at the appropriate time.
Reference:
http://www.erpgreat.com/java/memory-leak-in-java.htm
http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java
- Java Memory Leak Detection with JProfiler
http://www.youtube.com/watch?v=Dy7WZv5bEV4
- Java Performance - Eclipse.mp4
http://www.youtube.com/watch?v=jy39JEBSPkI
- Intertech - Complete Java Performance Tuning Training - Part 1
http://www.youtube.com/watch?v=YB2xvYCY4B8
- Plumbr - a tool for preventing and solving Java memory leaks
http://www.youtube.com/watch?v=3p-rwnJlGMY
- What is Memory Leak in java?
memory leak will occur if you put too many objects on the heap, I think that most of the time it will happen when you have some kind of a data structure and you keep on filling it while not removing unneeded objects.
For example, let say I'm keeping a Hash that contains all the phones that are currently in my factory.
If I forget to remove phones that left the factory towards customers - A memory leak exists in my program, since the hash will keep on growing. This is also the place to mention that some data structures (such as hash and arraylist) are doubling their sizes when they reach some predefined factor and so I can even run out of memory before I even use the entire potential of it holding my phones...
more common example would be if you hold connections to your server and forget to close them and remove them from your connection pool
http://www.linkedin.com/groups/What-is-Memory-Leak-in-70526.S.208104654?view=&gid=70526&type=member&item=208104654&trk=eml-anet_dig-b_nd-pst_ttle-cn
- Creating a memory leak with Java
a good way to create a true memory leak (objects inaccessible by running code but still stored in memory) in pure Java:
1-The application creates a long-running thread (or use a thread pool to leak even faster).
why application containers (like Tomcat) can leak memory like sieve if you frequently redeploy applications that happen to use ThreadLocals in any way.
(Since the application container uses Threads as described, and each time you redeploy the application a new ClassLoader is used.)
http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java
Thank you for the information.
ReplyDeleteVisit: Java Course in Pune