Next step should be to find out what kind of objects are really filling up your memory. If your code is doing something like storing elements in a list that expands forever, then that would be your problem. But if you don't see anything obvious like that, you should get a Java profiler and let it watch your memory allocations.
Your problem is before GC can collect unused object from memory, your application piling up many more object.
Avoid object creating. It is not at all connection pool problem.
Joined: Oct 30, 2001
Originally posted by Jignesh Patel: Avoid object creating.
Isn't it rather hard to write a Java program without creating objects ;-)
The problem is unlikely to be how many objects are being created, but rather what is holding references to them.
Almost every Java program creates loads of objects, but most of them are short-lived because references to them are not held for long.
Look for places where you may be storing long-lived references to objects. Global collections, caches, pools etc.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.<br /> <br />#:^P
Joined: May 29, 2001
Thanks for all for the valued suggestions.
I agree that it maybe due to the style of coding. Now, our project is over two years old and developed by over 20 different developers. So... the million dollar question is.....
How do we know what code is the Culprit... How do we know WHICH are the OBJECTS that are NOT being released... Are there any tools for it ? Can Java Profilier point us to the object which is causing the issue ?If not, which other tool ?
Thanks, Milan Doshi
Joined: Sep 24, 2003
Originally posted by Doshi Milan: Are there any tools for it ? Can Java Profilier point us to the object which is causing the issue ?If not, which other tool ?
Thanks, Milan Doshi
Yes, use a profiler. After you've encountered enough OutOfMemoryErrors, your first call will be a profiler - speculation from another is nothing more than a red herring - and in some cases an impossibility under the given circumstances.
Thanks everyone for valuable inputs, the Profiler has been installed and hopefully provide more information.
Joined: Sep 22, 2006
Running profiler may help you find some leaks, but your application may just need more memory:have you tried changing -Xmx value (to increase memory for JVM). The default value is not that large. Its maximum value can be about 1.4G for a 32bit.
Joined: Sep 27, 2006
Usually, the major cause for having many live objects cannot be cleared is the wrong scoping and cause the memory leak, so you better check all object variables defined with static outside the method. Besides, if you increase the xmx heap size, it should be limited by the physical memory; otherwise, it will downgrade the performance a lot due to paging.