× Please, log in to give us a feedback. Click here to login

You must be logged to download. Click here to login


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation


MrBool is totally free and you can help us to help the Developers Community around the world

Yes, I'd like to help the MrBool and the Developers Community before download

No, I'd like to download without make the donation

Profiling: How to Analyze Java Applications

In this article we will see how to perform the analysis of Java applications, how to detect memory leaks, deadlocks, locks, race conditions, and various problems, among other things, are the main causes of performance problems

A term commonly used for the analysis of applications is Profiling. The profiling is used to describe the process of measuring the execution time of methods, so that we can find and fix performance bottlenecks. In the context of Java that term is expanded further includes collecting various metrics and allows debug runtime threads and objects.

There are several reasons we use the profilers in Java applications, among them, to investigate the use of the heap and the frequency that is occurring garbage collection, search the allocation of objects and references to find and fix memory leaks, investigate the allocation and synchronization of threads to find blocking issues and competition for access to data, identify costly methods or investigating a run-time application so that we can understand its structure.

The profiling occurs usually after the development phase and the main objectives of their use is to improve application performance, fix bugs difficult to locate and understand what is happening in the application while it runs.

The rest of the article we will see what are the main profilers and what they can offer developers, what are the main features of these tools and how we can test them in practice and how we can make some specific tests to check performance problems in Java applications.


There are three profilers widely used in Java and considered the best by the community, they are: JProbe Suite (Quest Software), Optimizeit Suite (Borland) and JProfiler (Ej-Technologies).

All three are considered very good, but JProfiler has the advantage of integrating all the features in a single application, instead of having separate tools for profiling, memory debugging and debug threads. The JProbe has the advantage of being the first type of tool and is still considered the best by many developers. The differential JProbe over other tools is the heap graph window which among other things allows you to navigate the graph objects. Optimizeit is a Borland tool well known in the market, being developed and maintained by a specialized team. The big problem is Optimizeit integration has only a few development tools.

We will see below for more information about the tools mentioned.


The JProbe Suite basically contains four tools: JProbe Memory Debugger JProbe Profiler JProbe Threadalyzer and JProbe Coverage. The JProbe Memory Debugger helps developers to eliminate memory leaks, reduce excess garbage collection and identify objects that are holding references to other objects in the heap. The JProbe Profiler combines an interface with call graph and information gathering to provide an application performance diagnosis. The JProbe Threadalyzer is a powerful tool for detecting problems with threads, deadlocks, race conditions, among others. Finally, JProbe Coverage helps development teams and quality assurance staff on location codes not run, making it easier to assess the reliability and accuracy of unit tests.

Each of these tools has two components: JProbe Console and JProbe Analysis. The JProbe Console is a user interface implemented as a separate application in JProbe Suite that can analyze information collected in session through JProbe Analysis. The JProbe Analysis collects data within the context of a session in a stand-alone Java application or an application that is running in Application Server. The JProbe Analysis requires a JVM that supports JVMPI interface that is a inerface profiling. The JProbe support the most popular JVMs a variety of operating systems.

Information collected by JProbe Analysis can be viewed in real time or stored in files for later analysis.

The installation of JProbe Suite can be performed either on the command line or with a GUI interface. The JProbe can be installed in various Integrated Development Environment (IDE).


Optimizeit allows developers to improve the performance of your Java applications, applets, servlets, JavaBeans, Enterprise JavaBeans (EJBs) and Java Server Pages (JSPs). Through an analysis of the JVM can check the memory allocation of our application or inefficient use of CPU.

Through a simple wizard and can quickly install configure Optimizeit, we do not need to recompile our program with a custom compiler or modify classes before his execution. So we just need to run to start Optimizeit performance testing. After running the Optimizeit Profiler can access the Memory Profiler or the CPU Profiler.

The Memory Profiler provides a real-time display of all classes used by the program and the number of allocated instances. We use the Memory Profiler to check references of allocated objects and instances. In addition, the memory profiler has filters so that we can focus on particular classes, controls for garbage collection, reference graphs, detection of memory leaks, and other features.

The CPU Profiler displays resltados tests for each thread or group of threads showing various statistics that can be filtered.

Optimizeit Profiler also has a Virtual Machine Info that displays and exports graphs showing high-level information including the JVM heap size, used heap, number of threads, number of busy threads and number of loaded classes.


