linuxhandler

1. 5.2 linux中断注册

注册中断最常用的函数是request_irq

第 1个参数 irq 为中断号
第 2 个参数 handler 为要中断服务函数
第 3 个参数 flags为中断标志位包含触发方式，是否共享，是否支持嵌套等
第 4 个参数 name，通常是 设备驱动程序的名称。该值用在 /proc/interrupt 系统文件上
第 5 个参数 dev 中断名称 可作为共享中断时的中断区别参数，也可以用来指定中断服务函数需要参考的数据地址。建议将 设备结构指针作为 dev参数

flags参数定义

注册中断的另一个函数是request_threaded_irq
request_threaded_irq是将中断处理函数线程化执行的接口，其实request_irq也是直接调用的request_threaded_irq，只不过线程化回调thread_fn设置为NULL，不进行中断处理程序线程化处理。

和request_irq的参数有少许差异
handler:表示中断服务例程，指向primary handler 和request_irq的中断处理函数handler类似。中断发生时优先执行primary handler；
如果primary handler 为NULL，且thread_fn不为NULL，那么执行默认primary handler = irq_default_primary_handler。
thread_fn：中断线程化，NULL表示没有中断线程化。thread_fn如果该参数不为NULL，内核会为该irq创建一个内核线程，
当中断发生时，如果handler回调返回值是IRQ_WAKE_THREAD，内核将会激活中断线程，
在中断线程中，该回调函数将被调用，所以，该回调函数运行在进程上下文中，允许进行阻塞操作。

其中

其中

2. Oracle SQL Handler文件拷贝到Linux怎么打开软件Handler

把程序打成jar包放到Linux上

转到目录下执行命令 hadoop jar maprecer.jar /home/clq/export/java/count.jar hdfs://ubuntu:9000/out06/count/

上面一个是本地文件，一个是上传hdfs位置

成功后出现：打印出来，你所要打印的字符。

package com.clq.hdfs;

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URI;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IOUtils;
import org.apache.hadoop.util.Progressable;

public class FileCopyWithProgress {
//********************************
//把本地的一个文件拷贝到hdfs上
//********************************
public static void main(String[] args) throws IOException {
String localSrc = args[0];
String dst = args[1];
InputStream in = new BufferedInputStream(new FileInputStream(localSrc));
Configuration conf = new Configuration();
FileSystem fs = FileSystem.get(URI.create(dst), conf);
FSDataOutputStream out = fs.create(new Path(dst), new Progressable() {
@Override
public void progress() {
System.out.print(".");
}
});
IOUtils.Bytes(in, out, conf, true);
}

}
可能出现异常：

Exception in thread "main" org.apache.hadoop.ipc.RemoteException: java.io.IOException: Cannot create /out06; already exists as a directory

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInternal(FSNamesystem.java:1569)

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFile(FSNamesystem.java:1527)

at org.apache.hadoop.hdfs.server.namenode.NameNode.create(NameNode.java:710)

at org.apache.hadoop.hdfs.server.namenode.NameNode.create(NameNode.java:689)

at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:587)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1432)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1428)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.Subject.doAs(Subject.java:415)

说明你这个路径在hdfs上已经存在，换一个即可。

3. linux输入子系统是轮询还是中断

与Linux设备驱动中中断处理相关的首先是申请与释放IRQ的API request_irq()和free_irq()，

request_irq()的原型为：

int request_irq(unsigned int irq,

void (*handler)(int irq, void *dev_id,
struct pt_regs *regs),

unsigned long irqflags,

const char * devname,

void *dev_id);

irq是要申请的硬件中断号；

handler是向系统登记的中断处理函数，是一个回调函数，中断发生时，系统调用这个函数，dev_id参数将被传递；

irqflags是中断处理的属性，若设置SA_INTERRUPT，标明中断处理程序是快速处理程序，快速处理程序被调用时屏蔽所有中断，慢速处理程序不屏蔽；若设置SA_SHIRQ，则多个设备共享中断，dev_id在中断共享时会用到，一般设置为这个设备的device结构本身或者NULL。

4. 关于 Handler 的这 20 个问题，你都清楚吗

