CODEWITHSUNDEEP
javaperformancememory-leaksjprofiler
NIVESH SENGAR
NIVESH SENGAR

Reputation: 1333

Finding memory leak By JProfiler

My question is different from this I've done profiling of my application it is too slow.
After completion of one process I have seen some live objects in the heap walker.

Though we are caching some data from database to HashMap but the heap walker shows me some live objects like Resultset.getString and Statement.getString which should not be there.

HashMap.put() taking very less memory then above two methods.

Have I done everything fine and is this analysis right? OR I am missing anything and the memory is occupied by HashMap itself and HeapWalker is just showing me methods of JDBC (getString and executeQuery).

Upvotes: 1

Views: 3735

Answers (2)

Ingo Kegel
Ingo Kegel

Reputation: 48105

Since you're talking about methods, I guess you're looking at the "Allocations" view of the heap walker. That view shows where objects have been created, not where objects are referenced. There's a screen cast that explains allocation recording in JProfiler.

HashMap.put will not allocate a lot of memory, it just creates small "Entry" objects that are are used to store key-value pairs. The objects that take a lot of memory are created before you put them into the hash map.

Resultset.getString and Statement.getString create the String objects that you read from your database. So it's reasonable to assume that some of these objects are longer-lived.

To find out why objects are still on the heap, you should go to the reference view, select incoming references and search for the "path to GC root". The "biggest objects" view is also very helpful in tracking down excessive memory usage.

Upvotes: 2

wmorrison365
wmorrison365

Reputation: 6318

What you may be seeing is cached data held by the connection (perhaps its buffer cache) or the statement or result set.

This could be through not closing the connection, statement or result set or it could be due to connection pooling. If you look at the memory profile, you may be able to see the "path to GC root" (the path to the object root) and this would indicate what is holding your ResultSet strings. You should see if it's in your code, cached within something you retain or if it's in a pool.

N.B. I've not used JProfiler but this is how I would track it with YourKit.

Upvotes: 1

Related Questions