Threads share the address space of the process that created it; processes have their own address.
Threads have direct access to the data segment of its process; processes have their own copy of the data segment of the parent process.
Threads can directly communicate with other threads of its process; processes must use inter-process communication to communicate with sibling processes.
Threads have almost no overhead; processes have considerable overhead.
New threads are easily created; new processes require duplication of the parent process.
Threads can exercise considerable control over threads of the same process; processes can only exercise control over child processes.
Changes to the main thread (cancellation, priority change, etc.) may affect the behavior of the other threads of the process, changes to the parent process does not affect child processes.
Threads have direct access to the data segment of its process; processes have their own copy of the data segment of the parent process.
Threads can directly communicate with other threads of its process; processes must use inter-process communication to communicate with sibling processes.
Threads have almost no overhead; processes have considerable overhead.
New threads are easily created; new processes require duplication of the parent process.
Threads can exercise considerable control over threads of the same process; processes can only exercise control over child processes.
Changes to the main thread (cancellation, priority change, etc.) may affect the behavior of the other threads of the process, changes to the parent process does not affect child processes.
Both have an id, set of registers, state, priority, and scheduling policy.
Both have attributes that describe the entity to the OS.
Both have an information block.
Both share resources with the parent process.
Both function as independent entities from the parent process.
The creator can exercise some control over the thread or process.
Both can change their attributes.
Both can create new resources.
Neither can access the resources of another process.
Both have attributes that describe the entity to the OS.
Both have an information block.
Both share resources with the parent process.
Both function as independent entities from the parent process.
The creator can exercise some control over the thread or process.
Both can change their attributes.
Both can create new resources.
Neither can access the resources of another process.
: How would you detect and minimize memory leaks in Java?
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.
Minimizing memory leaks:
In Java, typically memory leak occurs when an object of a longer lifecycle has a reference to objects of a short life cycle. This prevents the objects with short life cycle being garbage collected. The developer must remember to remove the references to the short-lived objects from the long-lived objects. Objects with the same life cycle do not cause any issues because the garbage collector is smart enough to deal with the circular references
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 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.
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.
Minimizing memory leaks:
In Java, typically memory leak occurs when an object of a longer lifecycle has a reference to objects of a short life cycle. This prevents the objects with short life cycle being garbage collected. The developer must remember to remove the references to the short-lived objects from the long-lived objects. Objects with the same life cycle do not cause any issues because the garbage collector is smart enough to deal with the circular references
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 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