Android 11 开始，AsyncTask 正式谢幕，变成了不推荐使用的 API。官方建议采用 Kotlin 协程替代，或者自行实现。

事实上，无论是 AsyncTask 还是协程，背后都有 Handler 的功劳。无论从普及原理的角度、还是从自行实现的角度，我们都需要吃透这个 Android 系统所特有的线程间通信方式Handler 机制！

初尝 Handler 机制的时候，原以为 Handler 类发挥了很大的作用。当你深入了解它的原理之后，会发现 Handler 只是该机制的 调用入口和回调 而已，最重要的东西是 Looper 和 MessagQueue，以及不断流转的 Message。

本次针对 Handler 机制常被提及和容易困扰的  20  个问题进行整理和回答，供大家解惑和回顾~

简述下 Handler 机制的总体原理？

Looper 存在哪？如何可以保证线程独有？

如何理解 ThreadLocal 的作用？

主线程 Main Looper 和一般 Looper 的异同？

Handler 或者说 Looper 如何切换线程？

Looper 的 loop() 死循环为什么不卡死？

Looper 的等待是如何能够准确唤醒的？

Message 如何获取？为什么这么设计？

MessageQueue 如何管理 Message？

理解 Message 和 MessageQueue 的异同？

Message 的执行时刻如何管理？

Handler、Mesage 和 Runnable 的关系如何理解？

IdleHandler 空闲 Message 了解过吗？有什么用？

异步 Message 或同步屏障了解过吗？怎么用？什么原理？

Looper 和 MessageQueue、Message 及 Handler 的关系？

Native 侧的 NativeMessageQueue 和 Looper 的作用是？

Native 侧如何使用 Looper？

Handler 为什么可能导致内存泄露？如何避免？

Handler 在系统当中的应用

Android 为什么不允许并发访问 UI？

1. 简述下 Handler 机制的总体原理？

Looper 准备和开启轮循：

尚无 Message 的话，调用 Native 侧的 pollOnce() 进入 无限等待

存在 Message，但执行时间 when 尚未满足的话，调用 pollOnce() 时传入剩余时长参数进入 有限等待

Looper#prepare() 初始化线程独有的 Looper 以及 MessageQueue

Looper#loop() 开启 死循环 读取 MessageQueue 中下一个满足执行时间的 Message

Message 发送、入队和出队：

Native 侧如果处于无限等待的话：任意线程向 Handler 发送 Message 或 Runnable 后，Message 将按照 when 条件的先后，被插入 Handler 持有的 Looper 实例所对应的 MessageQueue  中 适当的位置 。MessageQueue 发现有合适的 Message 插入后将调用 Native 侧的 wake() 唤醒无限等待的线程。这将促使 MessageQueue 的读取继续 进入下一次循环 ，此刻 Queue 中已有满足条件的 Message 则出队返回给 Looper

Native 侧如果处于有限等待的话：在等待指定时长后 epoll_wait 将返回。线程继续读取 MessageQueue，此刻因为时长条件将满足将其出队

Looper 处理 Message 的实现：

Looper 得到 Message 后回调 Message 的 callback 属性即 Runnable，或依据 target 属性即 Handler，去执行 Handler 的回调。

存在 mCallback 属性的话回调 Handler$Callback

反之，回调 handleMessage()

2. Looper 存在哪？如何可以保证线程独有？

Looper 实例被管理在静态属性 sThreadLocal 中

ThreadLocal 内部通过 ThreadLocalMap 持有 Looper，key 为 ThreadLocal 实例本身，value 即为 Looper 实例

每个 Thread 都有一个自己的 ThreadLocalMap，这样可以保证每个线程对应一个独立的 Looper 实例，进而保证 myLooper() 可以获得线程独有的 Looper

彩蛋：一个 App 拥有几个 Looper 实例？几个 ThreadLocal 实例？几个 MessageQueue 实例？几个 Message 实例？几个 Handler 实例

一个线程只有一个 Looper 实例

一个 Looper 实例只对应着一个 MessageQueue 实例

一个 MessageQueue 实例可对应多个 Message 实例，其从 Message 静态池里获取，存在 50 的上限

一个线程可以拥有多个 Handler 实例，其Handler 只是发送和执行任务逻辑的入口和出口

