正文
我只是想开个饭店—— JavaIO模型的演变
提示：扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
Java的IO。。。真的是我所见过的高级语言中。最最复杂的。。。
看着这个图我也是醉了。
但是不知不觉间，java的IO已经更新到了NIO.2了，IO库早已经不止是这个样子了，那么这个过程中，它们经历了怎么样的变化呢？在了解Java的IO之前，我们先来看看几种模型。
咱就是提供独家服务
在jdk没有推出NIO之前，java使用的IO模型都是BIO（Block Input Output）模型。那么什么是BIO模型呢？
简单来说就是一对一的服务。好比新开了一家餐厅，来了一位客人，就买一张桌子放到餐厅里面去（应该没有这么蠢的老板吧。。orz.....），来了一千位客人，就放一千张桌子……
“我去，餐厅不够大啊。。。。怎么破？”
这个时候只能任性了……
“买买买！咱再租一个场地，开个新店！”
这就是传统的BIO模型，相当“任性”的模型，服务端会使用一个Acceptor线程监听客户端的连接，每当一个客户机向服务端发起一个链接，服务端就创建一个线程（ Thread），当并发访问量增大，只能通过“买买买”的方法解决问题了。
那么问题来了，T^T.
“刚刚是做梦呢！我们真的好穷啊。”
开窍的老板
“咱搞个排号不就完事了么？”
咱就这么多桌子，事先都买好了，每次客人坐满了之后，之后来的客人只能在外面等着了（没办法，谁让咱的饭菜就是这么好吃！）。
这便是伪异步IO模型了。当客户端发起一个请求个服务端，服务端将请求封装成一个任务（Task）放入之前已经准备好的线程池（Thread Pool）。当并发请求数量超过线程池规定的大小时，迟一点发起的线程只能默默在队列中等待线程池中的资源了。
相比BIO模型，这个模型已经提升了很多性能了。
但是。。他还是伪异步IO模型！也许是名气太大了。越来越多的客人慕名而来。门口的等地区要挤爆了啊～～如果每桌的客户吃饭的时间又比较长（IO是阻塞的，需要等待IO执行完毕才会释放资源），咱根本hold不住啊！
是时候，展现我们的智慧了
我们更新了餐厅的排号系统，为了让有限的空间释放出最大的能量，我们也是蛮拼的。我们开始意识到客人是喜欢我们的食物的，那么让客人能及时地享用我们的食物才是最重要的（PM们，明确的需求分析很重要啊！）。
我们把排号系统放到了网上，大家可以点外卖啊。客人们事先点好需要的食物，我们把食物做好后送到客人面前（服务很贴心，有木有！）。在这个期间，客人们可以去做自己的事情，而不会因为等待时间过长而感到烦躁。
是的，这就是New IO，java在1.4版本之后，提供了新的IO库，当然在jdk1.7中，NIO已经被升级到NIO.2了。客户端发出请求后，请求会立即返回。当服务端准备好数据后，就会把数据送回客户端。（可以看下我上一篇的博客《Please Call Me NIO》）
总结
这里简单分析了几个IO模型，接下来，我会结合一些代码继续写几篇blog。
最后，但愿世界上没有这么无脑的餐厅～
