permaculture playing cards*
The moose likes Java in General and the fly likes memory leackage Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "memory leackage" Watch "memory leackage" New topic
Author

memory leackage

Nareshkumar Kapilavai
Greenhorn

Joined: May 29, 2007
Posts: 25
how to control memory leackage in java?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Are you looking for how to avoid it in code? How to detect when it happens? How to figure out what's causing it? how to fix it? Those are all good topics but too many to answer all at once.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Amit Ghorpade
Bartender

Joined: Jun 06, 2007
Posts: 2709
    
    5

Hi,
as far as I know there are no memory leaks as such in Java.
By this I mean that if you keep on allocating memory and then dont care to free it,NO memory leak takes place. Because JVM or in fact GC takes care of it.
So I dont think a memory leak actually takes place and there is any way to detect it.

Hope this helps


SCJP, SCWCD.
|Asking Good Questions|
Mike Mc Afee
Greenhorn

Joined: Jan 31, 2007
Posts: 19
Item 5 of Effective Java by Joshua Bloch mentions a good example of a "memory leak" in Java and a way to correct the problem.
Nareshkumar Kapilavai
Greenhorn

Joined: May 29, 2007
Posts: 25
Hi,
Thanks for the suggetion,my question is how to control in the code when it happens? and how to avoid it in the code?
Jeremy Botha
Ranch Hand

Joined: Feb 16, 2005
Posts: 125
1) Don't create objects you won't ever use.
2) Code efficiently.
3) Don't keep references to objects you no longer need.

J


McFinnigan? Never heard of him. Nobody here but us chickens...<br /> <br />SCJP for Java 1.4<br />SCJD for Java 5.0
Nareshkumar Kapilavai
Greenhorn

Joined: May 29, 2007
Posts: 25
Hi,
Thank you very much.
naresh.
Anupam Bhatt
Ranch Hand

Joined: Mar 12, 2004
Posts: 81
Just to add, pay special attention to any database connection objects being created and "not being closed" [sometimes due to an exception happening the con.close() will be ignored], so close the connections always in the finally blocks !
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Originally posted by Anupam Bhatt:
Just to add, pay special attention to any database connection objects being created and "not being closed"


Not every application uses SQL databases, so it's worth a more general statement of this principle.

Database Connections are an example of a "non-memory resource". A TCP socket or a CORBA ORB might be other examples.

The Java garbage collector manages memory resources, so that they are automatically freed when they are no longer used; all you have to do is make sure you do not keep referencing them after you need them.

Non-memory resources have no such automatic management, so you must ensure that you explicitly close/free/delete them when you are finished with them. You must make sure this happens even in the error case. A common mistake of new/poor programmers is to fail to code for exceptional conditions. Java's "finally" often helps with this.

Note that the Java classes that manage non-memory resources sometimes do include a finalize() method that closes the resource when the associated Java object is GC'd. You should not rely on this. The reason is that GC occurs in response to a lack of free memory, which is a completely different thing to a lack of, say, database connections. For instance, a machine might have gigabytes of Java heap available, but very limited numbers of database connections. In such a system, GC might be very infrequent and you could easily run out of database connections if you relied on GC to close them.

Personally, I think that people writing classes representing non-memory resources should not write such finalisers, as they only encourage bad practice.


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Anupam Bhatt
Ranch Hand

Joined: Mar 12, 2004
Posts: 81
I thought again and i agree with you Peter, thanks for correcting me.

I was mixing two things here when talking about closing DB connections.

What we are freeing up on closing the DB connections is the connections to the DB so that we do not run out of DB connections for any further requests.

Just a clarification needed: where is the DB connection state held? I mean lets say we do not close a DB connection, in that case where shall the session data for the DB connection will be held? I think it would be held in memory on the DB server. Is that correct?

Need your comments.

Thanks,
Anupam
[ June 25, 2007: Message edited by: Anupam Bhatt ]
Kaydell Leavitt
Ranch Hand

Joined: Nov 18, 2006
Posts: 688

Although Java has automatic garbage collection, there can be memory leakage if you are keeping references to objects that are no longer needed. You can set an object reference to null to indicate that you no longer need an object. This will make the object eligible for garbage collection -- provided that there are no other references to the object.

Kaydell
[ June 25, 2007: Message edited by: Kaydell Leavitt ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: memory leackage
 
Similar Threads
How to pass the values between MIDlets?
Tag Library and Struts Framework
WA #1.....word association
Jess in J2ME
char doubt