ThreadLocal 实例是静态的，整个进程 共用一个实例 。每个 Looper 存放的 ThreadLocalMap 均弱引用它作为 key

3. 如何理解 ThreadLocal 的作用？

首先要明确并非不是用来切换线程的， 只是为了让每个线程方便程获取自己的 Looper 实例 ，见 Looper#myLooper()

后续可供 Handler 初始化时 指定其所属的 Looper 线程

也可用来线程判断自己是否 是主线程

4. 主线程 Main Looper 和一般 Looper 的异同？

区别：

Main Looper  不可 quit

主线程需要不断读取系统消息和用书输入，是进程的入口，只可被系统直接终止。进而其 Looper 在创建的时候设置了 不可quit的标志 ，而 其他线程的 Looper 则可以也必须手动 quit

Main Looper 实例还被 静态缓存

为了便于每个线程获得主线程 Looper 实例，见 Looper#getMainLooper()，Main Looper 实例还作为 sMainLooper 属性缓存到了 Looper 类中。

相同点：

都是通过 Looper#prepare() 间接调用 Looper 构造函数创建的实例

都被静态实例 ThreadLocal 管理，方便每个线程获取自己的 Looper 实例

彩蛋：主线程为什么不用初始化 Looper？

App 的入口并非 MainActivity，也不是 Application，而是 ActivityThread。

其为了 Application、ContentProvider、Activity 等组件的运行，必须事先启动不停接受输入的 Looper 机制，所以在 main() 执行的最后将调用 prepareMainLooper() 创建 Looper 并调用 loop() 轮循。

不需要我们调用，也不可能有我们调用。

可以说如果主线程没有创建 Looper 的话，我们的组件也不可能运行得到！

5. Handler 或者说 Looper 如何切换线程？

Handler 创建的时候指定了其所属线程的 Looper，进而持有了 Looper 独有的 MessageQueue

Looper#loop() 会持续读取 MessageQueue 中合适的 Message，没有 Message 的时候进入等待

当向 Handler 发送 Message 或 Runnable 后，会向持有的 MessageQueue 中插入 Message

Message 抵达并满足条件后会唤醒 MessageQueue 所属的线程，并将 Message 返回给 Looper

Looper 接着回调 Message 所指向的 Handler Callback 或 Runnable，达到线程切换的目的

简言之，向 Handler 发送 Message 其实是向 Handler 所属线程的独有 MessageQueue 插入 Message。而线程独有的 Looper 又会持续读取该 MessageQueue。所以向其他线程的 Handler 发送完 Message，该线程的 Looper 将自动响应。

6. Looper 的 loop() 死循环为什么不卡死？

为了让主线程持续处理用户的输入，loop() 是 死循环 ，持续调用 MessageQueue#next() 读取合适的 Message。

但当没有 Message 的时候，会调用 pollOnce() 并通过 Linux 的 epoll 机制进入等待并释放资源。同时 eventFd 会监听 Message 抵达的写入事件并进行唤醒。

这样可以 空闲时释放资源、不卡死线程，同时能持续接收输入的目的 。

彩蛋1：loop() 后的处理为什么不可执行

因为 loop() 是死循环，直到 quit 前后面的处理无法得到执行，所以避免将处理放在 loop() 的后面。

彩蛋2：Looper 等待的时候线程到底是什么状态？

调用 Linux 的 epoll 机制进入 等待 ，事实上 Java 侧打印该线程的状态，你会发现线程处于 Runnable 状态，只不过 CPU 资源被暂时释放。

7. Looper 的等待是如何能够准确唤醒的？

读取合适 Message 的 MessageQueue#next() 会因为 Message 尚无或执行条件尚未满足进行两种等的等待：

无限等待

尚无 Message（队列中没有 Message 或建立了同步屏障但尚无异步 Message）的时候，调用 Natvie 侧的 pollOnce() 会传入参数  -1 。

Linux 执行 epoll_wait() 将进入无限等待，其等待合适的 Message 插入后调用 Native 侧的 wake() 向唤醒 fd 写入事件触发唤醒 MessageQueue 读取的下一次循环

有限等待

