※ 引述《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