This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
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.
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 !
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.
Joined: Mar 12, 2004
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?
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.