The JProfiler is a simple tool to be used and very powerful. The session settings are fairly straightforward and integration with third-party tools is simple and data collection is presented in a very natural way.

The tool provides profiling for JDBC, JPA/Hibernate and NoSQL (MongoDB, Cassandra and HBase), since problems with database calls constitute the key performance problems of applications.

We can also see a tree of calls made to Java Enterprise Edition components.

Higher level information such as RMI calls, files, sockets and processes are also presented to the JProfiler.

JProfiler also supports information about memory leaks and heap information.

Quality assurance team can use JProfiler as a tool for QA. The tool supports command-line operations through the ant tasks allowing export information or create comparisons.

Like this other profilers the JProfiler is integrated into different development environments (making profilindo during the development phase), application servers and JVMs in general both 32-bit and 64-bits.

Another interesting point of JProfiler is its low overhead because the JProfiler only stores information when we need. So we can start our application with the JProfiler agent and include the JProfiler GUI at a later time. When we are not recording information overhead is extremely low

Finally, the JProfiler also allows the CPU execute one profiling checking the status of threads, levels of aggregation, called tree, call graph, among other features.

Other tools

There are other tools that extract this information already seen the running JVM. The tools in this section are all open source.

Jmap is a tool developed by Oracle that is present in the JVM and displays a map of objects in memory in addition to heap the details of a given process, a file or a remote server. The VisualVM is another tool built into the JVM that displays visual information to developers as memory leaks, heap space, CPU usage, among other features. The problem of VisualVM is that it is able to run constantly on the JVM, not records collected information and does not send alerts. The BTrace is a more complete tool than previous allowing visualize various information such as use of GEAP memory, number of active threads, total CPU usage, SQL calls, network operations, among others.

Investigating Heap and Garbage Collection

The Garbage Collector is a platform provided by the Java feature that eliminates the need for the developer explicitly release memory objects. However, the cost of this is the performance overhead when garbage collection is performed.

Using the JProbe or any of the other profilers have access to a summary of the heap chart for a running application. With this, we can monitor the total size of allocated memory and the available memory.

Here in Figure 1 an example of JProbe investigating the heap usage and frequency of garbagge Collector in an application that is running.

How to Analyze Java Applications

Figure 1. Information on the heap in JProbe.

When the amount of heap used decreases is because we had a garbage collection performed, or are sought objects in memory that are no longer used in the program and deleted from memory, thus freeing up more space.

We can verify that create many new objects can result in complex and time-consuming operations in the JVM will spend time in the processor memory management, instead of performing operations that make up the business logic. The problem may worsen when the JVM has little free memory, thus the garbage collector needs to run more often so that more memory is available. We can improve application performance by increasing the heap size. As an example, we can run an application and try size 5MB and 16MB for the heap and compare the frequency of execution of the garbage collector. However, this does not mean that there may be an improvement in performance, as they sometimes run multiple garbage collection cycles can be almost as fast as running just a cycle, but we would have to iterate over objects. So it is interesting experiencing values for initial and maximum size of the heap for a specific application, the test is the only way to reliably validate the best configuration.

Finding and Fixing Leaks Memory

Most Java applications have problems with memory leaks. A memory leak is when the allocated memory is not released back to the pool. The Garbage Collector frees the memory kept by inaccessible objects, but if there is a reference to an object, this object will not be eligible for garbage collection even if it is never again used. An example of this is placed in an array object, if this element is never removed it will remain in memory. If these objects remain long in the memory they can consume all memory and cause an OutOfMemoryError. Another problem is the persistent objects (connection to the database or temporary files). Also the longer the objects remain in the memory, the more costly will be garbage collection, you have more objects to be covered. Thus, the profilers provide a better alternative to locate these persistent objects and identify objects that are difficult to garbage collection. With this, we can achieve a more targeted search within the system to see what is causing this memory leak.

Here in Listing 1 is an example of a program that causes memory leaks.

Listing 1. Causing memory leaks.

