1.一文深入了解Linux内核源码pdflush机制
2.linux 内核 spinlock 的小睡实现
3.go源码：Sleep函数与线程
4.Netty源码解析 -- FastThreadLocal与HashedWheelTimer

一文深入了解Linux内核源码pdflush机制

       在进程安全监控中，遇到进程长时间处于不可中断的眠源码睡眠状态（D状态，超过8分钟），小睡可能导致系统崩溃。眠源码这种情况下，小睡涉及到Linux内核的眠源码借贷 源码pdflush机制，即如何将内存缓存中的小睡数据刷回磁盘。pdflush线程的眠源码数量可通过/proc/sys/vm/nr_pdflush_threads调整，范围为2到8个。小睡

       当内存不足或需要强制刷新时，眠源码脏页的小睡刷新会通过wakeup_pdflush函数触发，该函数调用background_writeout函数进行处理。眠源码background_writeout会监控脏页数量，小睡当超过脏数据临界值（脏背景比率，眠源码通过dirty_background_ratio调整）时，小睡会分批刷磁盘，直到比率下降。

       内核定时器也参与脏页刷新，启动wb_timer定时器，周期性地检查脏页并刷新。系统会在脏页存在超过dirty_expire_centisecs（可以通过/proc/sys/vm/dirty_expire_centisecs设置）后启动刷新。用户态的WRITE写文件操作也会触发脏页刷新，以平衡脏页比率，避免阻塞写操作。

       总结系统回写脏页的三种情况：定时器触发、内存不足时分批写、写操作触发pdflush。关键参数包括dirty_background_ratio、dirty_expire_centisecs、dirty_ratio和dirty_writeback_centisecs，它们分别控制脏数据比例、回写时间、openbsd 源码用户自定义回写和pdflush唤醒频率。

       在大数据项目中，写入量大时，应避免依赖系统缓存自动刷回，尤其是当缓存不足以满足写入速度时，可能导致写操作阻塞。在逻辑设计时，应谨慎使用系统缓存，对于对性能要求高的场景，建议自定义缓存，同时在应用层配合使用系统缓存以优化高楼贴等特定请求的性能。预读策略是提升顺序读性能的重要手段，Linux根据文件顺序性和流水线预读进行优化，预读大小通过快速扩张过程动态调整。

       最后，注意pread和pwrite在多线程io操作中的优势，以及文件描述符管理对性能的影响。在使用pread/pwrite时，即使每个线程有自己的文件描述符，它们最终仍作用于同一inode，不会额外提升IO性能。

linux 内核 spinlock 的实现

       在Linux内核中，共享对象的互斥处理常常面临复杂性问题，源于其内部并发机制的复杂性。这可能包括单核多进程（线程）间的伪并发，或是SMP架构下的真实并发。同时，还需考虑中断和下半部机制对并发的影响，使并发编程变得更为复杂。

       共享数据加锁是并发编程中基本的共识。Linux内核提供了多种锁机制，lodop源码以适应不同的并发情况。没有哪一种锁能适应所有场景，即使有，其适用性也会受到兼容性与针对性之间的权衡。

       在所有锁机制中，spin lock和mutex lock应用最为广泛。mutex lock在请求资源时若资源不可用，则进程会进入睡眠状态，直到资源重新开放。这种方式节省了CPU资源，适用于某些特定情况。然而，在某些场景下，mutex lock并不适用。一方面，从微观角度来看，虽然进程切换的开销通常很小，但如果确定进入临界区的时间小于进程切换的时间，且硬件发展使更多开销隐含在进程切换中，使用mutex lock的开销可能不再合理。另一方面，中断上下文中不能使用mutex lock，因此需要使用spinlock来实现共享对象的互斥访问。

       spinlock的核心思想是“旋转”，当进程无法获得spinlock保护的临界区访问权时，它会原地等待资源，同时不断地尝试查询是否能获得锁。spinlock的实现主要包括初始化、加锁和解锁三个过程，通过简单的编程接口完成。

       spinlock接口包括但不限于spin_lock_irq、tango 源码spin_unlock_irq、spin_lock_irqsave、spin_unlock_irqstore、spin_lock_bh、spin_unlock_bh等。这些接口允许在不同场景下灵活地使用spinlock，例如在中断上下文禁止中断、保存中断状态或在下半部中禁止下半部等。

       在分析spinlock之前，需要理解在使用过程中可能会遇到的并发情况。内核抢占、中断抢占、SMP架构下的并发执行以及下半部的抢占都是需要考虑的因素。对于自旋锁，内核抢占和中断都是明显的风险点，通常需要在使用自旋锁前禁止这些情况。中断服务程序和普通进程之间竞争同一锁时，需要在中断服务程序中禁止中断，而普通进程在使用spinlock时则不需要。在SMP架构下，需要考虑加解锁操作的原子性和独占性。

       一个完善的spinlock实现应该具备以下特点：在申请锁时关闭内核抢占，释放锁时开启内核抢占；如果出现中断或进程间的spinlock竞争，进程中的锁操作需要关闭中断；在中断下半部或进程中出现spinlock竞争时，需要关闭中断下半部；在多核系统下，加解锁的操作函数需要具备原子性或独占性。

       spinlock的源码实现通常涉及到单核与多核架构的区分，以及内核支持的死锁检测和调试功能。在arm SMP平台上，spinlock实现包含多层宏定义，以适应不同的rollviewpager源码需求。spinlock结构体spinlock_t负责管理加解锁操作，通过owner和next变量完成。初始化、加锁和释放锁的过程涉及到一系列的函数调用和宏定义，实现复杂的逻辑。

       spinlock在单核和多核系统中的实现方式有所不同，单核系统可以通过简单的变量来管理锁状态，而多核系统则需要更复杂的机制来处理并发和独占性问题。通过使用嵌入汇编程序，spinlock实现能够确保加解锁操作的原子性，从而防止并发执行中可能出现的问题。

       spinlock的使用涉及到多个并发情况的考虑，包括内核抢占、中断抢占、多核并发执行以及下半部的抢占。在设计和实现spinlock时，需要平衡兼容性与针对性，确保在不同场景下都能有效地实现资源的互斥访问。深入理解spinlock的实现原理和具体细节，对于优化并发代码的性能和避免死锁至关重要。