有限等待的场合将下一个 Message  剩余时长作为参数 交给 epoll_wait()，epoll 将等待一段时间之后 自动返回 ，接着回到 MessageQueue 读取的下一次循环

8. Message 如何获取？为什么这么设计？

享元设计模式：通过 Message 的静态方法 obatin() 获取，因为该方法不是无脑地 new，而是 从单链表池子里获取实例 ，并在 recycle() 后将其放回池子

好处在于复用 Message 实例，满足频繁使用 Message 的场景，更加高效

当然，缓存池存在上限  50 ，因为没必要无限制地缓存，这本身也是一种浪费

需要留意缓存池是静态的，也就是整个进程共用一个缓存池

9. MessageQueue 如何管理 Message？

MessageQueue 通过单链表管理 Message，不同于进程共用的 Message Pool，其是线程独有的

通过 Message 的执行时刻 when 对 Message 进行排队和出队

MessageQueue 除了管理 Message，还要管理空闲 Handler 和 同步屏障

10. 理解 Message 和 MessageQueue 的异同？

相同点：都是通过 单链表来管理  Message 实例；

Message 通过  obtain() 和 recycle()  向单链表获取插入节点

MessageQueue 通过  enqueueMessage() 和 next()  向单链表获取和插入节点

区别：

Message 单链表是 静态的，供进程使用的缓存池

MessageQueue 单链表 非静态，只供 Looper 线程使用

11. Message 的执行时刻如何管理？

发送的 Message 都是按照执行时刻 when 属性的先后管理在 MessageQueue 里

延时 Message 的 when 等于调用的当前时刻和 delay 之和

非延时 Message 的 when 等于当前时刻（delay 为 0）

插队 Message 的 when 固定为 0，便于插入队列的 head

之后 MessageQueue 会根据 读取的时刻和 when 进行比较

将 when 已抵达的出队，

尚未抵达的计算出 当前时刻和目标 when 的插值 ，交由 Native 等待对应的时长，时间到了自动唤醒继续进行 Message 的读取

事实上，无论上述哪种 Message 都不能保证在其对应的 when 时刻执行，往往都会延迟一些！因为必须等当前执行的 Message 处理完了才有机会读取队列的下一个 Message。

比如发送了非延时 Message，when 即为发送的时刻，可它们不会立即执行。都要等主线程现有的任务（Message）走完才能有机会出队，而当这些任务执行完 when 的时刻已经过了。假使队列的前面还有其他 Message 的话，延迟会更加明显！

彩蛋：. onCreate() 里向 Handler 发送大量 Message 会导致主线程卡顿吗？

不会，发送的大量 Message 并非立即执行，只是先放到队列当中而已。

onCreate() 以及之后同步调用的 onStart() 和 onResume() 处理，本质上也是 Message。等这个 Message 执行完之后，才会进行读取 Message 的下一次循环，这时候才能回调 onCreate 里发送的 Message。

需要说明的是，如果发送的是 FrontOfQueue 将 Message 插入队首也不会立即先执行，因为 onStart 和 onResume 是 onCreate 之后同步调用的，本质上是同一个 Message 的作业周期

12. Handler、Mesage 和 Runnable 的关系如何理解？

作为使用 Handler 机制的入口， Handler 是发送 Message 或 Runnable 的起点

发送的  Runnable 本质上也是 Message ，只不过作为 callback 属性被持有

Handler 作为 target 属性被持有在 Mesage 中 ，在 Message 执行条件满足的时候供 Looper 回调

事实上，Handler 只是供 App 使用 Handler 机制的 API，实质来说，Message 是更为重要的载体。

13. IdleHandler 空闲 Message 了解过吗？有什么用？

适用于期望 空闲时候执行，但不影响主线程操作 的任务

系统应用：

Activity destroy 回调就放在了 IdleHandler 中

ActivityThread 中 GCHandler 使用了 IdleHandler，在空闲的时候执行  GC  操作

App 应用：

发送一个返回 true 的 IdleHandler，在里面让某个 View 不停闪烁，这样当用户发呆时就可以诱导用户点击这个 View

将某部分初始化放在 IdleHandler 里不影响 Activity 的启动