public class FabricaDePoints {
           protected ArrayList points = new ArrayList();
           public Point createPoint(int x, int y) {
                     Point point = new Point(x,y)
                     return point;
           public void removePoint(Point point) {
           public void testaPrintPoints() {
                     for (int i=0; i<5; i++) {
                              Point point = createPoint(i,i);
                              System.out.println("Point = " + point);

Using the JProbe can check the status of that application. If we increase the object's size or the number of iterations we can run out of memory quickly.

To investigate the memory management in the sample code must configure convertjava.profile.PointFactory as an independent application in JProbe Memory Debugger. Running it in JProbe, the initial display shows a summary of the heap at run time and a preview of the classes. Initially no java.awt.Point object has not yet created, but when you click the PRINT TEST POINTS button on the application will return to the display of classes where we can see five StringBuffer instance created. With JProbe we can also force to collect garbage and verify that the StringBuffer instance disappeared and the points are still in memory. If we click again on this button the number increases to 10. This confirms that we have memory leaks and must now find out why the points are persisting in memory, either through an inspection of source code by locating where the instances are created or browsing the tree references in a profiler and finding all the ways in memory to the root. Another interesting view that the JProbe offers is the Reference Graph. One way to solve this would be to add the method "remove" after the "println" in "testaPrintPoints" method.

Investigating the allocation and Thread Synchronization

Multithreaded applications have a high risk due to synchronization problems where several concurrent operations can be performed simultaneously. While if we use single threaded code will run in the same order in which it is written in the source code. As in multithreaded application each thread can be interrupted to allow the processor to execute another thread operations have to order and breakpoints are almost random and can not be predicted.

Among the problems encountered with the multithreading have competition data where two threads trying to access and modify the same time a shared resource, deadlocks where a thread waits for a lock acquired by another thread that is never released, and threads of crashes where the threads are waiting to be notified, but the notification never comes.

The profilers like JProbe Threadalizes can capture and report the various types of competition data that may occur. To deadlock problems the JProbe Threadalizer and OptimizeIr Thread Debugger can detect and provide information on deadlocks. Optimizeit even provides a visual line of the thread execution time. To test Optimizeit can use the example below and after that run the Optimizeit and we configure the ThreadTest as the main class, we also mark the Auto-start Analyzer option in the application settings dialog box to automatically analyze the application running searching problems.

Listing 2 in the following an example of a code deadlock.

Listing 2. Sample code deadlocked.

 public Object lock1 = new Object();
  public Object lock2 = new Object();
  public void metodo1() {
           synchronized(lock1) {
                     synchronized(lock2) {
  public void metodo2() {
           synchronized(lock2) {
                     synchronized(lock1) {

When we run the JProbe can check all the threads and the timeline of their status running. Green indicates that the thread is running, yellow indicates that the thread is blocked while waiting for a lock that is with another thread, red is when the thread waits for a notification, and purple indicates that the thread is blocked. We can see that after running the code up the two threads "method 1" and "method2" are locked indefinitely. If we use the File-> Analyser-> Stop Recording can verify identification of a deadlock detected by the tool on "Locking order mismatch". If we select the item you can see more details about the deadlock found.

The locks of the threads are also captured by the profilers. To test these crashes can create a thread that calls the wait() method on an object, but no other thread calls notify() on the same object.

Investigating Methods Costly

Despite improvements in recent JIT, the main factor for quality gain is still the design and implementation of the application. Hence the importance of knowing good practices and common armadinhas. To gain performance must first identify where the bottleneck, so as we develop and test the code should be analyzed with a profiler to identify the methods that are taking longer.

Generally, the profiling collects various performance statistics providing an idea of where time is being spent. The most important and useful metrics produced by JProbe this case is the "Method Time" where we have the time spent executing a given method excluding the time spent in the method he called the "Method Number of Calls" where we have the number of times the method was called, the "Avarage method time" where we have the average time that the method took to run, the "Cumulative time" that provides the total time to perform a given method including those he called and "Avarage objects per method "which is the average number of objects created within a method (useful to know how GC may influence the performance).


[1] Vanhelsuwé, Laurence. Profiling the profilers: A comparative review of three commercial Java code profilers.

[2] Tool Report: JProbe

[3] JProbe

Web developer and passioned for web design, SEO and front end technologies.

What did you think of this post?
To have full access to this post (or download the associated files) you must have MrBool Credits.

  See the prices for this post in Mr.Bool Credits System below:

Individually – in this case the price for this post is US$ 0,00 (Buy it now)
in this case you will buy only this video by paying the full price with no discount.

Package of 10 credits - in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download few videos. In this plan you will receive a discount of 50% in each video. Subscribe for this package!

Package of 50 credits – in this case the price for this post is US$ 0,00
This subscription is ideal if you want to download several videos. In this plan you will receive a discount of 83% in each video. Subscribe for this package!

> More info about MrBool Credits
You must be logged to download.

Click here to login