ICE09 . playing with java, scala, groovy and spring .

Playing with Spring

Eclipse Galileo: Memory Analyzer (MAT) …and a little Spring…

Posted by ice09 on June 28, 2009

The source can be downloaded here. The Spring libraries have to be added manually to the local maven repo (compare this.) The pom is inspired by this post.

I wanted to play with Eclipse Galileo and the Memory Analyzer (MAT), which I used successfully some time ago to identify possible memory leaks.

Using an old example, I construed a case where instead of using a singleton, accidentially a prototype is used (once again a nice sample for Spring’s capabilities – changing one line changes the behaviour completely).

<?xml version="1.0" encoding="UTF-8"?>
<beans [...]>
               
<!-- using is the "correct" singleton pattern
     <bean id="scopetest" class="com.commons.Scopetest">
     </bean>
-->

<!-- using is the "leaking" prototype pattern
     <bean id="scopetest" class="com.commons.Scopetest" scope="prototype">
         <aop:scoped-proxy/>  
     </bean>
-->
     
     <bean id="testclass" class="com.commons.Testclass">
     	<property name="scopetest" ref="scopetest"/>
     </bean>
     
</beans>

What's the difference? Let's have a look at the main class:

Testclass testclass = (Testclass) app.getBean("testclass");
for (; i < 1000000; i++) {
     Scopetest proxy = testclass.getScopetest();
     leakingSet.add(proxy.uniqueCode());
}
System.out.println("size: " + leakingSet.size());

Using a singleton, the uniqueCode is always the same (I did not use hashCode since it collides with the Proxy hashCode), which leads to a Set with just one object (the uniqueCode of the singleton - which is always the same).
Using the prototype, the class is proxied by cglib and each call to uniqueCode() creates a new Scopetest object, each has a timestamp-based uniqueCode - therefore each object (the uniqueCode-Integer) is added to the Set.

As being said, this is highly construed, however, if you forget to change the object type from prototype to singleton somewhere in your application, you might experience a non-expected behaviour (eg. 1000000 objects instead of one).

How can this be found with Eclipse MAT?

Preparation

First, Eclipse MAT has to be installed (anybody knows why?):


Afterwards, the sample application is started and a heap dump is taken. There are several options for doing this, I used jvisualvm.


Usage

Back in Galileo, the heap dump can now be opened with Eclipse MAT (after opening the MAT Perspective):




Using the generated report, the source of the memory leak is quite easy to find - it is immediately identified as a "suspect" automatically by the "Leak Suspect Report". Even the correct name of the private member (the Set with the 1000000 objects) is shown (leakingSet), which makes pinpointing the causing object an ease.

About these ads

One Response to “Eclipse Galileo: Memory Analyzer (MAT) …and a little Spring…”

  1. [...] Comments (RSS) « Eclipse Galileo: Memory Analyzer (MAT) …and a little Spring… [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: