nio

前言 在 Java NIO 中， 缓冲区 用来 临时 存储数据，可以理解为是 I/O 操作中数据暂存的中转站。 缓冲区 直接为 通道 ( Channel )服务，数据是从 通道 读入 缓冲区 ，从 缓冲区 写入到 通道 中的。 缓冲区 本质上是一块可以 写入数据 ，然后可以从中 读取数据 的内存。这块内存被包装成 NIO Buffer 对象，并提供了一组方法，用来方便的访问 这块内存 。 正文 Buffer的类型 Java NIO 提供以下几种 Buffer 类型： ByteBuffer MappedByteBuffer ShortBuffer LongBuffer FloatBuffer CharBuffer IntBuffer DoubleBuffer 这些 Buffer 类型代表了 Java 中7种基本数据类型。换句话说，就是可以通过 byte 、 char 、 short 、 int 、 long 、 float 或 double 类型来操作 缓冲区 中的数据。 Buffer的基本用法 使用 Buffer 读写数据一般遵循以下四个步骤： 写入数据到 Buffer 中； 调用 Buffer 的 flip() 方法； 从 Buffer 中读取数据； 调用 clear() 方法或者 compact() 方法。 当向 Buffer 写入数据时， Buffer 会记录下写了多少数据

欢迎回到淦™的源码看爆系列 在看完前面两个系列之后，相信大家对NIO也有了一定的理解，接下来我们就来深入源码去解读它，我这里的是OpenJDK-8u60版本，建议大家也下一份放ide里和我一起看会比较好理解。（这里主要介绍Selector，Buffer第一篇有提到一点，Channel也不过是些Buffer的操作方法而已，这里就不提及了，大家感兴趣可以自己去看） open() // 1. 创建Selector Selector selector = Selector.open(); 首先我们来分析open方法: // Selector public static Selector open() throws IOException { // 这里的静态方法provider会使用DefaultSelectorProvider.create();方法根据系统选择一个SelectorProvider // windows平台的话是WindowsSelectorProvider， // Linux平台是一个EPollSelectorProvider，这里主要分析Linux平台下的 // 之后openSelector方法(一会看下面)会返回一个EPollSelectorImpl作为Selector的实现，我们一般提及的Selector就是它了 return SelectorProvider

无处不在的C/S架构 在这个充斥着云的时代,我们使用的软件可以说99%都是C/S架构的！ 你发邮件用的Outlook,Foxmail等 你看视频用的优酷，土豆等 你写文档用的Office365,googleDoc，Evernote等 你浏览网页用的IE,Chrome等(B/S是特殊的C/S) ...... C/S架构的软件带来的一个明显的好处就是：只要有网络，你可以在任何地方干同一件事。 例如：你在家里使用Office365编写了文档。到了公司，只要打开编辑地址就可以看到在家里编写的文档，进行展示或者继续编辑。甚至在手机上进行阅读与编辑。不再需要U盘拷来拷去了。 C/S架构可以抽象为如下模型： C就是Client(客户端),上面的B是Browser(浏览器) S就是Server(服务器)： 服务器管理某种资源，并且通过操作这种资源来为它的客户端提供某种服务 C/S架构之所以能够流行的一个主要原因就是网速的提高以及费用的降低，特别是无线网络速度的提高。试想在2G时代，大家最多就是看看文字网页，小说什么的。看图片，那简直就是奢侈！更别说看视频了！ 网速的提高，使得越来越多的人使用网络，例如：优酷，微信都是上亿用户量，更别说天猫双11的瞬间访问量了！这就对服务器有很高的要求！能够快速处理海量的用户请求！那服务器如何能快速的处理用户的请求呢？ 高性能服务器

ByteBuf 组件 当我们进行数据传输的时候，往往需要使用到缓冲区，常用的缓冲区就是 JDK NIO类库 提供的 Buffer组件，7 种基本数据类型 ( Boolean 除外 ) 都有自己的缓冲区实现。对于 NIO编程 而言，我们主要使用的是 ByteBuffer。从功能角度而言，ByteBuffer 完全可以满足 NIO编程 的需 要，但是由于 NIO编程 的复杂性，ByteBuffer 也有其局限性，它的主要缺点如下。 ByteBuffer 长度固定，一旦分配完成，它的容量不能动态扩展和收缩，当需要编码的 POJO对象 大于 ByteBuffer 的容量时，会发生索引越界异常； ByteBuffer 只有一个标识位置的 指针position，读写的时候需要手工调用 flip() 和 rewind() 等，使用者必须小心谨慎地处理这些 API，否则很容易导致程序处理失败； ByteBuffer 的 API 功能有限，一些高级和实用的特性它不支持，需要使用者自己编程实现。 为了弥补这些不足，Netty 提供了自己的 ByteBuffer实现，即 ByteBuf, 下面我们看一下 ByteBuf 的原理和主要功能。 ByteBuf 工作原理 首先，ByteBuf 依然是个 Byte数组 的缓冲区，它的基本功能应该与 JDK 的 ByteBuffer 一致，提供以下几类基本功能。

