Closing sockets and streams?

Discussion in 'Java' started by Knute Johnson, Jan 21, 2006.

  1. 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?

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 21, 2006
    #1
    1. Advertising

  2. opalinski from opalpaweb, Jan 21, 2006
    #2
    1. Advertising

  3. opalinski from opalpaweb wrote:
    > 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
    >
    > http://www.geocities.com/opalpaweb/
    >


    Excellent! Thank you.

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 21, 2006
    #3
  4. Knute Johnson

    Roedy Green Guest

    On Fri, 20 Jan 2006 16:22:19 -0800, Knute Johnson
    <> wrote, quoted or indirectly quoted someone
    who said :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Jan 21, 2006
    #4
  5. Roedy Green wrote:
    >
    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jan 21, 2006
    #5
  6. Thomas Hawtin wrote:
    > Roedy Green wrote:
    >
    >>
    >> 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


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

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jan 22, 2006
    #6
  7. "Knute Johnson" <> wrote in message
    news:JGBAf.12678$...

    > 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.
    Mike Schilling, Jan 22, 2006
    #7
  8. Knute Johnson

    Roedy Green Guest

    On Sat, 21 Jan 2006 18:00:07 -0800, Knute Johnson
    <> wrote, quoted or indirectly quoted someone
    who said :

    >
    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Jan 22, 2006
    #8
  9. Knute Johnson

    zero Guest

    " opalinski from opalpaweb" <> wrote in
    news::

    >
    > 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!
    zero, Jan 22, 2006
    #9
  10. Knute Johnson wrote:
    > Thomas Hawtin wrote:
    >> Roedy Green wrote:
    >>> So, for example, closing a buffered output stream closes the embedded
    >>> output stream.


    >> 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.


    > 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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jan 23, 2006
    #10
  11. Knute Johnson

    Roedy Green Guest

    On Mon, 23 Jan 2006 18:32:04 +0000, Thomas Hawtin
    <> wrote, quoted or indirectly quoted someone
    who said :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Jan 23, 2006
    #11
  12. Roedy Green wrote:
    > On Mon, 23 Jan 2006 18:32:04 +0000, Thomas Hawtin
    > <> wrote, quoted or indirectly quoted someone
    > who said :
    >
    >> 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.


    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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jan 23, 2006
    #12
  13. Knute Johnson

    Roedy Green Guest

    On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin
    <> wrote, quoted or indirectly quoted someone
    who said :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Jan 23, 2006
    #13
  14. Roedy Green wrote:
    > On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin
    > <> wrote, quoted or indirectly quoted someone
    > who said :
    >
    >
    >>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.


    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.

    --
    John Bollinger
    John C. Bollinger, Jan 24, 2006
    #14
  15. John C. Bollinger wrote:
    > Roedy Green wrote:
    >> On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin
    >> <> wrote, quoted or indirectly quoted someone
    >> who said :
    >>
    >>
    >>> 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.


    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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jan 24, 2006
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ZOCOR

    Closing IO Streams

    ZOCOR, Aug 27, 2004, in forum: Java
    Replies:
    3
    Views:
    511
    Michael Borgwardt
    Aug 27, 2004
  2. Aziz
    Replies:
    1
    Views:
    397
    Oliver Wong
    Jun 28, 2006
  3. Evgeni Sergeev
    Replies:
    2
    Views:
    440
    Jean Brouwers
    Dec 28, 2004
  4. Juha Nieminen

    Re: Closing file streams

    Juha Nieminen, Jan 27, 2009, in forum: C++
    Replies:
    3
    Views:
    506
    James Kanze
    Jan 29, 2009
  5. Philipp

    Closing decorated streams

    Philipp, Jul 9, 2009, in forum: Java
    Replies:
    6
    Views:
    321
    Knute Johnson
    Jul 11, 2009
Loading...

Share This Page