Closing sockets and streams?

[Knute Johnson]

If I have a socket and an InputStream and OutputStream that I have
opened from that socket, do I need to close the streams when I am
finished if I close the socket?

 

[opalpa]

out.close();
in.close();
clientSocket.close();
serverSocket.close();

from
http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

protected void finalize(){
//Clean up
try{
in.close();
out.close();
server.close();
} catch (IOException e) {
System.out.println("Could not close.");
System.exit(-1);
}
}

from
http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/Code/SocketServer.java


It appears it is recommended.



Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Knute Johnson]

out.close();
in.close();
clientSocket.close();
serverSocket.close();

from
http://java.sun.com/docs/books/tutorial/networking/sockets/clientServer.html

protected void finalize(){
//Clean up
try{
in.close();
out.close();
server.close();
} catch (IOException e) {
System.out.println("Could not close.");
System.exit(-1);
}
}

from
http://java.sun.com/developer/onlineTraining/Programming/BasicJava2/Code/SocketServer.java


It appears it is recommended.



Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

Excellent! Thank you.

 

[Roedy Green]

If I have a socket and an InputStream and OutputStream that I have
opened from that socket, do I need to close the streams when I am
finished if I close the socket?

You close the last thing you opened, and it deals with closing all the
things you built up to it.

So, for example, closing a buffered output stream closes the embedded
output stream.

close calls super.close() all the way down like turtles.

 

[Thomas Hawtin]

You close the last thing you opened, and it deals with closing all the
things you built up to it.

So, for example, closing a buffered output stream closes the embedded
output stream.

close calls super.close() all the way down like turtles.

If the construction of the buffered output stream fails, then you have
to remember to close the underlying stream. However, you can wrap this
up in a convenience method.

A simpler idiom is: for output streams, flush the most wrapped output
stream in the happy case. close the underlying stream within a finally
block.

Tom Hawtin

 

[Knute Johnson]

If the construction of the buffered output stream fails, then you have
to remember to close the underlying stream. However, you can wrap this
up in a convenience method.

A simpler idiom is: for output streams, flush the most wrapped output
stream in the happy case. close the underlying stream within a finally
block.

Tom Hawtin

If you don't close them will they eventually get closed in the garbage
collector or are they left dangling forever?

 

[Mike Schilling]

If you don't close them will they eventually get closed in the garbage
collector or are they left dangling forever?

Since the GC may never run, worst case is that they stay open. So it's wise
to close them youeself when you're done with them.

 

[Roedy Green]

If you don't close them will they eventually get closed in the garbage
collector or are they left dangling forever?

I don't know. I have always presumed they could dangle unclosed
forever.

 

[zero]

protected void finalize(){
//Clean up
try{
in.close();
out.close();
server.close();
} catch (IOException e) {
System.out.println("Could not close.");
System.exit(-1);
}
}

No! Don't ever use finalizers to close critical resources. In fact, don't
use finalizers at all - there are very few legitimate reasons to ever use
one. Finalizers are not guaranteed to be called at any time, in any order,
or at all!

 

[Thomas Hawtin]

If you don't close them will they eventually get closed in the garbage
collector or are they left dangling forever?

If a tree falls in a wood with nobody about to here it, does it make any
noise?

It's not a question of when they get closed by the garbage collector.
They will have no chance at all of being closed by the garbage
collector. (Or more strictly, in a finalizer thread.) They have no
finaliser (nor other forms of reference handlers). They are not
resource, so it does not matter. Insisting on closing them is just voodoo.

Tom Hawtin

 

[Roedy Green]

Insisting on closing them is just voodoo.

If you don't close a file, the last bytes you wrote to it won't get
written.

 

[Thomas Hawtin]

If you don't close a file, the last bytes you wrote to it won't get
written.

You should certainly flush OutputStream decorators in the happy case,
but there's no reason that you must close them (so long as you do close
the actual resources somehow).

Tom Hawtin

 

[Roedy Green]

You should certainly flush OutputStream decorators in the happy case,
but there's no reason that you must close them (so long as you do close
the actual resources somehow).

If you can remember to flush, surely you can remember to close.

 

[John C. Bollinger]

If you can remember to flush, surely you can remember to close.

Sometimes it isn't an issue of memory or care. For example, I have
several methods which output formatted text to a Writer. The Writer is
provided as a method argument, and the method implementations wrap it in
a Formatter, which is then used to produce the output. (Not exactly
stream wrapping, but Formatters have exactly the same flushing/closing
semantics as stream decorators.) These methods must *not* close their
Formatters because doing so would close the underlying stream, which is
not their responsibility and not the desired behavior. They must flush
their Formatters, however, lest data be lost.

I agree with Tom. Streams that own system resources must assuredly be
closed to prevent resource leaks. This can be accomplished by closing
some decorating stream, but the only advantage in that is ensuring that
all data written directly via that decorator are committed to the stream
destination. If that is done by some other means (or if it isn't
important) then it doesn't matter which stream up or down the decorator
chain is closed -- closing any one of them will free up the system
resources.

 

[Thomas Hawtin]

Roedy, it is only necessary to flush in the happy case. No need to
introduce any more finally ugliness, nor to ask for more than is required.

I agree with Tom. Streams that own system resources must assuredly be
closed to prevent resource leaks. This can be accomplished by closing
some decorating stream, but the only advantage in that is ensuring that
all data written directly via that decorator are committed to the stream
destination. If that is done by some other means (or if it isn't
important) then it doesn't matter which stream up or down the decorator
chain is closed -- closing any one of them will free up the system
resources.

It doesn't matter much whether you close the resource or its decorator.
However you MUST close the resource *even if the construction of the
decorator fails*.

Tom Hawtin