Java基础--IO篇 - Githubissues

1.什么是序列化？什么是反序列化？

如果我们需要持久化java对象比如将Java对象保存在文件中，或者在网络传输Java对象，这些场景都需要用到序列化。序列化：将数据结构或对象转换成二进制字节流binary byte stream（可以传输的形式）的过程 反序列化：将在序列化过程中所生成的二进制字节流转换成数据结构或对象的过程

为什么要二进制？总之不需要二进制

2.如果序列中有些字段不想进行序列化怎么办？

对于不想进行序列化的变量，使用transient关键词修饰。 Transient关键字的作用是：阻止实例中那些用此关键字修饰的变量序列化；当对象被反序列化时，被transient修饰的变量值不会被持久化和恢复不过要注意：Transient只能修饰变量，不能修饰类和方法

3.获取键盘输入常用的两种方式

1.通过scanner 2.通过BufferedReader

4.Java中IO流分为几种

其实最主要的是磁盘IO和读写IO

1.按照流的流向分，可以分为输入流和输出流 2.按照操作单元划分，可以划分为字节流和字符流 3.按照流的角色划分为节点流和处理流

Java40多个IO流涉及40多个类，实际上是从一下4个抽象类基类中派生出来的 InputStream/Reader:所有的输入流的基类，前者是字节输入流，后者是字符输入流 OutputStream/Writer:所有输出类的基类，前者是字节输出流，后者是字符输出流

按操作对象分类结构图

按操作方式分类结构图

6.五种IO模型

1.阻塞BIO

A拿着一支鱼竿在河边钓鱼，并且一直在鱼竿前等，在等的时候不做其他的事情，十分专心。只有鱼上钩的时，才结束掉等的动作，把鱼钓上来。 在内核将数据准备好之前，系统调用会一直等待所有的套接字，默认的是阻塞方式。

2.非阻塞NIO（noblocking I/O）

B也在河边钓鱼，但是B不想将自己的所有时间都花费在钓鱼上，在等鱼上钩这个时间段中，B也在做其他的事情（一会看看书，一会读读报纸，一会又去看其他人的钓鱼等），但B在做这些事情的时候，每隔一个固定的时间检查鱼是否上钩。一旦检查到有鱼上钩，就停下手中的事情，把鱼钓上来。 B在检查鱼竿是否有鱼，是一个轮询 polling mechanisms的过程。

3.异步AIO（asynchronous I/O）

C也想钓鱼，但C有事情，于是他雇来了D、E、F，让他们帮他等待鱼上钩，一旦有鱼上钩，就打电话给C，C就会将鱼钓上去。当应用程序请求数据时，内核一方面去取数据报内容返回，另一方面将程序控制权还给应用进程，应用进程继续处理其他事情，是一种非阻塞的状态。

4.信号驱动IO（signal blocking I/O）

G也在河边钓鱼，但与A、B、C不同的是，G比较聪明，他给鱼竿上挂一个铃铛，当有鱼上钩的时候，这个铃铛就会被碰响，G就会将鱼钓上来。信号驱动IO模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGIO信号进行捕捉，并且调用我的信号处理函数来获取数据报。

5.IO多路转接（I/O multiplexing）

H同样也在河边钓鱼，但是H生活水平比较好，H拿了很多的鱼竿，一次性有很多鱼竿在等，H不断的查看每个鱼竿是否有鱼上钩。增加了效率，减少了等待的时间。 IO多路转接是多了一个select函数，select函数有一个参数是文件描述符集合，对这些文件描述符进行循环监听，当某个文件描述符就绪时，就对这个文件描述符进行处理。 IO多路转接是属于阻塞IO，但可以对多个文件描述符进行阻塞监听，所以效率较阻塞IO的高。

7.IO多路复用（补充）

实际属于linux知识

7.1什么是IO多路复用

一句话解释：单线程或单进程同时监测若干个文件描述符是否可以执行IO操作的能力

7.2.具体怎么用

select、poll、epoll 重点：epoll epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

优点： 1.没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口） 2.效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。 3.内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

epoll对文件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别如下：

LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。

ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件

1.LT模式 LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的。

2.ET模式 ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

总结

在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。(此处去掉了遍历文件描述符，而是通过监听回调的的机制。这正是epoll的魅力所在。)

8.select, poll, epoll区别

1.支持一个进程所能打开的最大连接数

2.FD剧增后带来的IO效率问题 https://upload-images.jianshu.io/upload_images/2062729-34d8955371a90dad.png?imageMogr2/auto-orient/strip|imageView2/2/w/1168/format/webp

3.消息传递方式

综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点：

1.表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

2.select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善。

16.在面试中，当被问到 epoll 的使用原理时，你可以回答以下内容：

epoll 是 Linux 特有的 I/O 多路复用机制，用于高效地监视多个文件描述符的状态变化。它是基于事件驱动的机制，通过内核事件表（event table）来管理文件描述符。

使用 epoll 的主要步骤如下：

创建 epoll 实例（epoll_create）。将需要监视的文件描述符添加到 epoll 实例中（epoll_ctl）。进入事件循环（epoll_wait）。在事件循环中，epoll_wait 会阻塞并等待文件描述符上的事件发生。当文件描述符上的事件发生时，epoll_wait 会返回相关的事件信息。根据返回的事件信息，处理相应的 I/O 操作。 epoll 的使用原理基于以下几个关键点：

内核事件表：epoll 通过维护一个内核事件表来存储被监视的文件描述符和它们的状态信息。回调机制：epoll 使用回调机制，只对活动的文件描述符进行操作，而不需要遍历整个文件描述符集合。边缘触发（Edge-triggered）模式：epoll 支持边缘触发模式，在事件发生时只触发一次，需要用户自行处理剩余的数据。高效的事件通知机制：epoll 使用了内核与用户空间之间的共享内存区域，避免了传统的轮询机制，提供了高效的事件通知。当被问到 epoll 的使用原理时，你可以结合上述要点，解释 epoll 是如何利用内核事件表和回调机制来实现高效的 I/O 多路复用，以及边缘触发模式和高效的事件通知机制的优势。还可以提到 epoll 在高性能网络应用中的应用场景，并举例说明如何使用 epoll 来实现高并发的网络服务器。

poll is a Linux-specific I/O multiplexing mechanism used for efficiently monitoring the state changes of multiple file descriptors. It is an event-driven mechanism that manages file descriptors through an event table in the kernel.

The main steps involved in using epoll are as follows:

Create an epoll instance (epoll_create). Add the file descriptors to be monitored to the epoll instance (epoll_ctl). Enter the event loop (epoll_wait). In the event loop, epoll_wait blocks and waits for events to occur on the file descriptors. When an event occurs on a file descriptor, epoll_wait returns the relevant event information. Handle the I/O operations based on the returned event information. The usage principle of epoll is based on the following key points:

Event table: Epoll maintains an event table in the kernel to store the monitored file descriptors and their state information. Callback mechanism: Epoll uses a callback mechanism to operate only on active file descriptors, avoiding the need to iterate through the entire set of file descriptors.

Edge-triggered mode: Epoll supports edge-triggered mode, where an event is triggered only once when it occurs, and the remaining data needs to be handled by the user.

Efficient event notification mechanism: Epoll uses shared memory between the kernel and user space, eliminating the need for traditional polling mechanisms and providing efficient event notification.

lukaliou123 / lukaliou123.github.io

Java基础--IO篇 #4