14. 异步 Message 或同步屏障了解过吗？怎么用？什么原理？

异步 Message：设置了 isAsync 属性的 Message 实例

可以用异步 Handler 发送

也可以调用 Message#setAsynchronous() 直接设置为异步 Message

同步屏障：在 MessageQueue 的 某个位置放一个 target 属性为 null 的 Message ，确保此后的非异步 Message 无法执行，只能执行异步 Message

原理：当 MessageQueue 轮循 Message 时候 发现建立了同步屏障的时候，会去跳过其他 Message，读取下个 async 的 Message 并执行，屏障移除之前同步 Message 都会被阻塞

应用：比如 屏幕刷新 Choreographer 就使用到了同步屏障 ，确保屏幕刷新事件不会因为队列负荷影响屏幕及时刷新。

注意： 同步屏障的添加或移除 API 并未对外公开，App 需要使用的话需要依赖反射机制

15. Looper 和 MessageQueue、Message 及 Handler 的关系？

Message 是承载任务的载体，在 Handler 机制中贯穿始终

Handler 则是对外公开的 API，负责发送 Message 和处理任务的回调，是  Message 的生产者

MessagQueue 负责管理待处理 Message 的入队和出队，是  Message 的容器

Looper 负责轮循 MessageQueue，保持线程持续运行任务，是  Message 的消费者

彩蛋：如何保证 MessageQueue 并发访问安全？

任何线程都可以通过 Handler 生产 Message 并放入 MessageQueue 中，可 Queue 所属的 Looper 在持续地读取并尝试消费 Message。如何保证两者不产生死锁？

Looper 在消费 Message 之前要先拿到 MessageQueue  的锁， 只不过没有 Message 或 Message 尚未满足条件的进行等待前会事先释放锁 ，具体在于 nativePollOnce() 的调用在 synchronized 方法块的外侧。

Message 入队前也需先拿到 MessageQueue  的锁，而这时 Looper 线程正在等待且不持有锁，可以确保 Message 的成功入队。入队后执行唤醒后释放锁，Native 收到 event 写入后恢复 MessagQueue 的读取并可以拿到锁，成功出队。

这样一种在没有 Message 可以消费时执行等待同时不占着锁的机制，避免了生产和消费的死锁。

16. Native 侧的 NativeMessageQueue 和 Looper 的作用是？

NativeMessageQueue 负责连接 Java 侧的 MessageQueue，进行后续的 wait 和 wake，后续将创建 wake 的FD，并通过 epoll 机制等待或唤醒。 但并不参与管理 Java 的 Message

Native 侧也需要 Looper 机制，等待和唤醒的需求是同样的，所以将这部分实现都封装到了 JNI 的NativeMessageQueue  和  Native 的 Looper 中， 供 Java 和 Native 一起使用

17. Native 侧如何使用 Looper？

Looper Native 部分承担了 Java 侧 Looper 的等待和唤醒，除此之外其还提供了 Message、MessageHandler 或 WeakMessageHandler、LooperCallback 或 SimpleLooperCallback 等 API

这些部分可供 Looper 被 Native 侧直接调用，比如 InputFlinger 广泛使用了 Looper

主要方法是调用 Looper 构造函数或 prepare 创建 Looper，然后通过 poll 开始轮询，接着 sendMessage 或 addEventFd，等待 Looper 的唤醒。 使用过程和 Java 的调用思路类似

18. Handler 为什么可能导致内存泄露？如何避免？

持有 Activity 实例的内名内部类或内部类的 生命周期 应当和 Activity 保持一致，否则产生内存泄露的风险。

如果 Handler 使用不当，将造成不一致，表现为：匿名内部类或内部类写法的 Handler、Handler$Callback、Runnable，或者Activity 结束时仍有活跃的 Thread 线程或 Looper 子线程

具体在于：异步任务仍然活跃或通过发送的 Message 尚未处理完毕，将使得内部类实例的 生命周期被错误地延长 。造成本该回收的 Activity 实例 被别的 Thread 或 Main Looper 占据而无法及时回收 （活跃的 Thread 或 静态属性 sMainLooper 是 GC Root 对象）

建议的做法：

