当前位置:首页>Linux>不懂 RCU,别再说你懂 Linux 内核了

不懂 RCU,别再说你懂 Linux 内核了

  • 2026-08-19 12:34:41
不懂 RCU,别再说你懂 Linux 内核了

很多人学习 Linux 内核,都把重心放在进程调度、内存管理、文件系统这些经典模块,却常常忽略一个对高并发至关重要的核心机制 ——RCU。在 SMP 架构普及、多核性能不断提升的今天,RCU 早已成为内核同步的基石,从网络子系统到虚拟内存,从设备驱动到调度器,几乎无处不在。如果只懂自旋锁、互斥锁而不懂 RCU,很难真正理解 Linux 内核在高并发场景下的设计精髓。

RCU 全称 Read-Copy-Update,即读 - 复制 - 更新,它用一种近乎无锁的方式实现了高效同步,让读操作几乎没有开销,同时保证更新安全。与传统锁机制相比,RCU 在多读少写的场景下优势巨大,也是 Linux 能够支撑高吞吐、低延迟业务的关键技术之一。本文就从原理、实现、使用场景到内核源码,带你彻底吃透 RCU,补上这块内核进阶路上的重要短板。

一、RCU 是什么,能解决什么问题?

面试题写作模版

1.1 传统同步机制的瓶颈

在当今多核处理器盛行的时代,高并发编程成为了软件开发中绕不开的话题。尤其是在一些读多写少的场景下,传统的同步机制,如锁和原子操作,逐渐暴露出了它们的瓶颈。想象一下,一个繁忙的图书馆,读者们都在安静地查阅书籍(读操作),偶尔会有管理员来更新书籍信息(写操作)。如果使用传统的同步机制,管理员在更新书籍时,就像给图书馆大门上了一把锁,所有读者都得等待,直到管理员更新完毕。这在读者众多的情况下,无疑会大大降低图书馆的使用效率。

传统的同步机制,如自旋锁、互斥锁和读写锁等,在多核高并发环境下,会面临严重的锁竞争问题。当多个线程同时竞争同一把锁时,未获取到锁的线程要么自旋等待(自旋锁),浪费 CPU 资源;要么进入睡眠状态,等待被唤醒(互斥锁),这会带来额外的上下文切换开销。以读写锁为例,虽然允许多个线程同时读,但只要有一个线程持有写锁,其他读线程和写线程都必须等待,这在 “读多写少” 的场景中,会极大地影响读操作的性能。

再看原子操作,虽然它能保证单个操作的原子性,但在复杂的数据结构操作中,往往需要多个原子操作的组合,这就可能导致数据不一致的问题。而且,原子操作通常依赖于硬件指令,其性能也会受到硬件平台的限制。

在多核高并发的读多写少场景中,比如网络路由表的查询与更新、数据库索引的读取与修改等,大量的读操作会因为写操作的锁机制而被阻塞,导致系统的响应时间变长,吞吐量降低。这就好比在一条高速公路上,大部分车辆都在正常行驶(读操作),但偶尔有施工车辆(写操作)占道,就会造成交通拥堵,影响整体的通行效率。

1.2 什么是 Read - Copy - Update?

为了解决这些问题,RCU 应运而生。RCU,即 Read - Copy - Update,读 - 拷贝 - 更新,其核心思想非常巧妙:读操作无阻塞,写操作通过复制数据、修改副本、替换指针的方式进行,并且旧数据的释放会延迟到所有读操作完成之后,这个延迟的时间段被称为宽限期(Grace Period) 。

RCU(Read-Copy-Update)是一种针对读多写少场景设计的并发控制机制,其核心思想是通过允许读者在临界区内无锁访问共享数据来提升系统性能。在 RCU 机制中,读者(Readers)是指那些仅对共享数据进行读取操作的线程,而写者(Writers)则负责对共享数据进行修改的线程。临界区(Critical Section)是指读者或写者访问共享数据的代码区域,其中读端临界区(Reader-Side Critical Section)允许并发执行,而写端临界区(Writer-Side Critical Section)则需要通过同步机制保证互斥访问。

RCU 通过将写者的更新操作延迟到所有读者完成读端临界区后才释放旧数据,从而避免了传统锁机制中因竞争导致的性能开销。此外,RCU 中的宽限期(Grace Period)是一个重要概念,它定义了从写者开始更新操作到所有读者退出读端临界区的时间窗口,确保在此期间不会发生内存回收操作。

还是以图书馆为例,当管理员要更新书籍信息时,RCU 机制允许他先复制一份书籍副本,在副本上进行修改。修改完成后,再原子性地将新副本替换旧书籍(通过修改指针指向)。而在这个过程中,读者们仍然可以继续查阅旧书籍,不受影响。只有当所有正在查阅旧书籍的读者都离开后,管理员才会将旧书籍回收。这样,就大大提高了图书馆的使用效率,读者无需等待管理员更新书籍,管理员也能在不影响读者的情况下完成更新操作。

1.3 RCU 机制优势

RCU 机制在设计上通过读端操作的几乎无锁和无阻塞特性,显著降低了系统开销。其核心思想是将同步开销从读端转移到写端,从而在读多写少的场景中实现极高的并发性能。具体而言,RCU 允许读者在临界区内无需获取锁或进行任何阻塞操作,即可访问共享数据。这种实现方式避免了传统锁机制中因竞争而导致的上下文切换开销,同时减少了缓存行伪共享等问题对系统性能的影响。

此外,RCU 通过引入“宽限期”概念进一步优化了写端操作的开销,使得写者在修改共享数据时无需等待所有读者完成当前操作,而是仅需在宽限期结束后执行内存回收操作。这种延迟处理机制不仅减少了写端操作的同步开销,还提高了系统的整体吞吐量。因此,RCU 在读端操作的低开销特性使其在高并发环境中表现出色,尤其适用于对实时性和响应性要求较高的系统。

RCU 机制在实际应用中被证明能够显著提升系统性能,特别是在读多写少的场景下。例如,在 Linux 网络协议栈中,RCU 被广泛应用于路由表查找等关键操作的优化。研究表明,相较于传统的读写锁机制,RCU 在路由表查找操作中的性能提升了约 30%,同时降低了超过 50% 的锁竞争开销。

类似地,在文件系统中的应用也表明,RCU 能够有效减少目录项缓存操作的同步开销,从而提高文件系统的整体性能。实验数据表明,在高并发读操作场景下,RCU 的性能优势尤为明显,其吞吐量相较于其他同步机制提高了近两倍。这些实际案例充分展示了 RCU 机制在提升系统性能方面的卓越表现。此外,RCU 的高性能还体现在其对多核处理器的良好支持上。由于 RCU 在读端操作中避免了锁竞争和缓存一致性开销,它能够充分利用多核处理器的并行计算能力,从而实现更高的系统吞吐量和更低的延迟。

二、RCU 核心原理剖析

面试题写作模版

2.1 读 - 复制 - 更新流程

RCU 的读操作堪称 “轻装上阵”,它无需任何锁机制,也不涉及原子操作和内存屏障(除了 DEC Alpha 处理器这种特殊情况 )。当一个读线程想要访问共享数据时,它只需调用 rcu_read_lock()标记进入读端临界区,然后就可以直接读取数据,读取完成后再调用 rcu_read_unlock()标记离开临界区。这就好比在一个大型超市里,顾客(读线程)可以自由地在货架间穿梭(访问共享数据),无需排队等待(加锁),极大地提高了访问效率。在这个过程中,读线程完全不会阻塞其他线程,也不会被其他线程阻塞,真正实现了无阻塞的高效读取。

而写操作则像是一场精心策划的 “接力赛”,流程较为复杂。当写线程到来时,它首先要做的是复制旧数据,就像运动员接过上一棒的数据副本。例如,在一个网络设备链表管理场景中,写线程要更新链表中的某个节点数据,它会先分配一块新的内存,然后将旧节点的数据完整地拷贝到新内存中。接着,写线程在这个副本上进行修改,这就好比运动员在自己的赛道上对数据进行 “加工”。修改完成后,写线程会使用 rcu_assign_pointer()函数原子性地更新指针,将其指向新的副本,这一步就像是在接力赛中,运动员将修改好的数据 “传递” 给下一个阶段。

此时,新的读者线程将读取到新的数据,但旧的读者线程仍然可以继续读取旧数据,因为旧数据还未被释放。

