javaio模式
❶ java中IO与NIO的区别和使用场景
在java2以前，传统的socket IO中，需要为每个连接创建一个线程，当并发的连接数量非常巨大时，线程所占用的栈内存和CPU线程切换的开销将非常巨大。java5以后使用NIO，不再需要为每个线程创建单独的线程，可以用一个含有限数量线程的线程池，甚至一个线程来为任意数量的连接服务。由于线程数量小于连接数量，所以每个线程进行IO操作时就不能阻塞，如果阻塞的话，有些连接就得不到处理，NIO提供了这种非阻塞的能力。
NIO 设计背后的基石：反应器模式，用于事件多路分离和分派的体系结构模式。
反应器（Reactor）：用于事件多路分离和分派的体系结构模式
通常的，对一个文件描述符指定的文件或设备, 有两种工作方式: 阻塞 与非阻塞 。所谓阻塞方式的意思是指, 当试图对该文件描述符进行读写时, 如果当时没有东西可读,或者暂时不可写, 程序就进入等待 状态, 直到有东西可读或者可写为止。而对于非阻塞状态, 如果没有东西可读, 或者不可写, 读写函数马上返回, 而不会等待 。
一种常用做法是：每建立一个Socket连接时，同时创建一个新线程对该Socket进行单独通信（采用阻塞的方式通信）。这种方式具有很高的响应速度，并且控制起来也很简单，在连接数较少的时候非常有效，但是如果对每一个连接都产生一个线程的无疑是对系统资源的一种浪费，如果连接数较多将会出现资源不足的情况。
另一种较高效的做法是：服务器端保存一个Socket连接列表，然后对这个列表进行轮询，如果发现某个Socket端口上有数据可读时（读就绪），则调用该socket连接的相应读操作；如果发现某个 Socket端口上有数据可写时（写就绪），则调用该socket连接的相应写操作；如果某个端口的Socket连接已经中断，则调用相应的析构方法关闭该端口。这样能充分利用服务器资源，效率得到了很大提高。
传统的阻塞式IO，每个连接必须要开一个线程来处理，并且没处理完线程不能退出。
非阻塞式IO，由于基于反应器模式，用于事件多路分离和分派的体系结构模式，所以可以利用线程池来处理。事件来了就处理，处理完了就把线程归还。而传统阻塞方式不能使用线程池来处理，假设当前有10000个连接，非阻塞方式可能用1000个线程的线程池就搞定了，而传统阻塞方式就需要开10000个来处理。如果连接数较多将会出现资源不足的情况。非阻塞的核心优势就在这里。
为什么会这样，下面就对他们做进一步细致具体的分析：
首先，我们来分析传统阻塞式IO的瓶颈在哪里。在连接数不多的情况下，传统IO编写容易方便使用。但是随着连接数的增多，问题传统IO就不行了。因为前面说过，传统IO处理每个连接都要消耗一个线程，而程序的效率当线程数不多时是随着线程数的增加而增加，但是到一定的数量之后，是随着线程数的增加而减少。这里我们得出结论，传统阻塞式IO的瓶颈在于不能处理过多的连接。
然后，非阻塞式IO的出现的目的就是为了解决这个瓶颈。而非阻塞式IO是怎么实现的呢？非阻塞IO处理连接的线程数和连接数没有联系，也就是说处理 10000个连接非阻塞IO不需要10000个线程，你可以用1000个也可以用2000个线程来处理。因为非阻塞IO处理连接是异步的。当某个链接发送请求到服务器，服务器把这个连接请求当作一个请求"事件"，并把这个"事件"分配给相应的函数处理。我们可以把这个处理函数放到线程中去执行，执行完就把线程归还。这样一个线程就可以异步的处理多个事件。而阻塞式IO的线程的大部分时间都浪费在等待请求上了。
所谓阻塞式IO流，就是指在从数据流当中读写数据的的时候，阻塞当前线程，直到IO流可以
重新使用为止，你也可以使用流的avaliableBytes()函数看看当前流当中有多少字节可以读取，这样
就不会再阻塞了。
❷ java io流的典型使用方式有几种
Java中IO流分成两大类，
一种是输入流，所有的输入流都直接或间接继承自InputStream抽象类，输入流作为数据的来源，我们可以通过输入流的read方法读取字节数据；
另一种是输出流，所有的输出流都直接或间接继承自OutputStream抽象类，输出流接收数据，可以通过write方法写入字节数据。
Java的IO流类中，大部分的输入流和输出流都是成对存在的，即如果存在XXXInputStream，那么就存在XXXOutputStream，反之亦然。SequenceInputStream和StringBufferInputStream是特例，没有对应的SequenceOutputStream类和StringBufferOutputStream类，许多IO操作都可能会抛出IOException异常，比如read、write、close操作。
以下是Java的IO流中常见的输入流，由于每个输入流都有其对应的输出流，所以此处就不再列出输出流的继承结构图。
1、ByteArrayInputStream & ByteArrayOutputStream：
ByteArrayInputStream构造函数中需要传入一个byte数组作为数据源，当执行read操作时，就会从该数组中读取数据，正如其名，是一种基于字节数组实现的一种简单输入流，显而易见的是，如果在构造函数中传入了null作为字节数据，那么在执行read操作时就会出现NullPointerException异常，但是在构造函数初始化阶段不会抛出异常；与之相对应的是ByteArrayOutputStream，其内部也有一个字节数组用于存储write操作时写入的数据，在构造函数中可以传入一个size指定其内部的byte数组的大小，如果不指定，那么默认它会将byte数组初始化为32字节，当持续通过write向ByteArrayOutputStream中写入数据时，如果其内部的byte数组的剩余空间不能够存储需要写入的数据，那么那么它会通过调用内部的ensureCapacity
方法对其内部维护的byte数组进行扩容以存储所有要写入的数据，所以不必担心其内部的byte数组太小导致的IndexOutOfBoundsException之类的异常。
2、FileInputStream & FileOutputStream
FileInputStream 能够将文件作为数据源，读取文件中的流，通过File对象或文件路径等初始化，在其构造函数中，如果传入的File对象（或与其相对应的文件路径所表示的File对象）不存在或是一个目录而不是文件或者由于其他原因无法打开读取数据，都会导致在初始化阶段导致抛出FileNotFoundException异常；与FileInputStream 相对应的是FileOutputStream，可以通过FileOutputStream向文件中写入数据，也需要通过File对象或文件路径对其初始化，如同FileInputStream ，如果传入的File对象（或与其相对应的文件路径所表示的File对象）是一个目录而不是文件或者由于其他原因无法创建该文件写入数据，都会导致在初始化阶段抛出FileNotFoundException异常。
3、PipedInputStream & PipedOutputStream
PipedInputStream和PipedOutputStream一般是结合使用的，这两个类用于在两个线程间进行管道通信，一般在一个线程中执行PipedOutputStream 的write操作，而在另一个线程中执行PipedInputStream的read操作。可以在构造函数中传入相关的流将PipedInputStream 和PipedOutputStream 绑定起来，也可以通过二者的connect方法将二者绑定起来，一旦二者进进行了绑定，那么PipedInputStream的read方法就会自动读取PipedOutputStream写入的数据。PipedInputStream的read操作是阻塞式的，当执行PipedOutputStream的write操作时，PipedInputStream会在另一个线程中自动读取PipedOutputStream写入的内容，如果PipedOutputStream一直没有执行write操作写入数据，那么PipedInputStream的read方法会一直阻塞PipedInputStream的read方法所运行的线程直至读到数据。单独使用PipedInputStream或单独使用PipedOutputStream时没有任何意义的，必须将二者通过connect方法（或在构造函数中传入对应的流）进行连接绑定，如果单独使用其中的某一个类，就会触发IOException: Pipe Not Connected.
4、ObjectInputStream & ObjectOutputStream
ObjectOutputStream具有一系列writeXXX方法，在其构造函数中可以掺入一个OutputStream，可以方便的向指定的输出流中写入基本类型数据以及String，比如writeBoolean、writeChar、writeInt、writeLong、writeFloat、writeDouble、writeCharts、writeUTF等，除此之外，ObjectOutputStream还具有writeObject方法。writeObject方法中传入的类型必须实现了Serializable接口，从而在执行writeObject操作时将对象进行序列化成流，并将其写入指定的输出流中。与ObjectOutputStream相对应的是ObjectInputStream，ObjectInputStream有与OutputStream中的writeXXX系列方法完全对应的readXXX系列方法，专门用于读取OutputStream通过writeXXX写入的数据。
5、SequenceInputStream
SequenceInputStream 主要是将两个（或多个）InputStream在逻辑上合并为一个InputStream，比如在构造函数中传入两个InputStream，分别为in1和in2,那么SequenceInputStream在读取操作时会先读取in1，如果in1读取完毕，就会接着读取in2。在我们理解了SequenceInputStream 的作用是将两个输入流合并为一个输入流之后，我们就能理解为什么不存在对应的SequenceOutputStream 类了，因为将一个输出流拆分为多个输出流是没有意义的。
6、StringBufferInputStream
StringBufferInputStream允许通过在构造函数中传入字符串以读取字节，在读取时内部主要调用了String的charAt方法。与SequenceInputStream类似，StringBufferInputStream也没有对应的OutputStream，即不存在StringBufferOutputStream类。Java没有设计StringBufferOutputStream类的理由也很简单，我们假设StringBufferOutputStream存在，那么StringBufferOutputStream应该是内部通过执行write操作写入数据更新其内部的String对象，比如有可能是通过StringBuilder来实现，但是这样做毫无意义，因为一旦我们String的构造函数中可以直接传入字节数组构建字符串，简单明了，所以设计StringBufferOutputStream就没有太大的必要了。StringBufferInputStream这个类本身存在一点问题，它不能很好地将字符数组转换为字节数组，所以该类被Java标记为废弃的（Deprecated），其官方推荐使用StringReader作为代替。
7、FilterInputStream & FilterOutputStream
FilterInputStream包含了其他的输入流，说具体点就是在其构造函数中需要传入一个InputStream并将其保存在其名为in的字段中，FilterInputStream只是简单的覆盖了所有的方法，之所说是简单覆盖是因为在每个覆盖函数中，它只是调用内部的保存在in字段中的InputStream所对应的方法，比如在其覆盖read方法时，内部只是简单调用了in.read()方法。FilterInputStream的子类可以进一步覆盖某些方法以保持接口不变的情况下实现某一特性（比如其子类有的可以通过使用缓存优化读取的效率）或者提供一些其他额外的实用方法。所以在使用时FilterInputStream可以让传入的InputStream具有一些额外的特性，即对构造函数传入的InputStream进行了一层包裹，使用了典型的装饰着模式，如果只看FilterInputStream本身这一个类的话，则该类自己本身意义不大，因为其只是通过内部的字段in简单覆写某些方法。但是如果将FilterInputStream 和其子类结合起来使用话，那么就很有用了。比如FilterInputStream 有两个子类BufferedInputStream和DataInputStream，这两个类在下面还会详细介绍。BufferedInputStream对read操作做了优化，每次读操作时都读取一大块数据，然后将其放入内部维护的一个字节数组缓冲区中。当外面调用BufferedInputStream的read方法时，首先去该缓冲区中读取数据，这样就避免了频繁的实际的读操作，BufferedInputStream对外没有暴露额外的其他方法，但是其内部的read方法已经经过优化了，所以在执行读操作的时候效率更高。DataInputStream与ObjectInputStream有点类似，可以通过一些readXXX方法读取基本类型的数据，这是非常有用的一些方法。
8、BufferedInputStream & BufferedOutputStream
如上面所介绍的那样，在BufferedInputStream的构造函数中需要传入一个InputStream， BufferedInputStream内部有一个字节数组缓冲区，每次执行read操作的时候就从这buf中读取数据，从buf中读取数据没有多大的开销。如果buf中已经没有了要读取的数据，那么就去执行其内部绑定的InputStream的read方法，而且是一次性读取很大一块数据，以便填充满buf缓冲区。缓冲区buf的默认大小是8192字节，也就是8K，在构造函数中我们也可以自己传入一个size指定缓冲区的大小。由于我们在执行BufferedInputStream的read操作的时候，很多时候都是从缓冲区中读取的数据，这样就大大减少了实际执行其指定的InputStream的read操作的次数，也就提高了读取的效率。与BufferedInputStream 相对的是BufferedOutputStream。在BufferedOutputStream的构造函数中我们需要传入一个OutputStream，这样就将BufferedOutputStream与该OutputStream绑定在了一起。BufferedOutputStream内部有一个字节缓冲区buf，在执行write操作时，将要写入的数据先一起缓存在一起，将其存入字节缓冲区buf中，buf是有限定大小的，默认的大小是8192字节，即8KB，当然也可以在构造函数中传入size指定buf的大小。该buf只要被指定了大小之后就不会自动扩容，所以其是有限定大小的，既然有限定大小，就会有被填充完的时刻，当buf被填充完毕的时候会调用BufferedOutputStream的flushBuffer方法，该方法会通过调用其绑定的OutputStream的write方法将buf中的数据进行实际的写入操作并将buf的指向归零（可以看做是将buf中的数据清空）。如果想让缓存区buf中的数据理解真的被写入OutputStream中，可以调用flush方法，flush方法内部会调用flushBuffer方法。由于buf的存在，会大大减少实际执行OutputStream的write操作的次数，优化了写的效率。
❸ Java AIO - 异步IO详解
Java AIO，即异步IO，是一种高效的数据传输模式。与同步IO不同，AIO采用“订阅-通知”模式。应用程序向操作系统注册IO监听后，继续执行其他任务。当操作系统准备好数据并触发相应函数时，会主动通知应用程序。
异步IO由操作系统支持，微软Windows系统通过IOCP（I/O完成端口）实现，而Linux系统则使用epoll技术来模拟异步IO。
Java AIO框架基于此原理设计，针对不同操作系统提供相应的实现。在Windows系统中，使用IOCP技术，类如“sun.nio.ch.”；在Linux中，则通过epoll进行模拟。此类设计使得Java AIO在不同环境下的应用更加灵活。
Java AIO框架在类设计上清晰展示了与操作系统的紧密联系，实现了（服务器监听通道）和AsynchronousSocketChannel（socket套接字通道）两种网络IO通道。每个通道都拥有独立的fileDescriptor和attachment，用于文件标识和附件管理。
在Java AIO中，不需要“selector”（选择器）进行IO事件轮询和通道管理，因为应用程序采用订阅-通知模式。通道直接与操作系统注册监听，实现高效的数据交互。
Java AIO框架仅实现了两种网络IO通道，并通过SocketChannelReadHandle类实例化独立引用，提供了面向应用的通道接口。
示例代码和关键要点讲解涉及Java NIO框架中的“selector”概念，用于替代应用程序查询所有注册通道的IO事件。但在AIO框架中，这一概念不再适用，通道直接与操作系统交互。
在实践中，启动客户端（使用任何支持TCP Socket套接字的语言）与服务器端进行通信时，服务器端能够直接处理连接，无需轮询或选择器的干预，实现高效、流畅的数据传输。