在业务开发的场景中，我们经常会遇到很多定时任务的需求。比如，生成业务报表，周期性对账，同步数据，订单支付超时处理等。针对业务场景中定时任务逻辑复杂，执行时间长的特点，市面上已经有很多成熟的任务调度中间件可供我们选择。比如：ElasticJob , XXL-JOB , Po...

本文是 Netty 内存管理系列的最后一篇文章，在第一篇文章 《聊一聊 Netty 数据搬运工 ByteBuf 体系的设计与实现》 中，笔者以 UnpooledByteBuf 为例，从整个内存管理的外围对 ByteBuf 的整个设计体系进行了详细的拆解剖析，随后在第二篇文章 《谈一谈 Netty 的内存管...

在之前的 Netty 系列中，笔者是以 4.1.56.Final 版本为基础和大家讨论的，那么从本文开始，笔者将用最新版本 4.1.112.Final 对 Netty 的相关设计展开解析，之所以这么做的原因是 Netty 的内存池设计一直在不断地演进优化。

在上篇文章《聊一聊 Netty 数据搬运工 ByteBuf 体系的设计与实现》 中，笔者详细地为大家介绍了 ByteBuf 整个体系的设计，其中笔者觉得 Netty 对于引用计数的设计非常精彩，因此将这部分设计内容专门独立出来。

时光芿苒，岁月如梭，好久没有给大家更新 Netty 相关的文章了，在断更 Netty 的这段日子里，笔者一直在持续更新 Linux 内存管理相关的文章 ，目前为止，算是将 Linux 内存管理子系统相关的主干源码较为完整的给大家呈现了出来，同时也结识了很多喜欢内核的读者，经常...

PhantomReference 和 WeakReference 如果仅仅从概念上来说其实很难区别出他们之间究竟有何不同，比如， PhantomReference 是用来跟踪对象是否被垃圾回收的，如果对象被 GC ，那么其对应的 PhantomReference 就会被加入到一个 ReferenceQueue 中，这个 ReferenceQueue...

FinalReference 对于我们来说是一种比较陌生的 Reference 类型，因为我们好像在各大中间件以及 JDK 中并没有见过它的应用场景，事实上，FinalReference 被设计出来的目的也不是给我们用的，而是给 JVM 用的，它和 Java 对象的 finalize() 方法执行机制有关。

大家在网上或者在其他讲解 JVM 的书籍中多多少少会看到这样一段关于 SoftReference 的描述 —— “当 SoftReference 所引用的 referent 对象在整个堆中没有其他强引用的时候，发生 GC 的时候，如果此时内存充足，那么这个 referent 对象就和其他强引用一样，不会被 GC ...

Reference（引用）是 JVM 中非常核心且重要的一个概念，垃圾回收器判断一个对象存活与否都是围绕着这个 Reference 来的，JVM 将 Reference 又细分为几种具体的引用类型，它们分别是：StrongReference，SoftReference，WeakReference，PhantomReference，FinalReferen...

在 JDK NIO 针对堆外内存的分配场景中，我们经常会看到 System.gc 的身影，比如当我们通过 FileChannel#map 对文件进行内存映射的时候，如果 JVM 进程虚拟内存空间中的虚拟内存不足，JVM 在 native 层就会抛出 OutOfMemoryError 。

自上篇文章《从 Linux 内核角度探秘 JDK MappedByteBuffer》 发布之后，很多读者朋友私信我说，文章的信息量太大了，其中很多章节介绍的内容都是大家非常想要了解，并且是频繁被搜索的内容，所以根据读者朋友的建议，笔者决定将一些重要的章节内容独立出来，更好的方...

在之前的文章《一步一图带你深入剖析 JDK NIO ByteBuffer 在不同字节序下的设计与实现》 中，笔者为大家详细剖析了 JDK Buffer 的整个设计体系，从总体上来讲，JDK NIO 为每一种 Java 基本类型定义了对应的 Buffer 类（boolean 类型除外）。

在前面两篇介绍 mmap 的文章中，笔者分别从原理角度以及源码实现角度带着大家深入到内核世界深度揭秘了 mmap 内存映射的本质。从整个 mmap 映射的过程可以看出，内核只是在进程的虚拟地址空间中寻找出一段空闲的虚拟内存区域 vma 然后分配给本次映射而已。

通过上篇文章 《从内核世界透视 mmap 内存映射的本质（原理篇）》的介绍，我们现在已经非常清楚了 mmap 背后的映射原理以及它的使用方法，其核心就是在进程虚拟内存空间中分配一段虚拟内存出来，然后将这段虚拟内存与磁盘文件映射起来，整个 mmap 系统调用就结束了。

之前有不少读者给笔者留言，希望笔者写一篇文章介绍下 mmap 内存映射相关的知识体系，之所以迟迟没有动笔，是因为 mmap 这个系统调用看上去简单，实际上并不简单，可以说是非常复杂的一个系统调用。

笔者之前在自己的专栏《聊聊 Linux 内核》 里通过大量的篇幅写了一个系列关于内存管理相关的文章，在这个系列文章中，笔者分别通过虚拟内存管理和物理内存管理两个角度算是把 Linux 内存管理子系统的全貌给大家呈现了出来。

本文是笔者 slab 系列的最后一篇文章，为了方便大家快速检索，先将相关的文章列举出来：《细节拉满，80 张图带你一步一步推演 slab 内存池的设计与实现》《从内核源码看 slab 内存池的创建初始化流程》《深入理解 slab cache 内存分配全链路实现》《深度解析 slab 内...

在上篇文章 《深入理解 slab cache 内存分配全链路实现》 中，笔者详细地为大家介绍了 slab cache 进行内存分配的整个链路实现，本文我们就来到了 slab cache 最后的一部分内容了，当申请的内存使用完毕之后，下面就该释放内存了。

本文笔者将带大家继续从内核源码的角度继续拆解 slab cache 的实现细节，接下来笔者会基于上面这幅 slab cache 完整架构图，详细介绍一下 slab cache 是如何进行内存分配的。

在上篇文章[《细节拉满，80 张图带你一步一步推演 slab 内存池的设计与实现》]([链接])中，笔者从 slab cache 的总体架构演进角度以及 slab cache 的运行原理角度为大家勾勒出了 slab cache 的总体架构视图，基于这个视图详细阐述了 slab cache 的内存分配以及释放原...