 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006Closing sockets and streams?
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?  SignatureKnute Johnson email s/nospam/knute/ 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/SocketS erver.java It appears it is recommended. Opalinski opalpa@gmail.com http://www.geocities.com/opalpaweb/ > out.close(); > in.close(); [quoted text clipped - 24 lines] > opalpa@gmail.com > http://www.geocities.com/opalpaweb/ Excellent! Thank you. SignatureKnute Johnson email s/nospam/knute/ > protected void finalize(){ > //Clean up [quoted text clipped - 7 lines] > } > } 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! On Fri, 20 Jan 2006 16:22:19 -0800, Knute Johnson <nospam@ljr-2.frazmtn.com> 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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > You close the last thing you opened, and it deals with closing all the > things you built up to it. [quoted text clipped - 3 lines] > > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> You close the last thing you opened, and it deals with closing all the >> things you built up to it. [quoted text clipped - 13 lines] > > Tom Hawtin If you don't close them will they eventually get closed in the garbage collector or are they left dangling forever? SignatureKnute Johnson email s/nospam/knute/ > 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. On Sat, 21 Jan 2006 18:00:07 -0800, Knute Johnson <nospam@ljr-2.frazmtn.com> 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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>> 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ On Mon, 23 Jan 2006 18:32:04 +0000, Thomas Hawtin <usenet@tackline.plus.com> 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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Mon, 23 Jan 2006 18:32:04 +0000, Thomas Hawtin > <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone [quoted text clipped - 4 lines] > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin <usenet@tackline.plus.com> 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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin > <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone [quoted text clipped - 5 lines] > > 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. SignatureJohn Bollinger jobollin@indiana.edu >> On Mon, 23 Jan 2006 21:23:08 +0000, Thomas Hawtin >> <usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone [quoted text clipped - 5 lines] >> >> 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 [quoted text clipped - 4 lines] > 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 SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.