go源码：Sleep函数与线程

       在探索 Go 语言的并发编程中，Sleep 函数与线程的交互方式与 Java 或其他基于线程池的并发模型有所不同。本文将深入分析 Go 语言中 Sleep 函数的实现及其与线程的互动方式，以解答关于 Go 语言中 Sleep 函数与线程关系的问题。

       首先，重要的一点是，当一个 goroutine（g）调用 Sleep 函数时，它并不会导致当前线程被挂起。相反，Go 通过特殊的机制来处理这种情景，确保 Sleep 函数的调用不会影响到线程的执行。这一特性是 Go 语言并发模型中独特而关键的部分。

       具体来说，当一个 goroutine 调用 Sleep 函数时，它首先将自身信息保存到线程的关键结构体（p）中并挂起。这一过程涉及多个函数调用，包括 `time.Sleep`、`runtime.timeSleep`、`runtime.gopark`、`runtime.mcall`、`runtime.park_m`、`runtime.resetForSleep` 等。最终，该 goroutine 会被放入一个 timer 结构体中，并将其放入到 p 关联的一个最小堆中，从而实现了对当前 goroutine 的保存，同时为调度器提供了切换到其他 goroutine 或 timer 的机会。因此，这里的 timer 实际上代表了被 Sleep 挂起的 goroutine，它在睡眠到期后能够及时得到执行。

       接下来，我们深入分析 goroutine 的调度过程。当线程 p 需要执行时，它会通过 `runtime.park_m` 函数调用 `schedule` 函数来进行 goroutine 或 timer 的切换。在此过程中，`runtime.findrunnable` 函数会检查线程堆中是否存在已到期的 timer，如果存在，则切换到该 timer 进行执行。如果 timer 堆中没有已到期的 timer，线程会继续检查本地和全局的 goroutine 队列中是否还有待执行的 goroutine，如果队列为空，则线程会尝试“偷取”其他 goroutine 的任务。这一过程包括了检查 timer 堆、偷取其他 p 中的到期 timer 或者普通 goroutine，确保任务能够及时执行。

       在“偷取”任务的过程中，线程会优先处理即将到期的 timer，确保这些 timer 的准时执行。如果当前线程正在执行其他任务（如 epoll 网络），则在执行过程中会定期检查 timer 到期情况。如果发现其他线程的 timer 到期时间早于自身，会首先唤醒该线程以处理其 timer，确保不会错过任何到期的 timer。

       为了证明当前线程设置的 timer 能够准时执行，本文提出了两种证明方法。第一种方法基于代码细节，重点分析了线程状态的变化和 timer 的执行流程。具体而言，文章中提到的三种线程状态（正常运行、epoll 网络、睡眠）以及相应的 timer 执行情况，表明在 Go 语言中，timer 的执行策略能够确保其准时执行。第二种方法则从全局调度策略的角度出发，强调了 Go 语言中线程策略的设计原则，即至少有一个线程处于“spinning”状态或者所有线程都在执行任务，这保证了 timer 的准时执行。

       总之，Go 语言中 Sleep 函数与线程之间的交互方式，通过特殊的线程管理机制，确保了 goroutine 的 Sleep 操作不会阻塞线程，同时保证了 timer 的准时执行。这一机制是 Go 语言并发模型的独特之处，为开发者提供了一种高效且灵活的并发处理方式。