最后,写线程需要等待所有旧读者退出,才能安全地释放旧数据。这就像是接力赛中,要确保所有之前参与的运动员都已经完成比赛(旧读者完成读取),才能清理赛道(释放旧数据)。在这个等待过程中,旧读者继续并行读取旧数据,而写者和新读者则处理新数据,实现了读写操作的高效并发。

2.2 宽限期(Grace Period)机制

宽限期是 RCU 机制中一个至关重要的概念,它就像是一个 “安全缓冲带”。简单来说,宽限期是指从写操作开始替换指针起,到所有在写操作之前开始的读操作都完成的这段时间。其作用是确保所有可能访问旧数据的读操作都已经完成,这样写操作就可以安全地释放旧数据,避免出现数据访问冲突。

在 Linux 内核中,宽限期的实现依赖于 CPU 的上下文切换。内核会周期性地进行上下文切换,当它发现每个 CPU 都至少经历过一次上下文切换时,就可以推断所有在指针替换之前就在运行的线程(可能持有旧数据的读者)肯定都已经切换出去了,它们的读临界区必然已经结束,此时宽限期就结束了。可以想象,每个 CPU 就像一个繁忙的工作间,当所有工作间都进行了一次大扫除(上下文切换),就意味着之前的工作(读操作)都已经完成,新的工作(写操作释放旧数据)就可以安全开展了。

为了等待宽限期结束,写者可以调用 synchronize_rcu()函数,这是一个同步接口,它会阻塞写线程,直到当前宽限期结束,之后就可以安全地释放旧数据。另一种方式是使用 call_rcu()函数,这是一个异步接口,它会注册一个回调函数,内核会在宽限期结束后自动调用这个回调函数,在回调函数中释放旧数据。这种异步方式更为常用,因为它不会阻塞写者,就像在一场音乐会上,观众(读线程)在欣赏演出,而工作人员(写线程)可以在后台准备下一个节目(进行写操作),等演出结束(宽限期结束),再进行场地清理(释放旧数据),互不干扰,大大提高了系统的并发性能。

2.3 线程安全与内存可见性保障

在多线程环境下,线程安全和内存可见性是必须要解决的重要问题。RCU 通过巧妙的设计,利用内存屏障等技术来确保这些关键特性。

对于线程安全,读操作无锁的特性本身就减少了锁竞争带来的线程安全问题。而写操作在更新指针时,使用 rcu_assign_pointer()函数,这个函数内部包含了必要的内存屏障(如 smp_wmb())。内存屏障就像是交通规则,它规定了指令的执行顺序,确保在屏障之前的所有写操作,必须先于在屏障之后的所有写操作完成,并且对其他 CPU 核心可见。在 RCU 的写操作中,这就保证了新指针指向的数据初始化完成后,其他线程才能看到新指针,避免了读到半初始化的数据,从而保障了线程安全。

在内存可见性方面,读线程使用 rcu_dereference()函数来获取受 RCU 保护的指针。这个函数确保在弱内存序的 CPU 上,读者能读到正确的指针值,并防止编译器进行有害的优化。同时,通过宽限期机制,保证了在旧数据被释放之前,所有读线程都能读到稳定的数据,不会因为数据的突然释放而导致内存访问错误。这就好比在一个共享的仓库里,所有的工人(线程)都遵循一定的规则(内存屏障和宽限期机制)来存取货物(数据),确保了每个工人都能看到一致的货物状态(内存可见性),避免了混乱和错误的发生。

2.4 读者与写者同步机制

读者与写者同步机制是 RCU 实现无锁并发的核心,RCU 本质上是一种高效的读者-写者同步模型,与传统读者-写者锁的“阻塞式同步”不同,RCU 采用“非阻塞式同步”,核心是“读不阻塞写、写不阻塞读”,完美适配读多写少的高并发场景。

RCU 中读者与写者的同步逻辑清晰且高效:读者线程无需加锁、无需等待,只需通过 rcu_read_lock()和 rcu_read_unlock()标记读临界区,即可直接访问共享数据,多个读者可并行访问,互不干扰,也不会被写者阻塞。写者线程则通过“复制-修改-替换”的流程执行更新操作,先复制旧数据生成副本,在副本上完成修改,再通过原子操作替换指针指向新副本,整个过程不会阻塞读者,读者仍可正常访问旧数据。

与传统读者-写者锁相比,RCU 彻底解决了“写阻塞读”的痛点:传统读写锁中,只要有写者持有写锁,所有读者都必须等待;而 RCU 中,写者操作不会影响读者,读者全程无阻塞,仅写者之间需要通过自旋锁等机制避免并发修改,极大提升了读操作的并发效率。需要注意的是,RCU 仅适用于“读多写少”场景,若写操作过于频繁,写者的复制、替换操作及宽限期等待会带来额外开销,此时传统读写锁可能更具优势。

2.5 RCU 的内存回收机制

RCU 的内存回收机制是保障数据安全的关键,核心是“延迟回收”——写者完成数据更新后,不会立即释放旧数据,而是等待所有正在访问旧数据的读者退出读临界区(即宽限期结束),再安全释放旧数据,避免出现悬空指针、内存访问错误等问题。

内存回收的完整流程与写者操作深度绑定:写者通过 rcu_assign_pointer()原子替换指针后,旧数据不再被新读者访问,但仍可能有旧读者在访问旧数据;写者通过 call_rcu()(异步)或 synchronize_rcu()(同步)触发回收操作,内核会等待宽限期结束,确认所有旧读者已退出读临界区,再通过回调函数释放旧数据内存。宽限期是内存回收的核心保障,内核通过检测每个 CPU 的“静止态”(如上下文切换、进入空闲状态、用户空间执行等),判断所有旧读者是否已完成读操作。当所有 CPU 都经历过至少一次静止态,即认为宽限期结束,此时旧数据已无读者访问,可安全回收。

RCU 提供两种内存回收方式:异步回收(call_rcu())无需阻塞写者,注册回调函数后写者可继续执行其他操作,内核在宽限期结束后自动触发回调释放内存;同步回收(synchronize_rcu())会阻塞写者,直到宽限期结束,适用于对内存回收及时性要求较高的场景(如模块退出)。

三、Linux 内核 RCU API 详解

面试题写作模版

在 Linux 内核中,RCU(Read-Copy-Update,读-复制-更新)提供了一系列简洁而强大的 API,这些 API 就像是一把把精巧的工具,为开发者在处理复杂的并发数据访问场景时,提供了极大的便利。以下将对 RCU 的核心 API 进行分类拆解,深入剖析其功能、原理及使用场景。

3.1 读端 API:读操作的开启与结束

读端 API 的核心作用是标记读操作的临界区,确保读操作能够无阻塞地并发执行,同时与写端操作协调,保障数据访问的安全性。核心 API 包括 rcu_read_lock 和 rcu_read_unlock。

rcu_read_lock 用于标记读端临界区的开始,它就像是在繁忙的交通路口设置了一个“读操作专用通道”的指示牌,告诉其他线程:“这里正在进行读操作,请不要干扰”。不过,这个“指示牌”并不会阻止其他线程的通行,只是起到一个标识作用——它不进行互斥锁的加锁操作,也不会阻塞其他读线程或写线程,仅用于告知内核“当前存在活跃的读操作”,确保读操作在这个临界区内能够无阻塞地进行。

rcu_read_unlock 则是读端临界区的“出口标志”,表示当前读操作已完成,内核可以记录该读线程已退出临界区。调用该函数后,读端临界区结束,其他线程(尤其是写线程)可以根据内核的记录,判断是否可以执行数据释放等后续操作。

这两个函数的使用非常简单,通常成对出现,包裹读操作的核心逻辑,但却至关重要——它们为读操作的无锁并发提供了基础保障,是 RCU 实现“读无阻塞”核心特性的关键。

// 示例:rcu_read_lock 和 rcu_read_unlock 的使用#include <linux/rcupdate.h>#include <linux/list.h>// 定义 RCU 保护的链表结构struct my_data {    int value;    struct list_head list;    struct rcu_head rcu; // 用于 RCU 回调释放};struct list_head my_list; // 全局链表头// 读操作:遍历链表并读取数据voidrcu_read_demo(void){    struct my_data *data;    // 标记读端临界区开始,无阻塞,不影响其他读/写线程    rcu_read_lock();    // 遍历 RCU 保护的链表(结合遍历 API,后续详细说明)    list_for_each_entry_rcu(data, &my_list, list) {        // 安全读取数据,无需加锁        printk("RCU read: data value = %d\n", data->value);    }    // 标记读端临界区结束,告知内核当前读操作完成    rcu_read_unlock();}

