-
Java NIO基础之ByteBuffer学习
Java NIO使用的数据结构不是普通的byte[],而是类似ByteBuffer的类。ByteBuffer使用起来与byte[]有很大不同,下面主要是自己学习到的一些使用方法。 ByteBuffer同时可以读写,一开始理解有点困难,建议按照推荐的操作步骤来使用ByteBuffer。即 Channel#read(ByteBuffer)或者ByteBuffer#put方法,往ByteBuffer里面写入数据 ByteBuffer#flip Channel#write(ByteBuffer)或者ByteBuffer#get方法,从ByteBuffer里面读取数据 ByteBuffer#clear, ByteBuffer#compact 读写模式通过不同的API来切换,一般情况下,按照上面这个顺序使用ByteBuffer就可以。不过要正确理解和使用ByteBuffer,需要对ByteBuffer的内部有所了解。 ByteBuffer主要有三个位置指针(不是C/C++的pointer) position,当前位置 limit,当前模式下的位置限制 capacity,分配时确定的空间大小 capacity因为一开始就被确定了,最容易理解。剩下两个位置指针需要配合ByteBuffer的“读写模式”来理解。 ByteBuffer被分配之后,默认是“写模式”,因为刚分配的空间你读取是没有意义的。这时position为0,limit为capacity的值。假设代码中执行了一些写入操作,每次写入都会增加position。 flip切换读写模式,position为0,即你写入的第一个byte的位置,limit变成你写入数据的最后一个byte后面的位置。 接下来你可以从ByteBuffer中读取数据了,每次读取增加position。 读取完毕之后,可以复用这个ByteBuffer,调用clear的话,position重置为0,limit设置为capacity,即回到写模式的初始状态。调用compact的话,你没有读取的数据会向前移动(System.arrayCopy),position设置为这些数据末尾之后的位置,limit设置为capacity。 用代码来测试一下
-
非阻塞IO与reactor模式
在写了非阻塞IO的基础知识之后,决定学习一下常规的非阻塞IO运行模式。 所谓运行模式,就是指以怎样的代码来实现非阻塞IO服务。为了比较和说明,先从阻塞IO的线程池化的服务器开始。 package in.xnnyygn.nio; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.net.ServerSocket; import java.net.Socket; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class BlockingIOEchoServer { private class EchoHandler implements Runnable { private final Socket socket; EchoHandler(Socket socket) { this.socket = socket; } @Override public void run() { System.out.println(“handle requests from ” + socket.getRemoteSocketAddress()); try { BufferedReader reader =…
-
非阻塞IO与异步IO
本文是自己对最近学习到的IO相关知识的一点整理,之后会逐渐增加。 首先非阻塞IO(non-blocking IO)相信很多人都听说过,比如Nginx,Redis,NodeJS等等。得到的印象大多是非阻塞IO比传统IO(blocking IO)要好。这里多少有点误解。 非阻塞IO的目的是高并发,比如C10K这种目标。在连接数不高的时候性能并不会比传统IO好。为什么传统IO难以做到C10K,主要原因还是可以建立的进程/线程数量有限,以及高并发情况下IO等待时间太多,阻塞进程/线程运行等原因。 当然非阻塞IO并不是完全非阻塞的,IO通常分为数据等待和数据从内核空间拷贝到用户空间的两部分,传统IO(阻塞IO)在这两个步骤都会阻塞,但是非阻塞IO只在数据拷贝的时候阻塞,数据等待时系统通常会返回一个特定的异常码来提示数据未准备好。 非阻塞IO是一个行为特征,具体实现有select/poll,Linux 2.6之后的epoll等IO多路复用的系统调用。直观上来讲,非阻塞IO和IO多路复用没有关系,但是如果你一直在某个fd(文件描述符)上轮询的话,就会变得和传统IO没有区别,所以一般都是在多个fd上等待,当其中某个数据就绪了再取数据,这样就可以体现在非阻塞IO在数据等待这一步非阻塞的优势了。 从编程语言来说,非阻塞也可以选择用注册callback异步调用来实现。实际的IO类型中也有异步IO,但是大部分人都不怎么谈到异步IO,说非阻塞IO其实就是指epoll,其原因之一是Linux上AIO(异步IO)实现差强人意,Windows上IO多路复用只有select,剩下的就是异步IO,即IOCP,Windows貌似希望开发人员使用IOCP而不是开发类似epoll在Windows上的实现。服务器端开发,你懂的,Windows的用武之地很少。 IO多路复用为什么epoll脱颖而出,主要还是他的数据通知机制。select虽然大部分平台都支持,但是fd有数量限制,1024个。poll消除了这个限制,但是得到数据就绪的响应之后,你必须遍历庞大的fd列表来得到就绪的fd。epoll的优势在于返回的响应中包含数据就绪的fd,综合各方面来说是最优的。 当然epoll是Linux的系统调用,如果在Windows上你只能用select,在Solaris上你需要/dev/poll,OS X是kqueue,通常编程语言会帮你统一API,比如Java。但是关于非阻塞IO的基本知识建议还是要了解一下。 参考: https://segmentfault.com/a/1190000003063859?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io#articleHeader12 http://blog.omega-prime.co.uk/?p=155 http://www.kegel.com/c10k.html
-
台場 2016-08-27
趁着台风来之前做点ingress任务,选择了台場。 查路线的时候鬼使神差地选了一个到现在为止我还读着拗口的「ゆりかもめ」电车,然后选择在「お台場海浜公園」下车。自然而然的我就开始做那个18个「お台場公園めぐり」连续任务了。 刚开始一两个我觉得还没什么,还觉得那两个不同颜色的缠在一起的管子挺好玩的。 任务一开始会往「お台場第三公園」方向走,那个公园人很少,从地图上看是一个正方向的公园,三面环海,中间有个盆地。
-
2016年8月25日
好久没有写博客了。但是VPS的钱还是要交,于是想着继续写点东西吧。 之前博客放置不写,有一个原因是没法升级到最新WP,今天查了下,感觉可能是服务器的防火墙的问题,增加了可以访问外部HTTPS网站之后就可以了。 小结就是iptables功力不够。 今天另外做的一件事情是换了主题,这样感觉就和以前不一样了。 暂时就这些。