Uncovering Memory Leaks Using NetBeans Profiler
2013-10-29 08:16
260 查看
Contributed by Jiri Sedlacek
This articles discusses how to use the NetBeans Profiler to locate memory leaks in a Java application.
Wikipedia says. This can happen for any program written in any programming language and Java is no exception.
Many users think that the Java VM releases unused objects from memory automatically, but that's not always the case. There are several scenarios when objects cannot be released and memory leaks occur. One common scenario is when a single object with large
memory consumption may be unintentionally held in memory, for example a
references to that object(s) in a heap walker tool.
This article will cover the second scenario, when there are many small objects that are continuously accumulating without being released. This type of leak can be more difficult to detect because typically it's not related to any concrete action and does
not use a noticeable amount of memory until the program has run for a long time. This scenario is dangerous especially with Java EE applications that are expected to run for long periods of time. After some time the leak starts to consume memory and may
slow down performance of the application or cause an
Even if your application seems to be working without any problems, before releasing your application it's always a good idea to verify that your application does not contain any potential memory leaks. For this purpose the NetBeans Profiler offers you
special metrics which can reliably uncover large amounts of continuously leaking small objects - the
Surviving Generations metrics. You can start the application in Monitoring mode without any profiling overhead and watch the graph to see if the application leaks over time.
a Generation is a set of instances created within the same GC interval (between two garbage collections)
a Surviving Generation is a Generation that survives at least one garbage collection. The number of survived garbage collections - the generation's age - is its unique identifier
Surviving Generations (metrics) value is the number of different Surviving Generations that are currently alive on the heap (number of Generations with different generation ages)
Typically there are several long-lived objects (like an application's main
Most applications also have short-lived objects which are created very frequently (such as
If we merge the two above cases, the total number of Surviving Generations in typical applications is quite stable. You may have long-lived objects representing, for example, 3 Surviving Generations, and short-lived objects representing, for example, 5
Surviving Generations, which means there will be about 8 Surviving Generations during the application's runtime.
Of course, in some application, for example a Swing application, dialogs and other components are created during run time and as a result the number of Surviving Generations grows a bit. But after some period of time the number of Surviving Generations
should become stable because all long-lived objects have already been created and newly-created short-lived objects are periodically being released from the heap.
However, if there is a memory leak in an application which prevents newly-created objects from being released from the heap (for example objects stored in a
the number of Surviving Generations whose generation's age differ by one unit increases, and that's exactly what the Surviving Generations metrics is able to detect regardless of how much memory is wasted by such a leak. That's why using the Surviving Generations
metrics can help you discover a memory leak much sooner, before it consumes the entire heap and causes an
download and install the
NetBeans Profiler installer package.
NetBeans IDE.
Open the project that you want to check for possible memory leaks.
Choose Profile > Profile Project from the main menu to start profiling the project.
Alternatively, choose Attach Profiler if you want to attach the NetBeans Profiler to an external application.
Choose the Monitor mode and click Run. (You don't need to monitor application's threads.)
This articles discusses how to use the NetBeans Profiler to locate memory leaks in a Java application.
What's a Memory Leak?
"Memory leak is a particular kind of unintentional memory consumption by a computer program where the program fails to release memory when no longer needed" asWikipedia says. This can happen for any program written in any programming language and Java is no exception.
Many users think that the Java VM releases unused objects from memory automatically, but that's not always the case. There are several scenarios when objects cannot be released and memory leaks occur. One common scenario is when a single object with large
memory consumption may be unintentionally held in memory, for example a
Projectinstance in NetBeans IDE when the project has already been closed. Another common scenario is when small objects are constantly being added to a
Collectionover time but they are never removed from that
Collection, for example caching coordinates in a graphics editor or a game.
How Can I Detect a Memory Leak?
In the first scenario, when a single (or few) object remains in memory after some action, memory leak detection is typically done by comparing memory snapshots taken before the action to snapshots taken after the action and then searching for unnecessaryreferences to that object(s) in a heap walker tool.
This article will cover the second scenario, when there are many small objects that are continuously accumulating without being released. This type of leak can be more difficult to detect because typically it's not related to any concrete action and does
not use a noticeable amount of memory until the program has run for a long time. This scenario is dangerous especially with Java EE applications that are expected to run for long periods of time. After some time the leak starts to consume memory and may
slow down performance of the application or cause an
OutOfMemoryErrorcrash without any visible cause.
Even if your application seems to be working without any problems, before releasing your application it's always a good idea to verify that your application does not contain any potential memory leaks. For this purpose the NetBeans Profiler offers you
special metrics which can reliably uncover large amounts of continuously leaking small objects - the
Surviving Generations metrics. You can start the application in Monitoring mode without any profiling overhead and watch the graph to see if the application leaks over time.
What Do The Surviving Generations Metrics Mean?
Surviving Generations metrics cannot be easily defined with just one line, so let's make a three-line definition:a Generation is a set of instances created within the same GC interval (between two garbage collections)
a Surviving Generation is a Generation that survives at least one garbage collection. The number of survived garbage collections - the generation's age - is its unique identifier
Surviving Generations (metrics) value is the number of different Surviving Generations that are currently alive on the heap (number of Generations with different generation ages)
Typically there are several long-lived objects (like an application's main
JFrameetc.) in an application. The generation's age increases during the application's run time but still represents one or a few Surviving Generations.
Most applications also have short-lived objects which are created very frequently (such as
Dimensionetc.) but these objects are released very soon, typically within only a few garbage collections. This means that they represent only a few Surviving Generations (with generation's age of 1, 2, 3 etc.).
If we merge the two above cases, the total number of Surviving Generations in typical applications is quite stable. You may have long-lived objects representing, for example, 3 Surviving Generations, and short-lived objects representing, for example, 5
Surviving Generations, which means there will be about 8 Surviving Generations during the application's runtime.
Of course, in some application, for example a Swing application, dialogs and other components are created during run time and as a result the number of Surviving Generations grows a bit. But after some period of time the number of Surviving Generations
should become stable because all long-lived objects have already been created and newly-created short-lived objects are periodically being released from the heap.
However, if there is a memory leak in an application which prevents newly-created objects from being released from the heap (for example objects stored in a
Collectionand never removed), the number of Surviving Generations grows. Why? Because between every two garbage collections a new generation (of leaking objects) is created and it survives each successive garbage collection. During run time
the number of Surviving Generations whose generation's age differ by one unit increases, and that's exactly what the Surviving Generations metrics is able to detect regardless of how much memory is wasted by such a leak. That's why using the Surviving Generations
metrics can help you discover a memory leak much sooner, before it consumes the entire heap and causes an
OutOfMemoryError.
How To Do It With NetBeans Profiler?
The NetBeans Profiler is included as part of the regular installation of current versions of NetBeans IDE. If you are using an older version of the IDE that does not include all the profiler features (NetBeans IDE 6.1 or earlier) you might need todownload and install the
NetBeans Profiler installer package.
Discovering the Leak
Download and installNetBeans IDE.
Open the project that you want to check for possible memory leaks.
Choose Profile > Profile Project from the main menu to start profiling the project.
Alternatively, choose Attach Profiler if you want to attach the NetBeans Profiler to an external application.
Choose the Monitor mode and click Run. (You don't need to monitor application's threads.)
相关文章推荐
- Finding Memory Leaks Using the CRT Library
- Tracing memory leaks in .NET applications with ANTS Profiler
- Using Valgrind to debug memory leaks
- Finding Memory Leaks Using the CRT Library
- Memory leaks while using GTK+ over DirectFB
- Using Valgrind to Find Memory Leaks
- Memory leaks using CVSListBox
- CRT Debugging Techniques / Finding Memory Leaks Using the CRT Library
- Finding iPhone Memory Leaks: A “Leaks” Tool Tutorial
- Android studio使用Memory Profiler查看 Java 堆和内存分配
- Using CLR Profiler for .NET Compact Framework
- memory_profiler的使用
- Netbeans-Profiler的激情接触
- How to access the features in an in-memory output layer using an IFeatureCursor
- Detected memory leaks!
- Finding iPhone Memory Leaks: A “Leaks” Tool Tutorial
- Instruments Tutorial for iOS: How To Debug Memory Leaks
- Why does my OSG MFC based application show memory leaks
- Detected memory leaks!内存泄漏,溢出,内存越界问题分析
- finding memory leaks for Solaris applications