一、概述 　　IO流用来处理设备之间的数据传输，上传文件和下载文件，Java对数据的操作是通过流的方式，Java用于操作流的对象都在IO包中。 　　流是一组有顺序的，有起点和终点的字节集合，是对数据传输的总称或抽象。即数据在两设备间的传输称为流，流的本质是数据传输，根据数据传输特性将流抽象为各种类，方便更直观的进行数据操作。 　　注：java把所有的传统的流类型都放到在java.io包下，用于实现输入和输出功能。 1.1、IO流分类 　　按照流的不同方向分为：输入流和输出流， 　　　　凡是含有in的，都可理解为输入流，输入流即从文件读取到程序，只能从中读取数据，而不能向其写入数据， 　　　　凡是含有out的，都可以理解为输出流，输出流即从程序输出到文件，只能向其写入数据，而不能向其读取数据。 　　　　输入，输出都是从程序运行所在的内存的角度来划分的。 　　按照实现功能不同可以分为：节点流和处理流。 　　　　可以从/向一个特定的IO设备（如磁盘，网络）读/写数据的流，称为节点流。节点流也被称为低级流。 　　　　处理流则用于对一个已存在的流进行连接和封装，通过封装后的流来实现数据的读/写功能。处理流也被称为高级流。 　　按照数据类型【单位分】：字节流：InputStream（字节输入流）、OutputStream（字节输出流）；字符流：Reader（字符输入流）、Writer

概要： Tomcat各核心组件认知 Tomcat server.xml 配置详解 Tomcat IO模型介绍 一、Tomcat各组件认知 Tomcat架构说明 Tomcat组件及关系详情介绍 Tomcat启动参数说明 Tomcat架构说明 1、Tomcat架构说明 Tomcat是一个基于JAVA的WEB容器，其实现了JAVA EE中的 Servlet 与 jsp 规范，与Nginx apache 服务器不同在于一般用于动态请求处理。在架构设计上采用面向组件的方式设计。即整体功能是通过组件的方式拼装完成。另外每个组件都可以被替换以保证灵活性。 那么是哪些组件组成了Tomcat呢？ 2、Tomcat 各组件及关系 Server 和 Service Connector 连接器 HTTP 1.1 SSL https AJP（ Apache JServ Protocol） apache 私有协议，用于apache 反向代理Tomcat Container Engine 引擎 catalina Host 虚拟机 基于域名 分发请求 Context 隔离各个WEB应用 每个Context的 ClassLoader都是独立 Component Manager （管理器） logger （日志管理） loader （载入器） pipeline (管道) valve （管道中的阀） 3

对于高性能的 RPC 框架，Netty 作为异步通信框架，几乎成为必备品。例如，Dubbo 框架中通信组件，还有 RocketMQ 中生产者和消费者的通信，都使用了 Netty。今天，我们来看看 Netty 的基本架构和原理。 Netty 的特点与 NIO Netty 是一个异步的、基于事件驱动的网络应用框架，它可以用来开发高性能服务端和客户端。 以前编写网络调用程序的时候，我们都会在客户端创建一个 Socket，通过这个 Socket 连接到服务端。 服务端根据这个 Socket 创建一个 Thread，用来发出请求。客户端在发起调用以后，需要等待服务端处理完成，才能继续后面的操作。这样线程会出现等待的状态。 如果客户端请求数越多，服务端创建的处理线程也会越多，JVM 如此多的线程并不是一件容易的事。 使用阻塞 I/O 处理多个连接 为了解决上述的问题，推出了 NIO 的概念，也就是（Non-blocking I/O）。其中，Selector 机制就是 NIO 的核心。 当每次客户端请求时，会创建一个 Socket Channel，并将其注册到 Selector 上（多路复用器）。 然后，Selector 关注服务端 IO 读写事件，此时客户端并不用等待 IO 事件完成，可以继续做接下来的工作。 一旦，服务端完成了 IO 读写操作，Selector 会接到通知，同时告诉客户端

Java IO模型 Java共支持3种网络编程模型/IO模式：BIO、NIO、AI BIO 同步并阻塞(传统阻塞型)，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销 适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序简单易理解。 存在问题： 每个请求都需要创建独立的线程，与对应的客户端进行数据Read，业务处理，数据Write 当并发数较大时，需要创建大量线程来处理连接，系统资源占用较大 连接建立后，如果当前线程暂时没有数据可读，则线程就阻塞在Read操作上，造成线程资源浪费 客户端 public class BIOClient { public static void main(String[] args) { // 通过构造函数创建Socket，并且连接指定地址和端口的服务端 try { Socket socket = new Socket(localhost, 6666); //开启一个线程接收消息 new ReadMsg(socket).start(); System.out.println("请输入信息"); PrintWriter pw = null; // 写数据到服务端 while (true) { pw =

IO的方式通常分为几种，同步阻塞的BIO、同步非阻塞的NIO、异步非阻塞的AIO。 一、BIO 在JDK1.4出来之前，我们建立网络连接的时候采用BIO模式，需要先在服务端启动一个ServerSocket，然后在客户端启动Socket来对服务端进行通信，默认情况下服务端需要对每个请求建立一堆线程等待请求，而客户端发送请求后，先咨询服务端是否有线程相应，如果没有则会一直等待或者遭到拒绝请求，如果有的话，客户端会线程会等待请求结束后才继续执行。 二、NIO NIO本身是基于事件驱动思想来完成的，其主要想解决的是BIO的大并发问题： 在使用同步I/O的网络应用中，如果要同时处理多个客户端请求，或是在客户端要同时和多个服务器进行通讯，就必须使用多线程来处理。也就是说，将每一个客户端请求分配给一个线程来单独处理。这样做虽然可以达到我们的要求，但同时又会带来另外一个问题。由于每创建一个线程，就要为这个线程分配一定的内存空间（也叫工作存储器），而且操作系统本身也对线程的总数有一定的限制。如果客户端的请求过多，服务端程序可能会因为不堪重负而拒绝客户端的请求，甚至服务器可能会因此而瘫痪。 NIO基于Reactor，当socket有流可读或可写入socket时，操作系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操作系统。 也就是说，这个时候，已经不是一个连接就要对应一个处理线程了