NIO编程很容易吗?不容易吗？很容易吗？不容易
吗？……
有些陷阱你需要知道
陷阱1：处理事件忘记移除key
在select返回值大于0的情况下，循环处理
Selector.selectedKeys 集合，每处理一个必须移除
Iterator<SelectionKey> it=set.iterator();
While(it.hasNext()){
SelectionKey key=it.next();
it.remove(); //切记移除
……处理事件
}
不移除的后果是本次的就绪的key集合下次会再次返
回,导致无限循环，CPU消耗100%
陷阱2：Selector返回的key集合非线程安全
1、Selector.selectedKeys/keys 返回的集合都是非线程安全的
2、Selector.selectedKeys返回的可移除
3、Selector.keys 不可变
4、 对selected keys的处理必须单线程处理或者适当同步
陷阱3：正确注册Channel和更新interest
1、 直接注册不可吗？
channel.register(selector, ops, attachment);
2、 不是不可以,效率问题
3、 至少加两次锁，锁竞争激烈
4、 Channel本身的regLock，竞争几乎没有
5、 Selector内部的key集合，竞争激烈
6、更好的方式:加入缓冲队列，等待注册，reactor单线程处理
If(isReactorThread()){
channel.register(selector, ops, attachment);
}
else{
register.offer(new Event(channel,ops,attachment));
selector.wakeup();
}
7、屏蔽平台差异，避免锁的激烈竞争，采用类似注册channel的方式：
if (this.isReactorThread()) {
key.interestOps(key.interestOps() | SelectionKey.OP_READ);
}
else {
this.register.offer(new Event(key,SelectionKey.OP_READ));
selector.wakeup();
}
陷阱4:正确处理OP_WRITE
1、 OP_WRITE处理不当很容易导致CPU 100%
2、 OP_WRITE触发条件
前提:interest了OP_WRITE
触发条件:
socket发送缓冲区可写
远端关闭
有错误发生
3 、正确的处理方式
4、 仅在已经连接的channel上注册
5、 仅在有数据可写的时候才注册
6、 触发之后立即取消注册，否则会继续触发导致循环
7、 处理完成后视情况决定是否继续注册
没有完全写入，继续注册
全部写入，无需注册
陷阱5：正确取消注册channel
1、 SelectableChannel一旦注册将一直有效直到明确取消
2、 怎么取消注册？
channel.close()，内部会调用key.cancel()
key.cancel();
3 、中断channel的读写所在线程引起的channel关闭
但是这样还不够！
key.cancel()仅仅是将key加入cancelledKeys 直到下一次select才真正处理，并且channel的socketfd只有在真正取消注册后才会close(fd)
4、后果是什么？
服务端，问题不大，select调用频繁
客户端，通常只有一个连接，关闭channel之后，没有调用select就关闭了selector
sockfd没有关闭，停留在CLOSE_WAIT状态
正确的处理方式，取消注册也应当作为事件交给reactor处理,及时wakeup做select
5、 适当的时候调用selector.selectNow()
6、 Netty 在超过256 连接关闭的时候主动调用一次selectNow
陷阱6：同时注册OP_ACCPET和OP_READ，同时注册OP_CONNECT和OP_WRITE
1、在底层来说，只有两种事件:read和write
Java NIO还引入了OP_ACCEPT和OP_CONNECT
OP_ACCEPT、OP_READ == Read
OP_CONNECT、OP_WRITE == Write
同时注册OP_ACCEPT和OP_READ ,或者同时注册OP_CONNECT和OP_WRITE在不同平台上产生错误的行为，避免这样做！
陷阱8：NIO的那些bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
http://bugs.sun.com/view_bug.do?bug_id=6693490
1、现象：导致已经关闭的连接一直处于就绪状态，select(timeout)不阻塞，CPU消耗100%
解决：
升级到jdk 6u4以上版本
代码上进行规避
2、代码如何规避此bug?
简单方案：在每次channel.close()之后马上调用select
Jetty 6的方案：
当select阻塞时间远远小于设置值
取消所有interest为0的key
重新创建Selector并注册有效的key
还不够健壮，select可能由于中断或者wakeup唤醒，导致误判
更完善:加入wakeup判断和中断状态判断
Mina有规避此bug的代码
Netty3，定期调用selectNow
最后忠告
1、 尽量不要尝试实现自己的nio框架，除非有经验丰富的工程师
2、 尽量使用经过广泛实践的开源NIO框架Mina、Netty3、xSocket
3、 尽量使用最新稳定版JDK
4、 遇到问题的时候，也许你可以先看下java的bug database