java的流套接_Java 网络编程从菜鸟到叫兽 4：面向流的套接字 I/O

前面已经看到，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 套接字。