Socket通道

上文讲述了通道、文件通道，这篇文章来讲述一下Socket通道，Socket通道与文件通道有着不一样的特征，分三点说：

1、NIO的Socket通道类可以运行于非阻塞模式并且是可选择的，这两个性能可以激活大程序（如网络服务器和中间件组件）巨大的可伸缩性和灵活性，因此，再也没有为每个Socket连接使用一个线程的必要了。这一特性避免了管理大量线程所需的上下文交换总开销，借助NIO类，一个或几个线程就可以管理成百上千的活动Socket连接了并且只有很少甚至没有性能损失

2、全部Socket通道类（DatagramChannel、SocketChannel和ServerSocketChannel）在被实例化时都会创建一个对应的Socket对象，就是我们所熟悉的来自java.net的类（Socket、ServerSocket和DatagramSocket），这些Socket可以通过调用socket()方法从通道类获取，此外，这三个java.net类现在都有getChannel()方法

3、每个Socket通道（在java.nio.channels包中）都有一个关联的java.net.socket对象，反之却不是如此，如果使用传统方式（直接实例化）创建了一个Socket对象，它就不会有关联的SocketChannel并且它的getChannel()方法将总是返回null

概括地讲，这就是Socket通道所要掌握的知识点知识点，不难，记住并通过自己写代码/查看JDK源码来加深理解。

非阻塞模式

前面第一点说了，NIO的Socket通道可以运行于非阻塞模式，这个陈述虽然简单却有着深远的含义。传统Java Socket的阻塞性质曾经是Java程序可伸缩性的最重要制约之一，非阻塞I/O是许多复杂的、高性能的程序构建的基础。

要把一个Socket通道置于非阻塞模式，要依赖的是Socket通道类的弗雷SelectableChannel，下面看一下这个类的简单定义：

因为这篇文章是讲述Socket通道的，因此省略了和选择器相关的方法，这些省略的内容将在下一篇文章中说明。

从SelectableChannel的API中可以看出，设置或重新设置一个通道的阻塞模式是很简单的，只要调用configureBlocking()方法即可，传递参数值为true则设为阻塞模式，参数值为false则设为非阻塞模式，就这么简单。同时，我们可以通过调用isBlocking()方法来判断某个Socket通道当前处于哪种模式中。

偶尔，我们也会需要放置Socket通道的阻塞模式被更改，所以API中有一个blockingLock()方法，该方法会返回一个非透明对象引用，返回的对象是通道实现修改阻塞模式时内部使用的，只有拥有此对象的锁的线程才能更改通道的阻塞模式，对于确保在执行代码的关键部分时Socket通道的阻塞模式不会改变以及在不影响其他线程的前提下暂时改变阻塞模式来说，这个方法是非常方便的。

Socket通道服务端程序

OK，接下来先看下Socket通道服务端程序应该如何编写：

整个代码流程大致上就是这样，没什么特别值得讲的，注意一下第18行~第22行，由于这里还没有讲到Selector，因此当客户端Socket没有到来的时候选择的处理办法是每隔1秒钟轮询一次。

Socket通道客户端程序

服务器端经常会使用非阻塞Socket通达，因为它们使同时管理很多Socket通道变得更容易，客户端却并不强求，因为客户端发起的Socket操作往往比较少，且都是一个接着一个发起的。但是，在客户端使用一个或几个非阻塞模式的Socket通道也是有益处的，例如借助非阻塞Socket通道，GUI程序可以专注于用户请求并且同时维护与一个或多个服务器的会话。在很多程序上，非阻塞模式都是有用的，所以，我们看一下客户端应该如何使用Socket通道：

总得来说和普通的Socket操作差不多，通过通道读写数据，非常方便。不过再次提醒，通道只能操作字节缓冲区也就是ByteBuffer的数据。

运行结果展示

上面的代码，为了展示结果的需要，在关键点上都加上了时间打印，这样会更清楚地看到运行结果。

首先运行服务端程序（注意不可以先运行客户端程序，如果先运行客户端程序，客户端程序会因为服务端未开启监听而抛出ConnectionException），看一下：

看到红色方块，此时程序是运行的，接着运行客户端程序：

看到客户端已经将"Hello World!"写入了Socket并通过通道传到了服务器端，方框变灰，说明程序运行结束了。此时看一下服务器端有什么变化：

看到服务器端打印出了字符串"Hello World!"，并且方框变灰，程序运行结束，这和代码是一致的。

注意一点，客户端看到的时间是XXX10307，服务器端看到的时间是XXX10544，这是很正常的，因为前面说过了，服务器端程序是每隔一秒钟轮询一次是否有Socket到来的。

当然，由于服务端程序的作用是监听1234端口，因此完全可以写客户端的代码，可以直接访问;f=6&g=7就可以了，看一下效果：

有了这个基础，我们就可以自己解析HTTP请求，甚至可以自己写一个Web服务器。

客户端Socket通道复用性的研究

这个是我今天上班的时候想到的一个问题，补充到最后。

服务器端程序不变，客户端现在是单个线程发送了一次数据到服务端的，假如现在我的客户端有多条线程同时通过Socket通道发送数据到服务端又会是怎么样的现象？首先将服务端端的代码稍作改变，让服务端SocketChannel在拿到客户端的数据之后程序不会停止运行而是会持续监听来自客户端的Socket，由于服务器端的代码比较多，这里只列一下改动的地方，：

接着看一下对客户端代码的启动，把写数据的操作放到线程的run方法中去：

启动了5个线程，我们可能期待服务端能有5次的数据到来，实际上是：

原因就是客户端的五个线程共用了同一个SocketChannel，这样相当于五个线程把数据轮番写到缓冲区，写完之后再把数据通过通道传输到服务器端。ByteBuffer的write方法放心，是加锁的，反编译一下sun.nio.ch.SocketChannelImpl就知道了，因此不会出现"Hello World!Thread-X"这些字符交叉的情况。

所以有了这个经验，我们让每个线程都new一个自己的SocketChannel，于是客户端程序变成了：

此时再运行，观察结果：

看到没有问题，服务器端分五次接收来自客户端的请求了。

当然，这也是有一定问题的：

1、如果服务器端开放多线程使用ServerSocket通道去处理来自客户端的数据的话，面对成千上万的高并发很容易地就会耗尽服务器端宝贵的线程资源

2、如果服务器端只有一条ServerSocket通道线程处理来自客户端的数据的话，一个客户端的数据处理得慢将直接影响后面线程的数据处理

这么一说似乎又回到了非阻塞I/O的老问题了。不过，Socket通道讲解到此，大体的概念我们已经清楚了，接着就轮到NIO的最后也是最难、最核心的部分----选择器，将在下一篇文章进行详细的讲解。