无论是 Handler、Handler$Callback 还是 Runnable，尽量采用 静态内部类 + 弱引用 的写法，确保尽管发生不当引用的时候也可以因为弱引用能清楚持有关系

另外在 Activity 销毁的时候及时地 终止 Thread、停止子线程的 Looper 或清空 Message ，确保彻底切断 Activity 经由 Message 抵达 GC Root 的引用源头（Message 清空后会其与 Handler 的引用关系，Thread 的终止将结束其 GC Root 的源头）

注意：静态的 sThreadLocal 实例不持有存放 Looper 实例的 ThreadLocalMap，而是由 Thread 持有。从这个角度上来讲，Looper 会被活跃的 GC Root Thread 持有，进而也可能导致内存泄露。

彩蛋：网传的 Handler$Callback 方案能否解决内存泄露？

不能。

Callback 采用内部类或匿名内部类写法的话，默认持有 Activity 的引用，而 Callback 被 Handler 持有。这最终将导致 Message -> Handler -> Callback -> Activity 的链条仍然存在。

19. Handler 在系统当中的应用

特别广泛，比如：

Activity 生命周期的管理

屏幕刷新

HandlerThread、IntentService

AsyncTask 等。

主要利用 Handler 的切换线程、主线程异步 Message 的重要特性。注意：Binder 线程非主线程，但很多操作比如生命周期的管理都要回到主线程，所以很多 Binder 调用过来后都要通过 Handler 切换回主线程执行后续任务，比如 ActviityThread$H 就是 extends Handler。

20. Android 为什么不允许并发访问 UI？

Android 中 UI 非线程安全，并发访问的话会造成数据和显示错乱。

但此限制的检查始于ViewRootImpl#checkThread()，其会在刷新等多个访问 UI 的时机被调用，去检查当前线程，非主线程的话抛出异常。

而 ViewRootImpl 的创建在 onResume() 之后，也就是说如果在 onResume() 执行前启动线程访问 UI 的话是不会报错的，这点需要留意！

彩蛋：onCreate() 里子线程更新 UI 有问题吗？为什么？

不会。

因为异常的检测处理在 ViewRootImpl 中，该实例的创建和检测在 onResume() 之后进行。

5. Handler消息机制（一）：Linux的epoll机制

在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。

相比select模型， poll使用链表保存文件描述符，因此没有了监视文件数量的限制 ，但其他三个缺点依然存在。

假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。

设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？

在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统(文件系统一般用什么数据结构实现？B+树)。把原先的select/poll调用分成了3个部分：

1）调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)

2）调用epoll_ctl向epoll对象中添加这100万个连接的套接字

3）调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

当某一进程调用epoll_create方法时，Linux内核会创建一个eventpoll结构体，这个结构体中有两个成员与epoll的使用方式密切相关。eventpoll结构体如下所示：

每一个epoll对象都有一个独立的eventpoll结构体，用于存放通过epoll_ctl方法向epoll对象中添加进来的事件。这些事件都会挂载在红黑树中，如此，重复添加的事件就可以通过红黑树而高效的识别出来(红黑树的插入时间效率是lgn，其中n为树的高度)。

而所有 添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法 。这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。

在epoll中，对于每一个事件，都会建立一个epitem结构体，如下所示：

当调用epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可。如果rdlist不为空，则把发生的事件复制到用户态，同时将事件数量返回给用户。

epoll结构示意图

通过红黑树和双链表数据结构，并结合回调机制，造就了epoll的高效。

events可以是以下几个宏的集合：
EPOLLIN：触发该事件，表示对应的文件描述符上有可读数据。(包括对端SOCKET正常关闭)；
EPOLLOUT：触发该事件，表示对应的文件描述符上可以写数据；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读（这里应该表示有带外数据到来）；
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP： 表示对应的文件描述符被挂断；
EPOLLET：将EPOLL设为边缘触发(EdgeTriggered)模式，这是相对于水平触发(Level Triggered)来说的。
EPOLLONESHOT： 只监听一次事件，当监听完这次事件之后，如果还需要继续监听这个socket的话，需要再次把这个socket加入到EPOLL队列里。
示例：

