java nio socket的问题实例分析

本篇内容介绍了"java nio socket的问题实例分析"的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

第一个问题：

java nio的开发过程当中，在我们一个channel对象的时候，第一步就是要把它的阻塞模式配置为非阻塞。ServerSocketChannel.configureBlocking(false);

我们试图去了解一下这个configureBlocking函数究竟做了些什么事情，

但是最终我们找到了一个native的函数，具体内部干了些什么，貌似不是很容易了解。

那么我们试一下，把它配置为true的话，会发生什么样的事情。

结果，在register到selector上的时候，直接报错了。

java.nio.channels.IllegalBlockingModeException

关于这个问题，虽然没有得到一个确切的答案，不过貌似基本能够解决我们的一部分疑惑，要使用selector就只能是false。

第二个问题，有一个简单的java nio的例子，当中我们用到了SelectionKey当中3个值，OP_READ、OP_CONNECT、OP_ACCEPT。但是如果我们看一下java源码的话，会发现，其实还有一个值，叫做OP_WRITE，这个值究竟是怎么用的，因为在我们之前例子当中，server和client之间的数据交换已经基本完成，在收到read事件之后，通过channel把响应写回去，貌似没有OP_WRITE什么事啊！！！

首先我们对OP_READ、OP_CONNECT、OP_ACCEPT这几个值，重新进行一下解释，以OP_READ为例，应该解释为read就绪，换句话说，对方，已经向我写入数据了，这个时候开始读了。

那么OP_WRITE就好解释了，写就绪，那么写就绪的条件是什么呢？大体可以有2个条件，自己的写缓冲区是有空间的，网络环境是畅通的。

我们试一下，如果我们把一个SocketChannel的OP_WRITE注册到selector上的话，会发生什么样的事情。

修改一下之前的代码，Server端，接收一个客户端连接之后调用这样一句

channel.register(this.selector, SelectionKey.OP_WRITE);//原来是OP_READ

这样的话，因为网络是畅通的，本地的写缓冲区也是空间很充裕的，会一直试图做写的事情。

综上所述，在网络环境很好，以及写出的任务量不是很大的情况下，可能并不需要OP_WRITE的使用，而在某些高并发的情况下，OP_WRITE可能还是有其实际的用途的。

"java nio socket的问题实例分析"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！