知识点

最新推荐文章于 2023-04-10 09:50:02 发布

人间风流逍遥客

最新推荐文章于 2023-04-10 09:50:02 发布

阅读量161

点赞数

分类专栏：进阶

本文链接：https://blog.csdn.net/qq_40278997/article/details/113794713

版权

进阶专栏收录该内容

21 篇文章 0 订阅

订阅专栏

本文概述了IO多路复用技术，重点讲解了Epoll的工作原理，并深入探讨了进程和线程的关系，包括BIO、NIO和Reactor模型的应用。理解了同步异步、阻塞非阻塞的概念后，还将目光聚焦在Epoll如何提高网络I/O效率和线程管理上。

摘要由CSDN通过智能技术生成

IO中的同步、异步、阻塞、非阻塞的概念

epoll的原理：

进程和线程的关系

IO中的同步、异步、阻塞、非阻塞的概念

我们知道传统的BIO（Blocking）操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务。而 I/O 多路复用就是为了解决这个问题而出现的。
这里“多路”指的是多个网络连接（socket），“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），Reactor的设计模式就是基于NIO。
I/O多路复用实际上就是用select, poll, epoll技术等监听多个io对象，当io对象有变化（有数据）的时候就通知用户进程。好处就是单个进程可以处理多个socket。

epoll的原理：

epoll简单来讲就是有多个client连接（socket），kernel和reids之间是是用的是epoll的多路复用的模型，哪个连接有数据用一个线程我就处理哪个连接(监控所有的连接就是文件描述符fd，通过函数返回有数据变动的文件描述符号，然后再去read，epoll的实现，fd放在共享空间中存储在红黑树中，如果有数据来了准备好了，就会放在链表中去read)。

BIO ----》 NIO （同步非阻塞，自己去处理但是不阻塞） -----》Select(监控) ----》 poll ----> epoll的一个过程。

https://blog.csdn.net/yyoc97/article/details/85804654

参考：https://www.bilibili.com/video/BV1g5411j7AN?p=2（视频）

如果给钱的人是服务端，其他借钱的都是客户端，那么当前的请求还没有得到相应的话，阻塞的话是指其中一个没借完另外一个就不能借，非阻塞就是可以都进来，只不过处理的是先借給哪个人而已。

将一堆的socket维护在应用程序里，维护成一个链表。while循环消耗资源，理论上存在不会使用。

早期是select（）、poll（）函数，Epoll是较新的，将socke交由内核进行维护，由epoll不断的遍历这些socket，看哪些socket有一些活跃的事件

NIO的三种Reactor模型

进程和线程的关系

进程是系统中正在运行的一个程序，程序一旦运行就是进程。

进程可以看成程序执行的一个实例。进程是系统资源分配的独立实体，每个进程都拥有独立的地址空间。一个进程无法访问另一个进程的变量和数据结构，如果想让一个进程访问另一个进程的资源，需要使用进程间通信，比如管道，文件，套接字等。

一个进程可以拥有多个线程，每个线程使用其所属进程的栈空间。线程与进程的一个主要区别是，统一进程内的一个主要区别是，同一进程内的多个线程会共享部分状态，多个线程可以读写同一块内存（一个进程无法直接访问另一进程的内存）。同时，每个线程还拥有自己的寄存器和栈，其他线程可以读写这些栈内存。

线程是进程的一个实体，是进程的一条执行路径。

join

join是不能实现现线程之间交替运行的，比如说两条线程t1，t2在t1里调用t2.join是t2先运行完再来运行t1，注意是运行完。

AOP面试造火箭始末全解

https://mp.weixin.qq.com/s/9WQ5m7KhHe_tWCH0jba_kA

BeanPostProcessor

BeanPostProcessor是一个工厂钩子，允许Spring框架在新创建Bean实例时对其进行定制化修改。例如：通过检查其标注的接口或者使用代理对其进行包裹。应用上下文会从Bean定义中自动检测出BeanPostProcessor并将它们应用到随后创建的任何Bean上。

普通Bean对象的工厂允许在程序中注册post-processors，应用到随后在本工厂中创建的所有Bean上。典型的场景如：post-processors使用postProcessBeforeInitialization方法通过特征接口或其他类似的方式来填充Bean；而为创建好的Bean创建代理则一般使用postProcessAfterInitialization方法。

BeanPostProcessor本身也是一个Bean，一般而言其实例化时机要早过普通的Bean，但是BeanPostProcessor也会依赖一些Bean，这就导致了一些Bean的实例化早于BeanPostProcessor，由此会导致一些问题。最近在处理shiro和spring cache整合时就碰到了，导致的结果就是spring cache不起作用。现将问题场景、查找历程及解决方法展现一下。

springboot如何实现热部署

Spring Boot 官网给我提供了一个spring-boot-devtools这个工具jar包，而我们只许把这个jar宝引入项目就可以完成热部署。

修改项目pom.xml文件

<dependency>  
    <groupId>org.springframework.boot</groupId>  
    <artifactId>spring-boot-devtools</artifactId>  
    <optional>true</optional>
    <!-- 必须修改为true，默认是false -->
    <!-- optional=true,依赖不会传递，该项目依赖devtools；之后依赖myboot项目的项目如果想要使用devtools，需要重新引入 -->  
</dependency>