3.2 遍历 API:安全遍历 RCU 保护的数据

在并发场景中,遍历 RCU 保护的数据(如链表)时,需避免因写端修改数据导致的读取错误。RCU 提供的遍历 API 专门解决这一问题,核心包括 rcu_dereference 和 list_for_each_entry_rcu。

rcu_dereference 用于获取受 RCU 保护的指针,它就像是一把“安全钥匙”。在多 CPU、多线程环境中,指针的更新可能存在内存可见性问题,或因指令重排导致读取到无效指针。rcu_dereference 内部包含内存屏障相关操作,确保在读取指针时,能够获取到正确且稳定的值,避免因为指针的动态变化而导致读取到错误的数据或野指针。

list_for_each_entry_rcu 是一个专门用于遍历 RCU 保护链表的宏,它就像是一个智能的“导航仪”。与普通的链表遍历宏不同,它会结合 RCU 的机制,在遍历链表时跳过正在被写端修改的节点,确保遍历过程的完整性和正确性。例如,在一个网络设备链表中,当有写操作正在添加、删除或修改某个节点时,list_for_each_entry_rcu 可以确保读操作能够顺利遍历其他未被修改的节点,不会因写操作的干扰而出现遍历中断、数据错乱等问题。

// 示例:rcu_dereference 和 list_for_each_entry_rcu 的使用#include <linux/rcupdate.h>#include <linux/list.h>struct my_data {    int value;    struct list_head list;    struct rcu_head rcu;};struct list_head my_list;struct my_data *global_data __rcu; // 受 RCU 保护的全局指针// 读操作:安全读取指针并遍历链表voidrcu_traverse_demo(void){    struct my_data *data, *tmp;    rcu_read_lock();    // 安全获取 RCU 保护的全局指针,避免野指针和内存可见性问题    data = rcu_dereference(global_data);    if (data) {        printk("RCU dereference: data value = %d\n", data->value);    }    // 安全遍历 RCU 保护的链表,跳过正在修改的节点    list_for_each_entry_rcu(tmp, &my_list, list) {        printk("Traverse: data value = %d\n", tmp->value);    }    rcu_read_unlock();}

3.3 更新 API:写端修改数据的安全方法

写端的核心需求是修改数据并安全释放旧数据,同时不影响读端的无阻塞访问。RCU 提供的更新 API 主要用于协调写端与读端的操作,核心包括 call_rcu 和 synchronize_rcu。

call_rcu 是一个异步操作函数,它就像是一个“定时炸弹”(非贬义,仅形容延迟执行特性)。在写者完成数据修改并通过 rcu_assign_pointer 替换指针后,旧数据不能立即释放——因为可能还有活跃的读线程在访问旧数据。此时,call_rcu 会注册一个回调函数,将释放旧数据的操作延迟到“宽限期”(Grace Period)结束之后执行。内核会自动检测宽限期是否结束(即所有在指针替换前开始的读操作都已完成),当宽限期结束时,会自动调用注册的回调函数,安全释放旧数据。这种异步方式不会阻塞写线程,提高了写操作的效率。

synchronize_rcu 则是一个同步操作函数,它会阻塞写线程,直到宽限期结束,就像一个“等待室”。与 call_rcu 的异步特性不同,synchronize_rcu 会让写线程暂停执行,等待所有旧读者(指针替换前开始读操作的线程)完成读操作,待宽限期结束后,才允许写线程继续执行后续的旧数据释放等操作。这种方式适合对数据一致性要求极高、需要立即确认旧数据可安全释放的场景,但会牺牲一定的写操作效率。

// 示例:call_rcu 和 synchronize_rcu 的使用(写端更新)#include <linux/rcupdate.h>#include <linux/list.h>#include <linux/slab.h>struct my_data {    int value;    struct list_head list;    struct rcu_head rcu;};struct list_head my_list;struct my_data *old_data, *new_data;// call_rcu 的回调函数,用于释放旧数据voidrcu_free_old_data(struct rcu_head *rcu){    // 将 rcu_head 指针转换为 my_data 结构体指针    struct my_data *data = container_of(rcu, struct my_data, rcu);    // 释放旧数据内存    kfree(data);}// 异步更新:使用 call_rcu,不阻塞写线程voidrcu_call_demo(void){    // 分配并初始化新数据    new_data = kmalloc(sizeof(struct my_data), GFP_KERNEL);    new_data->value = 100;    // 替换指针(结合发布 API,后续详细说明)    rcu_assign_pointer(global_data, new_data);    // 异步释放旧数据,宽限期结束后调用回调函数    call_rcu(&old_data->rcu, rcu_free_old_data);}// 同步更新:使用 synchronize_rcu,阻塞写线程直到宽限期结束voidrcu_sync_demo(void){    new_data = kmalloc(sizeof(struct my_data), GFP_KERNEL);    new_data->value = 200;    // 替换指针    rcu_assign_pointer(global_data, new_data);    // 阻塞等待,直到所有旧读操作完成    synchronize_rcu();    // 此时可安全释放旧数据,无需回调    kfree(old_data);}

3.4 发布 API:原子更新 RCU 保护指针

写端修改数据后,需要将新数据的指针原子性地更新到 RCU 保护的指针变量中,确保读端能够正确获取到新数据。rcu_assign_pointer 作为发布 API 的核心,承担了这一关键职责。

rcu_assign_pointer 用于原子性地更新受 RCU 保护的指针,它就像是一场接力赛中的“交接棒”动作,必须准确无误。该函数内部包含了内存屏障操作,其核心作用有两个:一是确保新指针指向的数据已经完全初始化完成,不会出现读端读到半初始化数据的情况;二是确保新指针的更新对所有 CPU 核心可见,避免因 CPU 缓存、指令重排导致部分 CPU 读取到旧指针。

例如,在更新一个系统配置表的指针时,rcu_assign_pointer 能够确保新的配置数据已经全部准备好(初始化完成),并且所有 CPU 都能看到新的指针值,这样其他线程读取到的指针一定是指向完整可用的新数据,从而保证了数据的一致性和完整性。

// 示例:rcu_assign_pointer 的使用(原子更新指针)#include <linux/rcupdate.h>#include <linux/slab.h>// 定义系统配置表结构struct sys_config {    int max_conn; // 最大连接数    int timeout;  // 超时时间    struct rcu_head rcu;};// 受 RCU 保护的全局配置指针struct sys_config *global_config __rcu;// 更新系统配置,原子替换指针voidupdate_sys_config(int new_max_conn, int new_timeout){    // 分配新的配置结构体并初始化    struct sys_config *new_cfg = kmalloc(sizeof(struct sys_config), GFP_KERNEL);    new_cfg->max_conn = new_max_conn;    new_cfg->timeout = new_timeout;    // 原子更新 RCU 保护的指针,确保新数据初始化完成且全局可见    rcu_assign_pointer(global_config, new_cfg);    // 释放旧配置(可结合 call_rcu 或 synchronize_rcu,此处省略)}// 读端读取配置,结合读端和遍历 APIvoidread_sys_config(void){    struct sys_config *cfg;    rcu_read_lock();    // 安全获取配置指针    cfg = rcu_dereference(global_config);    if (cfg) {        printk("Max connection: %d, Timeout: %d\n", cfg->max_conn, cfg->timeout);    }    rcu_read_unlock();}

3.5 RCU 完整操作示例

下面通过一个完整的 C 语言可运行伪代码示例,来展示如何在实际场景中使用上述 API 进行 RCU 保护的数据结构操作。假设我们有一个简单的链表结构,用于存储一些整数数据,并且需要在多线程环境下安全地对链表进行读取和更新操作:

