In Java memory leaks are caused by poor program design where object references are long lived and the garbage
collector is unable to reclaim those objects.
Detecting memory leaks:
Use tools like JProbe, OptimizeIt etc to detect memory leaks.
Use operating system process monitors like task manager on NT systems, ps, vmstat, iostat, netstat etc on
UNIX systems.
Write your own utility class with the help of totalMemory() and freeMemory() methods in the Java Runtime
class. Place these calls in your code strategically for pre and post memory recording where you suspect to be
causing memory leaks. An even better approach than a utility class is using dynamic proxies or Aspect Oriented Programming (AOP) for pre and post memory
recording where you have the control of activating memory measurement only when needed.
in Emerging Technologies/Frameworks section).
Minimising memory leaks:
Design applications with an object’s life cycle in mind, instead of relying on the clever features of the JVM.
Letting go of the object’s reference in one’s own class as soon as possible can mitigate memory problems.
Example: myRef = null;
Unreachable collection objects can magnify a memory leak problem. In Java it is easy to let go of an entire
collection by setting the root of the collection to null. The garbage collector will reclaim all the objects (unless
some objects are needed elsewhere).
Use weak references (Refer Q32 in Java section) if you are the only one using it. The WeakHashMap is a
combination of HashMap and WeakReference. This class can be used for programming problems where you
need to have a HashMap of information, but you would like that information to be garbage collected if you are
the only one referencing it.
Free native system resources like AWT frame, files, JNI etc when finished with them. Example: Frame,
Dialog, and Graphics classes require that the method dispose() be called on them when they are no longer
used, to free up the system resources they reserve.
No comments:
Post a Comment