ET(EdgeTriggered) :高速工作模式，只支持no_block(非阻塞模式)。在此模式下，当描述符从未就绪变为就绪时，内核通过epoll告知。然后它会假设用户知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到某些操作导致那个文件描述符不再为就绪状态了。(触发模式只在数据就绪时通知一次，若数据没有读完，下一次不会通知，直到有新的就绪数据)

LT(LevelTriggered) :缺省工作方式，支持blocksocket和no_blocksocket。在LT模式下内核会告知一个文件描述符是否就绪了，然后可以对这个就绪的fd进行IO操作。如果不作任何操作，内核还是会继续通知！若数据没有读完，内核也会继续通知，直至设备数据为空为止！

1.我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
2. 这个时候从管道的另一端被写入了2KB的数据
3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
4. 然后我们读取了1KB的数据
5. 调用epoll_wait(2)……

ET工作模式：
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，在第2步执行了一个写操作，第三步epoll_wait会返回同时通知的事件会销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

只有当read(2)或者write(2)返回EAGAIN时(认为读完)才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时(即小于sizeof(buf))，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

LT工作模式：
LT方式调用epoll接口的时候，它就相当于一个速度比较快的poll(2)，并且无论后面的数据是否被使用，因此他们具有同样的职能。

当调用 epoll_wait检查是否有发生事件的连接时，只是检查 eventpoll对象中的 rdllist双向链表是否有 epitem元素而已，如果 rdllist链表不为空，则把这里的事件复制到用户态内存中，同时将事件数量返回给用户。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll对象中添加、修改、删除事件时，从 rbr红黑树中查找事件也非常快，也就是说，epoll是非常高效的，它可以轻易地处理百万级别的并发连接。

1.减少用户态和内核态之间的文件句柄拷贝；

2.减少对可读可写文件句柄的遍历。

https://cloud.tencent.com/developer/information/linux%20epoll%E6%9C%BA%E5%88%B6
https://blog.csdn.net/u010657219/article/details/44061629
https://jiahao..com/s?id=1609322251459722004&wfr=spider&for=pc

6. 在 linux中如何结束由一个父进程产生的所有子进程

父进程未结束，子进程先结束，会产生僵尸进程。
子进程在调用exit命令结束自己的生命的时候，其实它并没有真正的被销毁，而是留下一个称为僵尸进程（Zombie）的数据结构（系统调用 exit，它的作用是使进程退出，但也仅仅限于将一个正常的进程变成一个僵尸进程，并不能将其完全销毁）。
即使是root身份kill -9也不能杀死僵尸进程。补救办法是杀死僵尸进程的父进程(僵尸进程的父进程必然存在)，僵尸进程成为"孤儿进程"，过继给1号进程init，init始终会负责清理僵尸进程。
僵尸进程的避免：
(1) 父进程通过wait和waitpid等函数等待子进程结束，这会导致父进程挂起。
(2) 如果父进程很忙，那么可以用signal函数为SIGCHLD安装handler，因为子进程结束后， 父
进程会收到该信号，可以在handler中调用wait回收。
(3) 如果父进程不关心子进程什么时候结束，那么可以用signal（SIGCHLD, SIG_IGN） 通知内
核，自己对子进程的结束不感兴趣，那么子进程结束后，内核会回收， 并不再给父进程发送
信号。
(4) 还有一些技巧，就是fork两次，父进程fork一个子进程，然后继续工作，子进程fork一 个孙进
程后退出，那么孙进程被init接管，孙进程结束后， init会回收。不过子进程的回收 还要自己
做。
建议你使用第三种方法，父进程直接忽略子进程的结束，留给内核作回收处理。这样就不
会产生僵尸进程。

7. linux源代码中有很多变量以handler结尾，代表什么意思和window里面的句柄有什么区别

这里发估计没几个人都回答你，因为涉及到linux源代码。这个handler和句柄完全不是一回事，句柄的英文是handle：）
handler是处理程序的意思，比如中断有相应中断的内核中断处理程序 - interrupt handler；信号有信号处理程序 signal handler

我只能尽我最大力量回答你，我没看过内核代码，不过对内核还懂些。希望即使没帮到你 也启发了你

8. 如何在linux环境下实现进程之间的通信