#include <linux/module.h>#include <linux/init.h>#include <linux/list.h>#include <linux/slab.h>#include <linux/rcupdate.h>// 定义链表节点结构struct my_node {    int data;    struct list_head list;    struct rcu_head rcu;};// 定义链表头staticLIST_HEAD(my_list_head);// 读操作函数voidmy_read_function(){    struct my_node *node;    rcu_read_lock();    // 使用 list_for_each_entry_rcu 遍历链表    list_for_each_entry_rcu(node, &my_list_head, list) {        printk(KERN_INFO "Reading data: %d\n", node->data);    }    rcu_read_unlock();}// 写操作函数voidmy_write_function(int new_data){    struct my_node *new_node, *old_node;    // 分配新节点内存    new_node = kmalloc(sizeof(struct my_node), GFP_KERNEL);    if (!new_node) {        return;    }    new_node->data = new_data;    // 使用自旋锁保护写操作,防止多写者冲突    spin_lock(&my_lock);    // 将新节点插入链表头部    list_add_rcu(&new_node->list, &my_list_head);    // 获取链表头部节点(旧节点)    old_node = list_first_entry_or_null(&my_list_head, struct my_node, list);    if (old_node) {        // 将旧节点从链表中移除        list_del_rcu(&old_node->list);        // 注册回调函数,用于宽限期结束后释放旧节点内存        call_rcu(&old_node->rcu, free_old_node);    }    spin_unlock(&my_lock);}// 旧节点释放回调函数voidfree_old_node(struct rcu_head *rcu){    struct my_node *node = container_of(rcu, struct my_node, rcu);    kfree(node);}staticint __init my_module_init(void){    printk(KERN_INFO "RCU Example Module Initialized\n");    return 0;}staticvoid __exit my_module_exit(void){    struct my_node *node, *next;    // 确保所有读操作完成,再进行链表清理    synchronize_rcu();    // 遍历链表,释放所有节点内存    list_for_each_entry_safe(node, next, &my_list_head, list) {        list_del(&node->list);        kfree(node);    }    printk(KERN_INFO "RCU Example Module Exited\n");}module_init(my_module_init);module_exit(my_module_exit);MODULE_LICENSE("GPL");MODULE_AUTHOR("Your Name");MODULE_DESCRIPTION("RCU Example Module");

在这个示例中,my_read_function 函数展示了如何使用读端 API 进行链表的安全遍历。my_write_function 函数则展示了写操作的完整流程,包括分配新节点、插入链表、移除旧节点以及注册回调函数来延迟释放旧节点内存。free_old_node 函数是回调函数,用于在宽限期结束后释放旧节点的内存。my_module_init 和 my_module_exit 函数分别是模块的初始化和退出函数,在退出函数中,使用 synchronize_rcu 确保所有读操作完成后,再清理链表资源。通过这个示例,我们可以清晰地看到 RCU API 在实际场景中的具体应用和协同工作方式。

四、RCU 底层实现探秘(内核源码视角)

面试题写作模版

4.1 核心数据结构与 CPU 状态追踪

在内核中,RCU 依赖于一系列精心设计的数据结构来实现其高效的读写操作协调。其中,rcu_state 和 rcu_data 是两个关键的数据结构 。rcu_state 是一个全局数据结构,它就像是一个 “总指挥”,维护着整个 RCU 机制的全局状态,包括宽限期的计数、屏障锁等重要信息。而 rcu_data 则是每个 CPU 私有的数据结构,它如同每个 CPU 的 “小助手”,记录着本地的回调队列和状态信息。以 Linux 内核中的代码为例,rcu_state 结构定义如下:

