In what situations can a Java-program leak memory?
Few hunches:
- unnecessarily holding static references to objects
- unnecessarily holding references to objects in a long-living thread
- not closing connections, statements or resultsets
- writing native code that leaks memory
- using libraries or JVM-implementation that leak memory
Any other ideas?
Here are some references I can add during my lunch hour (I am sure
others will contribure more):
See Chapter two "Creating and Destroying Objects" of Bloch's book
Effective Java, especially sections 5 Eliminate obsolete object
references and 6 Avoid finalizers
http://java.sun.com/docs/books/effective/
http://java.sun.com/docs/books/effective/toc.html
Use of finalizers, or anything else that requests work to be done
at some unspecified time in the future (such as java.io.File.deleteOnExit()),
will resemble a memory leak because the system must retain enough
state (possibly including strong references to objects) to be able to
do the work later.
Thanx, in some of my code I do use java.io.File.deleteOnExit(). Especially when used in a webapp where the JVM does not *exits* unless the webserver (e.g. Tomcat or Resin) is restarted completely, memory can go crazy. So I conclude: don't use java.io.File.deleteOnExit() in webapps on production-machines.
> In what situations can a Java-program leak memory?
>
> Few hunches:
> - unnecessarily holding static references to objects
> - unnecessarily holding references to objects in a
> long-living thread
> - not closing connections, statements or resultsets
> - writing native code that leaks memory
> - using libraries or JVM-implementation that leak
> memory
>
> Any other ideas?
not closing connections, statements or resultsets
is the most common cause of leaks I guess.
Do you imply its so obvious from the following wonderfully terse and elegant javadoc? I wasted 3 days for unwanted, unneeded, undocumented caching. What about a "CachingObjectOutputStream" instead?
reset
public void reset()
throws IOExceptionReset will disregard the state of any objects already written to the stream. The state is reset to be the same as a new ObjectOutputStream. The current point in the stream is marked as reset so the corresponding ObjectInputStream will be reset at the same point. Objects previously written to the stream will not be refered to as already being in the stream. They will be written to the stream again.