linux环境下实现进程之间的通信主要有以下几种方式：

# 管道( pipe )：管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程关系。
# 有名管道 (named pipe) ： 有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。
# 信号量( semophore ) ： 信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
# 消息队列( message queue ) ： 消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息少、管道只能承载无格式字节流以及缓冲区大小受限等缺点。
# 信号 ( sinal ) ： 信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。
#共享内存( shared memory)：共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的IPC方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号量，配合使用，来实现进程间的同步和通信。
# 套接字( socket ) ： 套解口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同及其间的进程通信。

管道的主要局限性正体现在它的特点上：
只支持单向数据流；
只能用于具有亲缘关系的进程之间；
没有名字；
管道的缓冲区是有限的（管道制存在于内存中，在管道创建时，为缓冲区分配一个页面大小）；
管道所传送的是无格式字节流，这就要求管道的读出方和写入方必须事先约定好数据的格式，比如多少字节算作一个消息（或命令、或记录）等等；

9. Linux下通过哪个命令怎么查看中断

与Linux设备驱动中中断处理相关的首先是申请与释放IRQ的API request_irq()和free_irq()。

C++是一种面向对象的计算机程序设计语言，由美国AT&T贝尔实验室的本贾尼·斯特劳斯特卢普博士在20世纪80年代初期发明并实现，最初它被称作“C with Classes”（包含类的C语言）。

它是一种静态数据类型检查的、支持多重编程范式的通用程序设计语言，支持过程化程序设计、数据抽象、面向对象程序设计、泛型程序设计等多种程序设计风格。

在C基础上，一九八三年又由贝尔实验室的Bjarne Strou-strup推出了C++，C++进一步扩充和完善了C语言，成为一种面向 对象的程序设计语言。

C++目前流行的编译器最新版本是Borland C++ 4.5,Symantec C++ 6.1，和Microsoft Visual C++ 2012。

10. Linux内核中断之中断申请接口

本文基于 RockPI 4A 单板Linux4.4内核介绍中断申请的常用接口函数。

1、文件

2、定义

说明：

1）、 irq ：要申请的中断号，可通过 platform_get_irq() 获取，见“Linux内核中断之获取中断号”。

2）、 handler ：中断处理函数，发生中断时，先处理中断处理函数，然后返回 IRQ_WAKE_THREAD 唤醒中断处理线程。中断处理函数尽可能简单。

中断处理函数定义： typedef irqreturn_t (*irq_handler_t)(int, void *);

中断返回值如下：

3）、 thread_fn ：中断处理线程，该参数可为NULL。类似于中断处理函数的下半部分。

4）、 irqflags ：中断类型标志。

定义文件： include/linux/interrupt.h ，内容如下：

5）、 devname ：中断名称，可使用 cat /proc/interrupts 命令查看。

6）、 dev_id ：设备ID，该值唯一。

在使用共享中断时（即设置 IRQF_SHARED ），必须传入 dev_id ，在中断处理和释放函数中都会使用该参数。

注：

1、 request_threaded_irq() 函数可替代 request_irq 加 tasklet 或 workqueue 的方式。

2、对应的中断释放函数为： void free_irq(unsigned int, void *) ，需要和中断申请函数成对出现。

1、文件

2、定义

说明：

1）、 __must_check ：指调用函数一定要处理函数的返回值，否则编译器会给出警告。

2）、 request_irq() 函数本质上是中断处理线程 thread_fn 为空的 request_threaded_irq() 函数。

注 ：

对应的中断释放函数为： void free_irq(unsigned int, void *) ，需要和中断申请函数成对出现。

1、文件

2、定义

说明 ：

devm_request_threaded_irq() 本质上还是使用 request_threaded_irq() 函数实现中断申请。

两者区别：

1）多了一个 dev 参数；

2）在设备驱动卸载时，中断会自动释放；

3）如果想单独释放中断，可使用 void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id) 函数。

1、文件

2、定义

devm_request_irq() 函数本质上是中断处理线程 thread_fn 为空的 devm_request_threaded_irq() 函数。

1、获取中断号

2、申请中断

3、中断处理函数

4、中断处理线程

5、查看中断