前面已經看到，Socket 類的 getInputStream() 和 getOutStream() 方法分別獲取套接字的輸入流和輸出流。輸入流用來讀取遠端發送過來的數據，輸出流則用來向遠端發送數據。
輸入流
使用套接字的輸入流讀取數據時，當前線程會進入阻塞狀態，直到套接字收到一些數據為止（亦即套接字的接收緩沖區有可用數據）。該輸入流的 available() 方法只是返回接收緩沖區的可用字節數量，不可能知道遠端還要發送多少字節。使用輸入流的時候，最好先將它包裝為一個 BufferedInputStream，因為讀取接收緩沖區將導致 JVM 和底層系統之間的切換，應當盡量減少切換次數以提高性能。BufferedInputStream 的緩沖區大小最好設為套接字接收緩沖區的大小。
如果直接調用輸入流的 close() 方法來關閉它，則將導致套接字被關閉。對此，Socket 類提供了一個 shutdownInput() 方法來禁用輸入流。調用該方法后，每次讀操作都將返回 EOF，無法再讀取遠端發送的數據。對這個 EOF 的檢測，不同的輸入流包裝體現出不同的結果，可能讀到 -1 個字節，可能讀到的字符串為 null，還可能收到一個 EOFException 等等。禁用輸入流后，遠端輸出流的行為是平臺相關的：
- 在 BSD 平臺上，遠端的發送的數據能正常接收，然后直接丟棄。遠端無法知道本端的輸入流已禁用。這和 JDK 文檔描述的行為一致。
- 在 WINSOCK 平臺上，遠端發送數據將會導致“連接被重置”的錯誤。
- 在 Linux 平臺上，遠端發送的數據能繼續接收，直到套接字輸入緩沖區填滿，之后遠端再也無法發送數據（若使用阻塞模式則進入死鎖）。
禁用輸入流這種技術并不常用。
輸出流
套接字的輸出操作實際上僅僅將數據寫到發送緩沖區內，當發送緩沖區填滿且上次的發送成功后，由底層系統負責發送。如果發送緩沖區的剩余空間不夠，當前線程就會阻塞。和輸入流類似，最好將輸出流包裝為 BufferedOutputStream。
如果套接字的雙發都使用 ObjectInputStream 和 ObjectOutputStream 來讀寫 Java 對象，則必須先創建 ObjectOutputStream，因為 ObjectInputStream 在構造的時候會試圖讀取對象頭部，如果雙發都先創建 ObjectInputStream，則會互相等待對方的輸出，造成死鎖：
// 創建的順序不能顛倒！
ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());
ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
類似于輸入流，關閉輸出流也導致關閉套接字，所以 Socket 類同樣提供了一個 shutdownOutput() 來禁用輸出流。禁用輸出流后，已寫入發送緩沖區的數據會正常發送，之后的任何寫操作都會導致 IOException，且遠端的輸入流始終會讀到 EOF。禁用輸出流非常有用，例如套接字的雙發都在發送完畢數據后禁用輸入流，然后雙方都會收到 EOF，從而知道數據已經全部交換完畢，可以安全關閉套接字。直接關閉套接字會同時關閉輸入流和輸出流，且斷開連接，達不到這種效果。
使用流的阻塞套接字的優缺點
如果要使用流進行輸入和輸出，就只能用阻塞模式的套接字。這里總結一下阻塞套接字的優缺點。先看看優點：
- 編程模型簡單，非常適合初學者上手。
- 以裝飾器模式設計的 Java I/O 使得開發人員可以輕松地從 I/O 流讀寫任何類型的數據。
但在性能方面有致命的缺點：
- 由于服務器套接字接受連接，以及套接字的讀寫都會阻塞，性能低下。
- 如果不對 I/O 流手動進行緩沖，則可能造成一次只處理一個字節，性能低下。
- 服務器套接字每次只能接受一個連接，導致 JVM 和底層系統之間頻繁的調用切換，性能低下。
下一篇文章開始探討使用基于 NIO 的套接字通道和緩沖區實現伸縮性更強的 TCP 套接字。