Netty源码解析 -- FastThreadLocal与HashedWheelTimer

       Netty源码分析系列文章接近尾声，本文深入解析FastThreadLocal与HashedWheelTimer。基于Netty 4.1.版本。

       FastThreadLocal简介：

       FastThreadLocal与FastThreadLocalThread协同工作。FastThreadLocalThread继承自Thread类，内部封装一个InternalThreadLocalMap，该map只能用于当前线程，存放了所有FastThreadLocal对应的值。每个FastThreadLocal拥有一个index，用于定位InternalThreadLocalMap中的值。获取值时，首先检查当前线程是否为FastThreadLocalThread，如果不是，则从UnpaddedInternalThreadLocalMap.slowThreadLocalMap获取InternalThreadLocalMap，这实际上回退到使用ThreadLocal。

       FastThreadLocal获取值步骤：

       #1 获取当前线程的InternalThreadLocalMap，如果是FastThreadLocalThread则直接获取，否则通过UnpaddedInternalThreadLocalMap.slowThreadLocalMap获取。

       #2 通过每个FastThreadLocal的index，获取InternalThreadLocalMap中的值。

       #3 若找不到值，则调用initialize方法构建新对象。

       FastThreadLocal特点：

       FastThreadLocal无需使用hash算法，通过下标直接获取值，复杂度为log(1)，性能非常高效。

       HashedWheelTimer介绍：

       HashedWheelTimer是Netty提供的时间轮调度器，用于高效管理各种延时任务。时间轮是一种批量化任务调度模型，能够充分利用线程资源。简单说，就是将任务按照时间间隔存放在环形队列中，执行线程定时执行队列中的任务。

       例如，环形队列有个格子，执行线程每秒移动一个格子，则每轮可存放1分钟内的任务。任务执行逻辑如下：给定两个任务task1（秒后执行）、task2（2分秒后执行），当前执行线程位于第6格子。那么，task1将放到+6=格，轮数为0；task2放到+6=格，轮数为2。执行线程将执行当前格子轮数为0的任务，并将其他任务轮数减1。

       HashedWheelTimer的缺点：

       时间轮调度器的时间精度受限于执行线程的移动速度。例如，每秒移动一个格子，则调度精度小于一秒的任务无法准时调用。

       HashedWheelTimer关键字段：

       添加延迟任务时，使用HashedWheelTimer#newTimeout方法，如果HashedWheelTimer未启动，则启动HashedWheelTimer。启动后，构建HashedWheelTimeout并添加到timeouts集合。

       HashedWheelTimer运行流程：

       启动后阻塞HashedWheelTimer线程，直到Worker线程启动完成。计算下一格子开始执行的时间，然后睡眠到下次格子开始执行时间。获取tick对应的格子索引，处理已到期任务，移动到下一个格子。当HashedWheelTimer停止时，取消任务并停止时间轮。

       HashedWheelTimer性能比较：

       HashedWheelTimer新增任务复杂度为O(1)，优于使用堆维护任务的ScheduledExecutorService，适合处理大量任务。然而，当任务较少或无任务时，HashedWheelTimer的执行线程需要不断移动，造成性能消耗。另外，使用同一个线程调用和执行任务，某些任务执行时间过久会影响后续任务执行。为避免这种情况，可在任务中使用额外线程执行逻辑。如果任务过多，可能导致任务长期滞留在timeouts中而不能及时执行。

       本文深入剖析FastThreadLocal与HashedWheelTimer的实现细节，旨在提供全面的技术洞察与实战经验。希望对您理解Netty源码与时间轮调度器有帮助。关注微信公众号，获取更多Netty源码解析与技术分享。