※ 引述《PsMonkey (痞子军团团长)》之铭言： : 我不太懂你为甚麽要重复使用（嫌弃 GC？） : 重点是... 如果你已经读到没有东西了 : （我假设你那句「使用来读取一个档案之後」是这个意思） : 那麽，人家都精尽人亡了，你还要人家可以 read() 到东西 : 这样会不会太过分了点？ : 或着反过来说，如果这样还读得到东西 : 那你永远不知道什麽时候档案读完 [死] : 以上毫无反应，就只是个算命文 : 我相信乡民们看我这种无意义的算命文也看的很厌烦了 : 请你把你的剧本 / 程式码叙述的完整一点 : 这样才可能快速地解决你的问题 这个有一个小例外，不过因为太常碰到了，所以回文讲一下 我们有时候会有些需求，要用socket对HTTP做手脚，发request/收recv HTTP1.0的时候，server传完[header]\r\n\r\n[body]就会很乖的把它断开 (这个上面看不懂的其实下面也不太需要浪费时间看了，因为这代表没碰过这需求 等到实际碰到再回来看就可以了) 所以socket.getInputStream()会很乖的如上面所说的断开 当然，HTTP版本是可以从request的header去指定的 HTTP1.1的时候情况就不一样了，除了比以前1.0多要求了一个Host header以外， 还多增加了一个叫做Connection的Header。这个Connection header很妙 他预设是keep-alive Connection: keep-alive 这个keep-alive会keep住这个session让他不会断开，即使资料传完了也一样 按标准的话印象中是要20秒没资料来回才会断开，那这个socket.getInputStream() 问题就很大了...因为他不会自己断，你也不该自己断，这单单用socket其实颇难处理的 如果要让他能像以前的行为一样断开的话，你必须把Connection指定为closed Connection: closed 为什麽预设是keep-alive以及为什麽要支援keep-alive这个就不在本文讨论范围之内了， 总之在某些情况下Socket.getInputStream()的确在读完了并不会断开 可是，这篇不是讲FileInputStream吗？ 这就是重点了，FileInputStream的spec中并没有eof会断开的规定，任何设备商 要是以pipe来传递，而且overload FileInputStream的话，其实是有绝对的能力 去让他read卡在那里读不到东西却不直接执行断开的，而且这种东西实作上是很 有可能发生的，端看厂商怎麽实作。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.124.251.135