- 了解字符编码吗?说说你对它的了解？一个未知编码的文件，如果辨别文件的编码方式
https://blog.csdn.net/zhao__zhen/article/details/107684876 - netty的reactor 模型
单线程模型
Reactor单线程模型，指的是所有的IO操作都在同一个NIO线程上面完成，由这一个线程完成编码、解码、读取和发送等任务！
对于一些小容量应用场景，可以使用单线程模型。但是对于高负载、大并发的应用场景却不合适，主要原因如下：
- 性能稳定：一个NIO线程同时处理成百上千的链路，性能上无法支撑。
- 可靠性问题：一旦NIO线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。
多线程模型
Rector多线程模型与单线程模型最大的区别就是有一组NIO线程处理IO操作。有专门一个NIO线程-Acceptor线程用于监听服务端，接收客户端的TCP连接请求。网络IO操作-读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送；
在绝大多数场景下，Reactor多线程模型都可以满足性能需求；但是在一些特殊场景里面这种线程模型会出现性能问题：并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。在这类场景下，单独一个Acceptor线程可能会存在性能不足问题。
主从多线程模型
主从Reactor线程模型的特点是：服务端用于接收客户端连接的不再是个1个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到IO线程池（sub reactor线程池）的某个IO线程上，由它负责SocketChannel的读写和编解码工作。Acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。利用主从NIO线程模型，可以解决1个服务端监听线程无法有效处理所有客户端连接的性能不足问题。
- select epoll poll的理解
https://www.codenong.com/cs105364662/
-
Select
select，poll，epoll 都是 Linux 提供的 IO 多路复用的机制。IO 多路复用的本质是通过一种机制，让单个进程可以监视多个描述符，当发现某个描述符就绪之后，能够通知程序进行相应的读写操作。
select，poll，epoll 都是同步 IO。所谓同步 IO，便是读写是阻塞的，需要在读写事件就绪后自己负责读写，而异步 IO 会把数据从内核拷贝到用户空间，并不需要自己负责读写。
用户可以在一个线程内同时处理多个 socket 的 IO 请求。用户可以注册多个 socket，然后调用 select 函数读取被激活的 socket，从而实现在同一个线程内同时处理多个 IO 请求，在这点上select 函数与同步阻塞模型不同，因为在同步阻塞模型中需要通过多线程才能达到这个目的。 -
Poll
poll 的机制与 select 几乎相同，会对管理的描述符进行轮询操作，并根据描述符的状态进行相应的处理。poll 将用户传入的数组拷贝到内核空间，然后查询每个描述符对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有描述符后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时。
select 函数中，内核对 fd_set 集合的大小做出了限制，大小不可变为1024；而 poll 函数中，并没有最大文件描述符数量的限制（基于链表存储）。 -
EPoll
epoll 是基于事件驱动的 IO 方式，与 select 相比，epoll 并没有描述符个数限制。epoll 使用一个文件描述符管理多个描述符，它将文件描述符的事件放入内核的一个事件表中，从而在用户空间和内核空间的复制操作只用实行一次即可
socket通信https://www.runoob.com/java/net-serversocket-socket.html
两个数字字符串相加https://segmentfault.com/q/1010000015714183/
学生id 课程id 分数 找出挂科数>6
select *from T where socre <60 #不及格的学生课程
缓存不一致
缓存穿透
秒杀
效率 公平；
bean生命周期
项目 成就
解决问题
技术难度 技术深度
问：建议，具体问题，分析问题方法；积累；
593
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