static struct rcu_state rcu_state = {   .level = { &rcu_state.node[0] },   .gp_state = RCU_GP_IDLE,   .barrier_mutex = __MUTEX_INITIALIZER(rcu_state.barrier_mutex),   .barrier_lock = __RAW_SPIN_LOCK_UNLOCKED(rcu_state.barrier_lock),    // ... 其他初始化字段};

在这个结构中,gp_state 字段用于表示宽限期的状态,barrier_mutex 和 barrier_lock 则用于实现屏障操作时的同步。rcu_data 结构则包含了诸如 gp_seq(指向当前宽限期编号)、cblist(需要处理的回调函数链表)等字段,这些字段对于追踪 CPU 状态和管理回调函数至关重要。通过这些数据结构,内核能够准确地追踪每个 CPU 的状态,判断其是否处于读操作中,以及协调读写操作的执行顺序,确保系统的高效运行。

4.2 宽限期检测机制

宽限期检测机制是 RCU 实现的核心部分,它的作用是确保所有读者都已完成对旧数据的访问,从而使写者能够安全地回收旧数据。在可抢占 RCU 中,宽限期的检测主要通过检测每个 CPU 是否经历至少一次 “静止态”(Quiescent State)来实现。

当一个写操作触发宽限期开始后,内核会等待所有 CPU 报告它们已经经历了静止态。以下情况被视为 CPU 经历了静止态:发生进程上下文切换(schedule()函数调用时),这就像是一场接力赛中的交接棒,当一个线程将执行权交给另一个线程时,就意味着前一个线程的读操作已经告一段落;处理器进入空闲状态(进入 idle 循环),此时 CPU 暂时没有任务可执行,也就不会有读操作在进行;在用户空间执行,因为用户空间的执行与内核的读操作是相互独立的;响应中断后退出中断上下文时,中断的处理通常会打断当前的执行流程,当中断处理完成并退出中断上下文时,也表明之前可能存在的读操作已经结束。

为了高效地管理这个过程,内核采用了分层树形结构(rcu_node/rcu_data)来聚合各 CPU 的状态。rcu_node 就像是一个 “汇总表”,将各个 CPU 的状态信息进行汇总和管理,最终由 rcu_gp_kthread 内核线程来驱动状态机的推进,判断宽限期是否结束。例如,在 rcu_gp_kthread 线程中,会不断检查各个 rcu_node 中的状态信息,当所有 CPU 都报告了静止态时,就判定宽限期结束,此时写者就可以安全地释放旧数据,完成整个写操作流程。

4.3 经典 RCU 与可抢占 RCU(PREEMPT_RCU)

经典 RCU 和可抢占 RCU 在设计和实现上存在一些关键的区别,这些区别决定了它们在不同场景下的适用性和性能表现。

经典 RCU 在默认配置下,读侧临界区内禁止抢占,这意味着在一个读操作执行期间,不会被其他高优先级的任务打断。这种设计使得经典 RCU 在性能上表现出色,因为它减少了上下文切换的开销,读操作可以一气呵成地完成。然而,这也限制了它在一些对实时性要求较高场景的应用,因为如果一个读操作长时间占用 CPU,其他紧急任务可能无法及时得到处理。

可抢占 RCU 则允许在 RCU 读侧临界区内发生内核抢占,这使得系统能够更及时地响应高优先级任务。在实时系统、网络栈、虚拟化等对延迟敏感的场景中,可抢占 RCU 具有明显的优势。例如,在网络栈中,当有紧急的数据包需要处理时,可抢占 RCU 能够及时让出 CPU 资源,确保数据包能够被快速处理,提高系统的实时响应能力。然而,由于可抢占 RCU 需要处理抢占带来的额外复杂性,如保存和恢复上下文等操作,它的实现相对复杂,性能开销也相对较大。在选择使用经典 RCU 还是可抢占 RCU 时,需要根据具体的应用场景和性能需求进行权衡。如果应用场景对性能要求较高,且对实时性要求不苛刻,经典 RCU 可能是更好的选择;反之,如果对实时性要求较高,可抢占 RCU 则能更好地满足需求。

4.4 软中断与 RCU 回调处理

软中断在 RCU 机制中扮演着重要的角色,它主要负责处理 RCU 回调函数,实现延迟操作和资源回收。Linux 系统专门为 RCU 预留了一个名为 RCU_SOFTIRQ 的软中断,并在系统启动阶段通过 rcu_init()函数为它注册对应的回调函数 rcu_core_si()。

RCU_SOFTIRQ 软中断的主要作用有两个:一是处理本 CPU 上已经进入 DONE 状态的 callback,这些 callback 通常是在宽限期结束后需要执行的操作,比如释放旧数据的内存等;二是检测并更新本 CPU 的 gp 编号,以及检测并上报本 CPU 的静止态,若有需要则唤醒 gp 线程。值得注意的是,RCU_SOFTIRQ 软中断是所有软中断中优先级最低的,这是为了避免它对其他更紧急的软中断任务造成干扰。

当一个写操作完成指针替换后,会通过 call_rcu()函数将回收旧数据的回调函数注册到当前 CPU 的回调链表中。在宽限期结束后,RCU_SOFTIRQ 软中断会被触发,rcu_core_si()回调函数会遍历回调链表,执行每个注册的回调函数,从而实现旧数据的安全释放。

例如,在一个文件系统的目录项管理场景中,当一个目录项被删除时,写操作会将删除目录项的回调函数注册到回调链表中,在宽限期结束后,软中断会执行这个回调函数,将目录项占用的内存释放,完成资源的回收。通过软中断和回调函数的配合,RCU 实现了高效的延迟操作和资源回收,保证了系统的稳定性和性能。

五、RCU 在内核中的典型应用场景

面试题写作模版

5.1 路由表与网络设备链表管理

网络子系统中,路由表和网络设备链表需频繁读取(用于数据包转发、设备状态查询)、偶尔更新(网络拓扑变化),RCU 凭借读无阻塞、写延迟更新的特性,大幅提升网络性能。

以路由表为例,当一个数据包到达时,内核需要快速查询路由表以确定转发路径。在高并发的网络环境下,可能会有大量的数据包同时到达,这就要求路由表的查询操作能够高效地并发执行。使用 RCU,读线程可以无锁地访问路由表,大大提高了查询速度。而当网络管理员对路由表进行更新时,写线程会先复制旧的路由表项,在副本上进行修改,然后通过原子操作更新指针,将新的路由表项替换旧的。在这个过程中,读线程仍然可以继续读取旧的路由表项,不会因为写操作而被阻塞,保证了网络数据包的正常转发。

RCU 保护路由表并发访问示例如下:

#include <linux/rcupdate.h>#include <linux/list.h>#include <linux/slab.h>#include <linux/printk.h>// 定义路由表项结构,包含目标网络、网关和 RCU 头struct route_entry {    unsigned int dest_net;    // 目标网络地址    unsigned int gateway;     // 网关地址    struct list_head list;    // 链表节点,用于挂载到路由表    struct rcu_head rcu;      // RCU 头,用于延迟释放};// 定义路由表(全局链表,受 RCU 保护)staticLIST_HEAD(route_table);// 读操作:查询路由表,根据目标网络获取网关(无锁操作)unsignedintroute_lookup(unsignedint dest_net){    struct route_entry *entry;    unsigned int gateway = 0;    // 进入 RCU 读临界区,标记读操作开始    rcu_read_lock();    // 使用 RCU 专用链表遍历宏,安全遍历受 RCU 保护的链表    list_for_each_entry_rcu(entry, &route_table, list) {        if (entry->dest_net == dest_net) {            gateway = entry->gateway;            break// 找到目标路由,退出遍历        }    }    // 退出 RCU 读临界区,标记读操作结束    rcu_read_unlock();    return gateway; // 返回查询到的网关,未找到则返回 0}// 写操作:添加新的路由表项(延迟更新,不阻塞读操作)introute_add(unsignedint dest_net, unsignedint gateway){    struct route_entry *new_entry, *old_entry;    // 分配新的路由表项内存    new_entry = kmalloc(sizeof(struct route_entry), GFP_KERNEL);    if (!new_entry) {        printk(KERN_ERR "Failed to allocate route entry\n");        return -ENOMEM;    }    // 初始化新路由表项数据    new_entry->dest_net = dest_net;    new_entry->gateway = gateway;    INIT_LIST_HEAD(&new_entry->list);    // 写操作需加自旋锁,防止多写者并发修改链表    spinlock_t route_lock;    spin_lock_init(&route_lock);    spin_lock(&route_lock);    // 检查是否存在相同目标网络的路由项,若存在则先移除旧项    list_for_each_entry_rcu(old_entry, &route_table, list) {        if (old_entry->dest_net == dest_net) {            // 从链表中移除旧路由项(RCU 专用移除宏)            list_del_rcu(&old_entry->list);            // 注册 RCU 回调,宽限期结束后释放旧路由项内存            call_rcu(&old_entry->rcu, free_route_entry);            break;        }    }    // 将新路由项插入链表头部(RCU 专用插入宏)    list_add_rcu(&new_entry->list, &route_table);    spin_unlock(&route_lock);    return 0;}// RCU 回调函数:宽限期结束后,释放旧路由表项内存voidfree_route_entry(struct rcu_head *rcu){    // 通过 RCU 头反向获取路由表项结构体    struct route_entry *entry = container_of(rcu, struct route_entry, rcu);    kfree(entry); // 释放内存}

上述代码是 Linux 内核中 RCU 保护路由表的典型实现,读操作通过 rcu_read_lock/rcu_read_unlock 标记临界区、list_for_each_entry_rcu 无锁遍历,写操作通过自旋锁保护多写者、call_rcu 延迟释放旧项,完全契合 RCU 核心逻辑。RCU 在网络设备链表管理中同样高效:读线程无阻塞遍历链表查询设备信息,写线程(设备新增/移除)按 RCU 流程操作,不影响读操作的正常执行。

5.2 进程 / 任务相关数据结构安全遍历

进程管理中,进程描述符链表、任务队列等数据结构,需安全遍历和操作,存储进程 ID、优先级等核心信息及调度相关数据。多线程环境下,读线程(如调度器)需无锁遍历进程链表,写线程(进程创建/销毁)需修改链表,RCU 可避免锁竞争和上下文切换开销,提升调度效率。

RCU 保护进程链表安全遍历示例如下:

#include <linux/rcupdate.h>#include <linux/list.h>#include <linux/sched.h>#include <linux/printk.h>// 简化的进程描述符结构体(模拟内核 task_struct 核心字段)struct my_task_struct {    pid_t pid;                // 进程 ID    char comm[16];            // 进程名称    struct list_head list;    // 链表节点,用于挂载到进程链表    struct rcu_head rcu;      // RCU 头,用于延迟释放};// 全局进程链表(受 RCU 保护,模拟内核进程链表)staticLIST_HEAD(task_list);// 读操作:遍历进程链表,打印所有进程 ID 和名称(无锁)voidtask_list_traverse(void){    struct my_task_struct *task;    // 进入 RCU 读临界区,开始无锁遍历    rcu_read_lock();    // RCU 专用链表遍历宏,确保遍历过程中不受写操作干扰    list_for_each_entry_rcu(task, &task_list, list) {        printk(KERN_INFO "PID: %d, Comm: %s\n", task->pid, task->comm);    }    // 退出 RCU 读临界区,结束遍历    rcu_read_unlock();}// 写操作:创建新进程,添加到进程链表(延迟更新)inttask_create(pid_t pid, constchar *comm){    struct my_task_struct *new_task;    // 分配进程描述符内存    new_task = kmalloc(sizeof(struct my_task_struct), GFP_KERNEL);    if (!new_task) {        printk(KERN_ERR "Failed to allocate task struct\n");        return -ENOMEM;    }    // 初始化进程描述符信息    new_task->pid = pid;    strncpy(new_task->comm, comm, sizeof(new_task->comm)-1);    new_task->comm[sizeof(new_task->comm)-1] = '\0';    INIT_LIST_HEAD(&new_task->list);    // 写操作加自旋锁,防止多写者并发修改    spinlock_t task_lock;    spin_lock_init(&task_lock);    spin_lock(&task_lock);    // 将新进程添加到链表尾部(RCU 专用插入宏)    list_add_tail_rcu(&new_task->list, &task_list);    spin_unlock(&task_lock);    printk(KERN_INFO "Task %d (%s) created\n", pid, comm);    return 0;}// 写操作:销毁进程,从链表中移除并延迟释放(RCU 回调)inttask_destroy(pid_t pid){    struct my_task_struct *task;    spinlock_t task_lock;    spin_lock_init(&task_lock);    spin_lock(&task_lock);    // 遍历链表查找目标进程(RCU 专用遍历宏)    list_for_each_entry_rcu(task, &task_list, list) {        if (task->pid == pid) {            // 从链表中移除进程(RCU 专用移除宏)            list_del_rcu(&task->list);            // 注册 RCU 回调,宽限期结束后释放进程描述符            call_rcu(&task->rcu, free_task_struct);            spin_unlock(&task_lock);            printk(KERN_INFO "Task %d destroyed\n", pid);            return 0;        }    }    spin_unlock(&task_lock);    printk(KERN_ERR "Task %d not found\n", pid);    return -EINVAL;}// RCU 回调函数:释放进程描述符内存voidfree_task_struct(struct rcu_head *rcu){    struct my_task_struct *task = container_of(rcu, struct my_task_struct, rcu);    kfree(task);}

读操作通过 RCU 无锁遍历进程链表,不被写操作阻塞;写操作(创建/销毁进程)通过自旋锁保护多写者并发,使用 RCU 专用链表操作宏,结合 call_rcu 延迟释放进程描述符,既保证了进程管理的安全性,又提升了并发效率。

5.3 虚拟内存与页表相关结构

虚拟内存和页表是现代操作系统内存管理的重要组成部分。虚拟内存使得每个进程都拥有独立的地址空间,而页表则负责将虚拟地址映射到物理地址。在内存访问过程中,需要频繁地查询页表,同时,当进程进行内存分配、释放或者页面置换时,页表也会被更新。

RCU 在虚拟内存与页表相关结构的管理中发挥了重要作用。读线程在查询页表时,可以无锁地进行操作,提高了内存访问的效率。而写线程在更新页表时,会按照 RCU 的流程,先复制相关页表项,在副本上进行修改,然后更新指针,确保在更新过程中,读线程仍然可以访问旧的页表项,不会因为写操作而导致内存访问错误,保证了内存访问的高效性和一致性。

RCU 保护页表项并发更新示例如下:

#include <linux/rcupdate.h>#include <linux/slab.h>#include <linux/printk.h>#include <asm/page.h>// 定义页表项结构(模拟内核页表项核心字段)struct page_table_entry {    unsigned long vaddr;      // 虚拟地址    unsigned long paddr;      // 物理地址    unsigned int flags;       // 页表项标志(如可读、可写)    struct rcu_head rcu;      // RCU 头,用于延迟释放};// 定义页表(数组形式,受 RCU 保护,简化实现)static struct page_table_entry **page_table;static int page_table_size = 1024// 页表大小(固定,简化处理)// 模块初始化:初始化页表内存intpage_table_init(void){    page_table = kmalloc(sizeof(struct page_table_entry *) * page_table_size, GFP_KERNEL);    if (!page_table) {        printk(KERN_ERR "Failed to allocate page table\n");        return -ENOMEM;    }    // 初始化所有页表项为 NULL    memset(page_table, 0sizeof(struct page_table_entry *) * page_table_size);    return 0;}// 读操作:查询页表,根据虚拟地址获取物理地址(无锁)unsignedlongpage_table_lookup(unsignedlong vaddr){    int index = vaddr / PAGE_SIZE; // 计算页表索引(简化页表映射)    struct page_table_entry *pte;    unsigned long paddr = 0;    if (index >= page_table_size) {        return 0// 索引越界,返回无效地址    }    // 进入 RCU 读临界区,无锁获取页表项    rcu_read_lock();    // 使用 rcu_dereference 获取受 RCU 保护的指针,确保内存可见性    pte = rcu_dereference(page_table[index]);    if (pte && (pte->flags & 0x01)) { // 检查页表项有效且可读        paddr = pte->paddr;    }    rcu_read_unlock();    return paddr;}// 写操作:更新页表项,映射虚拟地址到物理地址(延迟更新)intpage_table_update(unsignedlong vaddr, unsignedlong paddr, unsignedint flags){    int index = vaddr / PAGE_SIZE;    struct page_table_entry *new_pte, *old_pte;    if (index >= page_table_size) {        printk(KERN_ERR "Page table index out of range\n");        return -EINVAL;    }    // 分配新的页表项内存    new_pte = kmalloc(sizeof(struct page_table_entry), GFP_KERNEL);    if (!new_pte) {        printk(KERN_ERR "Failed to allocate page table entry\n");        return -ENOMEM;    }    // 初始化新页表项    new_pte->vaddr = vaddr;    new_pte->paddr = paddr;    new_pte->flags = flags;    // 原子更新页表指针(RCU 发布 API)    old_pte = rcu_xchg_pointer(&page_table[index], new_pte);    if (old_pte) {        // 注册 RCU 回调,宽限期结束后释放旧页表项        call_rcu(&old_pte->rcu, free_page_table_entry);    }    printk(KERN_INFO "Page table updated: vaddr=0x%lx -> paddr=0x%lx\n", vaddr, paddr);    return 0;}// RCU 回调函数:释放旧页表项内存voidfree_page_table_entry(struct rcu_head *rcu){    struct page_table_entry *pte = container_of(rcu, struct page_table_entry, rcu);    kfree(pte);}

读操作通过 rcu_read_lock 和 rcu_dereference 无锁查询页表,确保内存可见性;写操作通过 rcu_xchg_pointer 原子替换页表指针,结合 call_rcu 延迟释放旧页表项,避免写操作阻塞读操作,完美体现 RCU 在虚拟内存管理中的优势。

5.4 驱动与设备模型中的使用

在设备驱动和设备模型中,设备资源的安全共享和并发访问是一个关键问题。设备驱动程序需要与硬件设备进行交互,同时也需要与内核的其他部分进行通信,这就要求设备驱动程序能够正确地处理并发访问,确保设备资源的安全使用。

RCU 在设备驱动和设备模型中被广泛应用。例如,在设备链表管理中,系统中所有的设备通过链表连接在一起,驱动程序需要遍历这个链表来查找特定的设备,或者对设备进行操作。使用 RCU,读线程(驱动程序中的查询操作)可以无阻塞地遍历链表,获取所需的设备信息。而当有新设备插入或者旧设备移除时,写线程会使用 RCU 机制进行操作,先复制相关数据,修改副本,然后更新指针,确保链表的更新不会影响读操作的进行,保障了设备管理的高效性和稳定性。

RCU 保护设备链表驱动开发示例如下:

#include <linux/rcupdate.h>#include <linux/list.h>#include <linux/slab.h>#include <linux/printk.h>#include <linux/module.h>// 定义设备结构体(模拟设备驱动中的设备描述符)struct device_dev {    int dev_id;               // 设备 ID    char dev_name[32];        // 设备名称    struct list_head list;    // 链表节点,挂载到设备链表    struct rcu_head rcu;      // RCU 头,用于延迟释放    // 其他设备相关字段(如设备状态、寄存器地址等,简化省略)};// 全局设备链表(受 RCU 保护,驱动中用于管理所有设备)staticLIST_HEAD(device_list);// 读操作:根据设备 ID 查找设备(无锁,驱动中常用查询接口)struct device_dev *device_find(int dev_id) {    struct device_dev *dev;    // 进入 RCU 读临界区,无锁遍历设备链表    rcu_read_lock();    list_for_each_entry_rcu(dev, &device_list, list) {        if (dev->dev_id == dev_id) {            // 找到设备,退出临界区并返回            rcu_read_unlock();            return dev;        }    }    rcu_read_unlock();    return NULL// 未找到设备}// 写操作:添加新设备到设备链表(驱动中设备注册接口)intdevice_add(int dev_id, constchar *dev_name){    struct device_dev *new_dev;    // 分配设备结构体内存    new_dev = kmalloc(sizeof(struct device_dev), GFP_KERNEL);    if (!new_dev) {        printk(KERN_ERR "Failed to allocate device struct\n");        return -ENOMEM;    }    // 初始化设备信息    new_dev->dev_id = dev_id;    strncpy(new_dev->dev_name, dev_name, sizeof(new_dev->dev_name)-1);    new_dev->dev_name[sizeof(new_dev->dev_name)-1] = '\0';    INIT_LIST_HEAD(&new_dev->list);    // 写操作加自旋锁,防止多写者并发修改设备链表    spinlock_t dev_lock;    spin_lock_init(&dev_lock);    spin_lock(&dev_lock);    // 将新设备插入链表头部(RCU 专用插入宏)    list_add_rcu(&new_dev->list, &device_list);    spin_unlock(&dev_lock);    printk(KERN_INFO "Device %d (%s) added\n", dev_id, dev_name);    return 0;}// 写操作:移除设备(驱动中设备注销接口)intdevice_remove(int dev_id){    struct device_dev *dev;    spinlock_t dev_lock;    spin_lock_init(&dev_lock);    spin_lock(&dev_lock);    // 遍历设备链表查找目标设备(RCU 专用遍历宏)    list_for_each_entry_rcu(dev, &device_list, list) {        if (dev->dev_id == dev_id) {            // 从链表中移除设备(RCU 专用移除宏)            list_del_rcu(&dev->list);            // 注册 RCU 回调,宽限期结束后释放设备结构体            call_rcu(&dev->rcu, free_device_dev);            spin_unlock(&dev_lock);            printk(KERN_INFO "Device %d removed\n", dev_id);            return 0;        }    }    spin_unlock(&dev_lock);    printk(KERN_ERR "Device %d not found\n", dev_id);    return -EINVAL;}// RCU 回调函数:释放设备结构体内存voidfree_device_dev(struct rcu_head *rcu){    struct device_dev *dev = container_of(rcu, struct device_dev, rcu);    kfree(dev);}// 模块初始化与退出(驱动标准接口)staticint __init device_module_init(void){    printk(KERN_INFO "RCU Device Driver Module Initialized\n");    return 0;}staticvoid __exit device_module_exit(void){    struct device_dev *dev, *next;    // 等待所有读操作完成,再清理设备链表    synchronize_rcu();    // 遍历链表,释放所有设备内存    list_for_each_entry_safe(dev, next, &device_list, list) {        list_del(&dev->list);        kfree(dev);    }    printk(KERN_INFO "RCU Device Driver Module Exited\n");}module_init(device_module_init);module_exit(device_module_exit);MODULE_LICENSE("GPL");MODULE_DESCRIPTION("RCU Protected Device List Driver Example");

读操作(设备查询)无锁遍历设备链表,不阻塞写操作;写操作(设备注册/注销)通过自旋锁保护多写者并发,结合 RCU 延迟释放机制,确保设备链表操作的安全性和高效性,与内核中设备模型的 RCU 使用逻辑完全一致。

六、RCU 使用误区与避坑指南

面试题写作模版

6.1 读端临界区睡眠问题

在使用 RCU 时,有一个严格的规则:绝对不能在 RCU 读端临界区睡眠 。这是因为 RCU 的宽限期检测机制依赖于 CPU 的上下文切换,当一个 CPU 经历上下文切换时,内核会认为该 CPU 上可能存在的读操作已经完成,即进入了 “静止态”。如果在 RCU 读端临界区内调用了可能导致睡眠的函数,如 sleep()、wait_event()等,就会使当前 CPU 发生上下文切换,而此时内核会错误地认为该读操作已经结束,从而可能在还有读线程正在访问旧数据时,就提前结束宽限期,释放旧数据,导致读线程访问到已经被释放的内存,引发段错误、数据损坏等严重问题。

例如,在一个网络设备状态查询的场景中,读线程在 RCU 读端临界区内调用了 sleep()函数来等待某个条件满足,此时如果写线程开始进行设备状态更新操作,并等待宽限期结束后释放旧数据,由于读线程的睡眠导致上下文切换,内核可能会提前结束宽限期,释放旧数据,当读线程醒来继续访问设备状态数据时,就会访问到已经被释放的内存,造成程序崩溃。

6.2 内存释放的正确姿势

内存释放必须通过 RCU 回调来进行,这是确保内存安全释放的关键。在 RCU 机制中,写线程在完成数据更新并替换指针后,不能立即释放旧数据,因为此时可能还有读线程正在访问旧数据。正确的做法是使用 call_rcu()函数注册一个回调函数,将旧数据的释放操作延迟到宽限期结束之后。

以一个简单的链表节点删除操作为例,当写线程要删除链表中的某个节点时,它首先将该节点从链表中移除,然后调用 call_rcu()函数,将释放该节点内存的回调函数注册到内核的回调队列中。内核会在检测到宽限期结束后,自动调用这个回调函数,释放节点内存。如果不通过 RCU 回调,而是直接在写线程中释放内存,就会导致正在访问该节点的读线程出现内存访问错误,引发悬空指针问题,使程序的稳定性和安全性受到严重威胁。

6.3 与其他锁混合使用的陷阱

在实际应用中,有时可能需要将 RCU 与其他锁机制混合使用,但这种混合使用存在一些潜在的陷阱,需要特别小心。如果在 RCU 读端临界区内获取其他锁,并且其他线程在持有这些锁的同时进行 RCU 写操作,就可能导致死锁。例如,线程 A 在 RCU 读端临界区内获取了互斥锁,而线程 B 持有相同的互斥锁并进行 RCU 写操作,等待宽限期结束。由于线程 A 持有互斥锁,线程 B 无法完成宽限期检测(因为线程 A 的读操作可能还未结束),而线程 A 又因为在 RCU 读端临界区内不能被抢占(如果是经典 RCU),也无法释放互斥锁,从而导致死锁。

另外,混合使用不同的锁机制还可能导致性能下降。不同的锁机制有不同的开销和适用场景,不合理的混合使用可能会增加锁竞争和上下文切换的次数,降低系统的并发性能。因此,在混合使用 RCU 和其他锁机制时,一定要仔细分析业务场景,合理设计锁的使用策略,避免出现死锁和性能问题。

6.4 性能调优与场景判断

RCU 的性能调优需要根据具体的应用场景来进行。在一些对延迟敏感的场景中,可以通过调整内核参数 rcupdate.rcu_expedited=1 来使 RCU 进入加速模式,减少更新的延迟,但这会增加系统的 CPU 使用率,需要在性能和资源消耗之间进行权衡。对于大规模多核系统,可以使用 rcu_nocbs=all 参数,将 RCU 的更新工作从每个 CPU 核心的常规执行队列中分离出来,减少 CPU 核心之间的负担和内存访问的竞争,提高系统的整体性能。

在判断是否适合使用 RCU 时,关键是看应用场景是否符合读多写少的特点。如果写操作过于频繁,RCU 频繁的复制数据和等待宽限期的开销可能会导致性能下降,此时传统的锁机制可能更合适。同时,还要考虑数据一致性的要求,如果对数据一致性要求极高,RCU 在宽限期内可能导致读者读到旧数据的情况就需要谨慎对待。例如,在金融交易系统中,对数据一致性要求极高,就不太适合使用 RCU;而在网络设备状态监控系统中,读操作频繁,对数据一致性要求相对较低,使用 RCU 就能显著提高系统的并发性能。

往期文章推荐

图解TCP/IP协议,看图秒懂

图解C/C++ 多线程,看图秒懂

爆肝整理!嵌入式开发必知10种调试手段

【图解】SSH(安全外壳协议)工作原理

👉 【大厂技术栈路线】Linux C/C++ 后端开发系统学习路线

👉 【音视频】音视频流媒体高级开发核心学习路径

👉 Qt进阶】C++ Qt 桌面&嵌入式式开发一条龙学习攻略

👉 【内核底层】Linux 内核硬核修炼指南

👉 【面试冲刺】C/C++高频八股面试题1000 题(三)

👉 【项目实战】手撕线程池:C++序员的能力试金石

最新文章

随机文章

基本 文件 流程 错误 SQL 调试
  1. 请求信息 : 2026-08-22 02:32:45 HTTP/2.0 GET : https://f.mffb.com.cn/a/508462.html
  2. 运行时间 : 0.250563s [ 吞吐率:3.99req/s ] 内存消耗:4,602.20kb 文件加载:140
  3. 缓存信息 : 0 reads,0 writes
  4. 会话信息 : SESSION_ID=33273b32261902a471a545d69fc6227e
  1. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/public/index.php ( 0.79 KB )
  2. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/autoload.php ( 0.17 KB )
  3. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/composer/autoload_real.php ( 2.49 KB )
  4. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/composer/platform_check.php ( 0.90 KB )
  5. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/composer/ClassLoader.php ( 14.03 KB )
  6. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/composer/autoload_static.php ( 4.90 KB )
  7. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-helper/src/helper.php ( 8.34 KB )
  8. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-validate/src/helper.php ( 2.19 KB )
  9. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/helper.php ( 1.47 KB )
  10. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/stubs/load_stubs.php ( 0.16 KB )
  11. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Exception.php ( 1.69 KB )
  12. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-container/src/Facade.php ( 2.71 KB )
  13. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/symfony/deprecation-contracts/function.php ( 0.99 KB )
  14. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/symfony/polyfill-mbstring/bootstrap.php ( 8.26 KB )
  15. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/symfony/polyfill-mbstring/bootstrap80.php ( 9.78 KB )
  16. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/symfony/var-dumper/Resources/functions/dump.php ( 1.49 KB )
  17. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-dumper/src/helper.php ( 0.18 KB )
  18. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/symfony/var-dumper/VarDumper.php ( 4.30 KB )
  19. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/App.php ( 15.30 KB )
  20. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-container/src/Container.php ( 15.76 KB )
  21. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/psr/container/src/ContainerInterface.php ( 1.02 KB )
  22. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/provider.php ( 0.19 KB )
  23. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Http.php ( 6.04 KB )
  24. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-helper/src/helper/Str.php ( 7.29 KB )
  25. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Env.php ( 4.68 KB )
  26. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/common.php ( 0.03 KB )
  27. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/helper.php ( 18.78 KB )
  28. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Config.php ( 5.54 KB )
  29. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/app.php ( 0.95 KB )
  30. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/cache.php ( 0.78 KB )
  31. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/console.php ( 0.23 KB )
  32. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/cookie.php ( 0.56 KB )
  33. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/database.php ( 2.48 KB )
  34. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/facade/Env.php ( 1.67 KB )
  35. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/filesystem.php ( 0.61 KB )
  36. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/lang.php ( 0.91 KB )
  37. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/log.php ( 1.35 KB )
  38. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/middleware.php ( 0.19 KB )
  39. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/route.php ( 1.89 KB )
  40. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/session.php ( 0.57 KB )
  41. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/trace.php ( 0.34 KB )
  42. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/config/view.php ( 0.82 KB )
  43. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/event.php ( 0.25 KB )
  44. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Event.php ( 7.67 KB )
  45. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/service.php ( 0.13 KB )
  46. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/AppService.php ( 0.26 KB )
  47. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Service.php ( 1.64 KB )
  48. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Lang.php ( 7.35 KB )
  49. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/lang/zh-cn.php ( 13.70 KB )
  50. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/initializer/Error.php ( 3.31 KB )
  51. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/initializer/RegisterService.php ( 1.33 KB )
  52. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/services.php ( 0.14 KB )
  53. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/service/PaginatorService.php ( 1.52 KB )
  54. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/service/ValidateService.php ( 0.99 KB )
  55. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/service/ModelService.php ( 2.04 KB )
  56. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-trace/src/Service.php ( 0.77 KB )
  57. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Middleware.php ( 6.72 KB )
  58. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/initializer/BootService.php ( 0.77 KB )
  59. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/Paginator.php ( 11.86 KB )
  60. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-validate/src/Validate.php ( 63.20 KB )
  61. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/Model.php ( 23.55 KB )
  62. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/Attribute.php ( 21.05 KB )
  63. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/AutoWriteData.php ( 4.21 KB )
  64. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/Conversion.php ( 6.44 KB )
  65. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/DbConnect.php ( 5.16 KB )
  66. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/ModelEvent.php ( 2.33 KB )
  67. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/concern/RelationShip.php ( 28.29 KB )
  68. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-helper/src/contract/Arrayable.php ( 0.09 KB )
  69. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-helper/src/contract/Jsonable.php ( 0.13 KB )
  70. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/model/contract/Modelable.php ( 0.09 KB )
  71. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Db.php ( 2.88 KB )
  72. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/DbManager.php ( 8.52 KB )
  73. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Log.php ( 6.28 KB )
  74. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Manager.php ( 3.92 KB )
  75. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/psr/log/src/LoggerTrait.php ( 2.69 KB )
  76. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/psr/log/src/LoggerInterface.php ( 2.71 KB )
  77. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Cache.php ( 4.92 KB )
  78. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/psr/simple-cache/src/CacheInterface.php ( 4.71 KB )
  79. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-helper/src/helper/Arr.php ( 16.63 KB )
  80. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/cache/driver/File.php ( 7.84 KB )
  81. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/cache/Driver.php ( 9.03 KB )
  82. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/contract/CacheHandlerInterface.php ( 1.99 KB )
  83. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/Request.php ( 0.09 KB )
  84. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Request.php ( 55.78 KB )
  85. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/middleware.php ( 0.25 KB )
  86. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Pipeline.php ( 2.61 KB )
  87. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-trace/src/TraceDebug.php ( 3.40 KB )
  88. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/middleware/SessionInit.php ( 1.94 KB )
  89. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Session.php ( 1.80 KB )
  90. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/session/driver/File.php ( 6.27 KB )
  91. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/contract/SessionHandlerInterface.php ( 0.87 KB )
  92. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/session/Store.php ( 7.12 KB )
  93. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Route.php ( 23.73 KB )
  94. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/RuleName.php ( 5.75 KB )
  95. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/Domain.php ( 2.53 KB )
  96. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/RuleGroup.php ( 22.43 KB )
  97. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/Rule.php ( 26.95 KB )
  98. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/RuleItem.php ( 9.78 KB )
  99. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/route/app.php ( 1.72 KB )
  100. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/facade/Route.php ( 4.70 KB )
  101. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/dispatch/Controller.php ( 4.74 KB )
  102. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/route/Dispatch.php ( 10.44 KB )
  103. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/controller/Index.php ( 4.81 KB )
  104. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/app/BaseController.php ( 2.05 KB )
  105. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/facade/Db.php ( 0.93 KB )
  106. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/connector/Mysql.php ( 5.44 KB )
  107. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/PDOConnection.php ( 52.47 KB )
  108. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/Connection.php ( 8.39 KB )
  109. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/ConnectionInterface.php ( 4.57 KB )
  110. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/builder/Mysql.php ( 16.58 KB )
  111. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/Builder.php ( 24.06 KB )
  112. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/BaseBuilder.php ( 27.50 KB )
  113. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/Query.php ( 15.71 KB )
  114. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/BaseQuery.php ( 45.13 KB )
  115. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/TimeFieldQuery.php ( 7.43 KB )
  116. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/AggregateQuery.php ( 3.26 KB )
  117. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/ModelRelationQuery.php ( 20.07 KB )
  118. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/ParamsBind.php ( 3.66 KB )
  119. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/ResultOperation.php ( 7.01 KB )
  120. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/WhereQuery.php ( 19.37 KB )
  121. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/JoinAndViewQuery.php ( 7.11 KB )
  122. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/TableFieldInfo.php ( 2.63 KB )
  123. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-orm/src/db/concern/Transaction.php ( 2.77 KB )
  124. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/log/driver/File.php ( 5.96 KB )
  125. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/contract/LogHandlerInterface.php ( 0.86 KB )
  126. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/log/Channel.php ( 3.89 KB )
  127. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/event/LogRecord.php ( 1.02 KB )
  128. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-helper/src/Collection.php ( 16.47 KB )
  129. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/facade/View.php ( 1.70 KB )
  130. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/View.php ( 4.39 KB )
  131. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Response.php ( 8.81 KB )
  132. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/response/View.php ( 3.29 KB )
  133. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/Cookie.php ( 6.06 KB )
  134. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-view/src/Think.php ( 8.38 KB )
  135. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/framework/src/think/contract/TemplateHandlerInterface.php ( 1.60 KB )
  136. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-template/src/Template.php ( 46.61 KB )
  137. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-template/src/template/driver/File.php ( 2.41 KB )
  138. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-template/src/template/contract/DriverInterface.php ( 0.86 KB )
  139. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/runtime/temp/067d451b9a0c665040f3f1bdd3293d68.php ( 11.98 KB )
  140. /yingpanguazai/ssd/ssd1/www/f.mffb.com.cn/vendor/topthink/think-trace/src/Html.php ( 4.42 KB )
  1. CONNECT:[ UseTime:0.000430s ] mysql:host=127.0.0.1;port=3306;dbname=f_mffb;charset=utf8mb4
  2. SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000523s ]
  3. SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000305s ]
  4. SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.001265s ]
  5. SHOW FULL COLUMNS FROM `set` [ RunTime:0.000588s ]
  6. SELECT * FROM `set` [ RunTime:0.019321s ]
  7. SHOW FULL COLUMNS FROM `article` [ RunTime:0.000779s ]
  8. SELECT * FROM `article` WHERE `id` = 508462 LIMIT 1 [ RunTime:0.000662s ]
  9. UPDATE `article` SET `lasttime` = 1787337165 WHERE `id` = 508462 [ RunTime:0.001646s ]
  10. SELECT * FROM `fenlei` WHERE `id` = 67 LIMIT 1 [ RunTime:0.001296s ]
  11. SELECT * FROM `article` WHERE `id` < 508462 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.001741s ]
  12. SELECT * FROM `article` WHERE `id` > 508462 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.000471s ]
  13. SELECT * FROM `article` WHERE `id` < 508462 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.000718s ]
  14. SELECT * FROM `article` WHERE `id` < 508462 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.089759s ]
  15. SELECT * FROM `article` WHERE `id` < 508462 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.041870s ]
0.252092s