1.Spring Boot引起的源码“堆外内存泄漏”排查及经验总结
2.fs/dev/zero的实现
3.RocksDb 源码剖析 (1) | 如何混合 new 、mmap 设计高效内存分配器 arena ?源码
4.mmap的系统调用
5.C++/C 内存分配-malloc/mmap/syscall深度解析以及性能测试
6.Linux内核黑科技——mmap实现详解

Spring Boot引起的“堆外内存泄漏”排查及经验总结

       为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），源码随后我们就发现系统会频繁报出Swap区域使用量过高的源码异常。笔者被叫去帮忙查看原因，源码发现配置了4G堆内内存，源码方舟生存进化工具源码在哪但是源码实际使用的物理内存竟然高达7G，确实不正常。源码JVM参数配置是源码“-XX:MetaspaceSize=M -XX:MaxMetaspaceSize=M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=m -XX:InitialCodeCacheSize=m, -Xssk -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”，实际使用的源码物理内存如下图所示：

       使用Java层面的工具定位内存区域（堆内内存、Code区域或者使用unsafe.allocateMemory和DirectByteBuffer申请的源码堆外内存）。

       笔者在项目中添加-XX:NativeMemoryTracking=detailJVM参数重启项目，源码使用命令jcmd pid VM.native_memory detail查看到的源码内存分布如下：

       发现命令显示的committed的内存小于物理内存，因为jcmd命令显示的源码内存包含堆内内存、Code区域、源码通过unsafe.allocateMemory和DirectByteBuffer申请的内存，但是不包含其他Native Code（C代码）申请的堆外内存。所以猜测是使用Native Code申请内存所导致的问题。

       为了防止误判，笔者使用了pmap查看内存分布，发现大量的M的地址；而这些地址空间不在jcmd命令所给出的地址空间里面，基本上就断定就是这些M的内存所导致。

       使用系统层面的工具定位堆外内存。

       因为已经基本上确定是Native Code所引起，而Java层面的工具不便于排查此类问题，只能使用系统层面的工具去定位问题。

       首先，使用了gperftools去定位问题。

       从上图可以看出：使用malloc申请的的内存最高到3G之后就释放了，之后始终维持在M-M。笔者第一反应是：难道Native Code中没有使用malloc申请，直接使用mmap/brk申请的？（gperftools原理就使用动态链接的方式替换了操作系统默认的内存分配器（glibc）。）

       然后，使用strace去追踪系统调用。

       因为使用gperftools没有追踪到这些内存，于是直接使用命令“strace -f -e"brk,mmap,munmap" -p pid”追踪向OS申请内存请求，但是并没有发现有可疑内存申请。

       接着，使用GDB去dump可疑内存。

       因为使用strace没有追踪到可疑内存申请；于是想着看看内存中的情况。就是直接使用命令gdp -pid pid进入GDB之后，然后使用命令dump memory mem.bin startAddress endAddressdump内存，其中startAddress和endAddress可以从/proc/pid/smaps中查找。然后使用strings mem.bin查看dump的内容，如下：

       从内容上来看，像是解压后的JAR包信息。读取JAR包信息应该是在项目启动的时候，那么在项目启动之后使用strace作用就不是很大了。所以应该在项目启动的时候使用strace，而不是启动完成之后。

       再次，项目启动时使用strace去追踪系统调用。

       项目启动使用strace追踪系统调用，发现确实申请了很多M的内存空间，截图如下：

       使用该mmap申请的地址空间在pmap对应如下：

       最后，使用jstack去查看对应的线程。

       因为strace命令中已经显示申请内存的源码转为真值线程ID。直接使用命令jstack pid去查看线程栈，找到对应的线程栈（注意进制和进制转换）如下：

       这里基本上就可以看出问题来了：MCC（美团统一配置中心）使用了Reflections进行扫包，底层使用了Spring Boot去加载JAR。因为解压JAR使用Inflater类，需要用到堆外内存，然后使用Btrace去追踪这个类，栈如下：

       然后查看使用MCC的地方，发现没有配置扫包路径，默认是扫描所有的包。于是修改代码，配置扫包路径，发布上线后内存问题解决。

       为什么堆外内存没有释放掉呢？

       虽然问题已经解决了，但是有几个疑问。带着疑问，直接看了一下 Spring Boot Loader那一块的源码。发现Spring Boot对Java JDK的InflaterInputStream进行了包装并且使用了Inflater，而Inflater本身用于解压JAR包的需要用到堆外内存。而包装之后的类ZipInflaterInputStream没有释放Inflater持有的堆外内存。于是以为找到了原因，立马向Spring Boot社区反馈了这个bug。但是反馈之后，就发现Inflater这个对象本身实现了finalize方法，在这个方法中有调用释放堆外内存的逻辑。也就是说Spring Boot依赖于GC释放堆外内存。

       使用jmap查看堆内对象时，发现已经基本上没有Inflater这个对象了。于是就怀疑GC的时候，没有调用finalize。带着这样的怀疑，把Inflater进行包装在Spring Boot Loader里面替换成自己包装的Inflater，在finalize进行打点监控，结果finalize方法确实被调用了。于是又去看了Inflater对应的C代码，发现初始化的使用了malloc申请内存，end的时候也调用了free去释放内存。

       此时，怀疑free的时候没有真正释放内存，便把Spring Boot包装的InflaterInputStream替换成Java JDK自带的，发现替换之后，内存问题也得以解决了。

       再次看gperftools的内存分布情况，发现使用Spring Boot时，内存使用一直在增加，突然某个点内存使用下降了好多（使用量直接由3G降为M左右）。这个点应该就是GC引起的，内存应该释放了，但是在操作系统层面并没有看到内存变化，那是不是没有释放到操作系统，被内存分配器持有了呢？

       继续探究，发现系统默认的内存分配器（glibc 2.版本）和使用gperftools内存地址分布差别很明显，2.5G地址使用smaps发现它是属于Native Stack。内存地址分布如下：

       到此，基本上可以确定是内存分配器在捣鬼；搜索了一下glibc M，发现glibc从2.开始对每个线程引入内存池（位机器大小就是M内存），原文如下：

       按照文中所说去修改MALLOC_ARENA_MAX环境变量，网约源码发现没什么效果。查看tcmalloc（gperftools使用的内存分配器）也使用了内存池方式。

       为了验证是内存池搞的鬼，就简单写个不带内存池的内存分配器。使用命令gcc zjbmalloc.c -fPIC -shared -o zjbmalloc.so生成动态库，然后使用export LD_PRELOAD=zjbmalloc.so替换掉glibc的内存分配器。其中代码Demo如下：

       通过在自定义分配器当中埋点可以发现实际申请的堆外内存始终在M-M之间，gperftools监控显示内存使用量也是在M-M左右。但是从操作系统角度来看进程占用的内存差别很大（这里只是监控堆外内存）。

       使用不同分配器进行不同程度的扫包，占用的内存如下：

       为什么自定义的malloc申请M，最终占用的物理内存在1.7G呢？因为自定义内存分配器采用的是mmap分配内存，mmap分配内存按需向上取整到整数个页，所以存在着巨大的空间浪费。通过监控发现最终申请的页面数目在k个左右，那实际上向系统申请的内存等于k * 4k（pagesize） = 2G。

       为什么这个数据大于1.7G呢？因为操作系统采取的是延迟分配的方式，通过mmap向系统申请内存的时候，系统仅仅返回内存地址并没有分配真实的物理内存。只有在真正使用的时候，系统产生一个缺页中断，然后再分配实际的物理Page。

       整个内存分配的流程如上图所示。MCC扫包的默认配置是扫描所有的JAR包。在扫描包的时候，Spring Boot不会主动去释放堆外内存，导致在扫描阶段，堆外内存占用量一直持续飙升。当发生GC的时候，Spring Boot依赖于finalize机制去释放了堆外内存；但是glibc为了性能考虑，并没有真正把内存归返到操作系统，而是留下来放入内存池了，导致应用层以为发生了“内存泄漏”。所以修改MCC的配置路径为特定的JAR包，问题解决。在发表这篇文章时，发现Spring Boot的最新版本（2.0.5.RELEASE）已经做了修改，在ZipInflaterInputStream主动释放了堆外内存不再依赖GC；所以Spring Boot升级到最新版本，这个问题也可以得到解决。

fs/dev/zero的实现

       在类UNIX操作系统中，/dev/zero是一个特殊文件，提供无限空字符流。常用于覆盖信息或生成特定大小空白文件。其实现依赖于mmap将/dev/zero映射至虚地址空间，实现共享内存。该操作等同于匿名内存使用，即没有与任何文件关联。系统分配内容（通过mmap或brk）通常清零，但虚拟地址按需分配物理页面。读取操作仅需保证零内容，虚拟地址映射至内容为0的物理页面，降低系统物理内存消耗。

       在Linux中，万物皆是文件，/dev/zero的实现涉及特定目录下的tmpfs文件系统。通过shmem_zero_setup、电子病毒 源码shmem_kernel_file_setup和alloc_file等步骤构建。

       mmap共享匿名映射实质上是文件映射，特殊文件位于/dev/zero目录，创建于tmpfs系统中。

       相关文献深入剖析了mmap原理、共享内存虚拟文件系统、mmap内存映射本质及其源码实现。

       进一步理解Linux内核共享内存机制，包括shmem和tmpfs，提供深入分析。

RocksDb 源码剖析 (1) | 如何混合 new 、mmap 设计高效内存分配器 arena ?

       本文旨在深入剖析RocksDb源码，从内存分配器角度着手。RocksDb内包含MemoryAllocator和Allocator两大类内存分配器。MemoryAllocator作为基类，提供MemkindKmemAllocator和JemallocNodumpAllocator两个子类，分别集成memkind和jemalloc库的功能，实现内存分配与释放。

       接着，重点解析Allocator类及其子类Arena的实现。基类Allocator提供两个关键接口：内存分配与对齐。Arena类采用block为单位进行内存分配，先分配一个block大小的内存，后续满足需求时，优先从block中划取，以减少内存浪费。一个block的大小由kBlockSize参数决定。分配策略中，Arena通过两个指针（aligned_alloc_ptr_和unaligned_alloc_ptr_）分别管理对齐与非对齐内存，提高内存利用效率。

       分配内存时，Arena通过构造函数初始化成员变量，包括block大小、内存在栈上的分配与mmap机制的使用。构造函数内使用OptimizeBlockSize函数确保block大小合理，减少内存对齐浪费。Arena中的内存管理逻辑清晰，尤其在分配新block时，仅使用new操作，无需额外内存对齐处理。

       分配内存流程中，AllocateNewBlock函数直接调用new分配内存，而AllocateFromHugePage和AllocateFallback函数则涉及mmap机制的使用与内存分配策略的统一。这些函数共同构成了Arena内存管理的核心逻辑，实现了灵活高效地内存分配。

       此外，Arena还提供AllocateAligned函数，针对特定对齐需求分配内存。这一函数在使用mmap分配内存时，允许用户自定义对齐大小，优化内存使用效率。在处理对齐逻辑时，Arena巧妙地利用位运算优化计算过程，提高了代码效率。

       总结而言，RocksDb的病毒源码网内存管理机制通过Arena类实现了高效、灵活的内存分配与管理。通过深入解析其源码，可以深入了解内存对齐、内存分配与多线程安全性的实现细节，为开发者提供宝贵的内存管理实践指导。未来，将深入探讨多线程内存分配器的设计，敬请期待后续更新。

mmap的系统调用

       1. 创建内存映射

       mmap：进程创建匿名的内存映射，把内存的物理页映射到进程的虚拟地址空间。进程把文件映射到进程的虚拟地址空间，可以像访问内存一样访问文件，不需要调用系统调用read()/write()访问文件，从而避免用户模式和内核模式之间的切换，提高读写文件速度。两个进程针对同一个文件创建共享的内存映射，实现共享内存。

       mumap：该调用在进程地址空间中解除一个映射关系，addr是调用mmap()时返回的地址，len是映射区的大小。当映射关系解除后，对原来映射地址的访问将导致段错误发生。

       3. 设置虚拟内存区域的访问权限

       mprotect：把自start开始的、长度为len的内存区的保护属性修改为prot指定的值。 prot可以取以下几个值，并且可以用“|”将几个属性合起来使用： 1）PROT_READ：表示内存段内的内容可写； 2）PROT_WRITE：表示内存段内的内容可读； 3）PROT_EXEC：表示内存段中的内容可执行； 4）PROT_NONE：表示内存段中的内容根本没法访问。 需要指出的是，指定的内存区间必须包含整个内存页（4K）。区间开始的地址start必须是一个内存页的起始地址，并且区间长度len必须是页大小的整数倍。

       0. 查找mmap在内核中的系统调用函数 我现在用的内核版是4..，首先在应用层参考上面解析编写一个mmap使用代码，然后编译成程序，在使用strace工具跟踪其函数调用，可以发现mmap也是调用底层的mmap系统调用，然后我们寻找一下底层的带6个参数的mmap系统调用有哪些：

       1.mmap的系统调用 x的位于arch/x/kernel/sys_x_.c文件，如下所示：

       arm的位于arch/arm/kernel/sys.c文件，如下所示：

       然后都是进入ksys_mmap_pgoff：

       然后进入vm_mmap_pgoff：

       我们讲解最重要的do_mmap_pgoff函数：

       然后进入do_mmap：

       do_mmap_pgoff这个函数主要做了两件事，get_unmapped_area获取未映射地址，mmap_region映射。 先看下get_unmapped_area ，他是先找到mm_struct的get_unmapped_area成员，再去执行他：

       再看mmap_region的实现：

       现在，我们看看匿名映射的函数shmem_zero_setup到底做了什么，其实匿名页实际也映射了文件，只是映射到了/dev/zero上，这样有个好处是，不需要对所有页面进行提前置0，只有当访问到某具体页面的时候才会申请一个0页。

       其实说白了，mmap就是在进程mm中创建或者扩展一个vma映射到某个文件，而共享、私有、文件、匿名这些mmap所具有的属性是在哪里体现的呢？上面的源码在不断的设置一些标记位，这些标记位就决定了进程在访问这些内存时内核的行为，mmap仅负责创建一个映射而已。

C++/C 内存分配-malloc/mmap/syscall深度解析以及性能测试

       用于实现动态内存分配函数（如malloc、free等）以及操作系统级的内存管理。

       通常情况下，malloc和free会使用brk或sbrk来动态管理进程的堆空间。它们会请求增加或减少堆空间的大小，以满足动态内存分配的需求。

       在理解brk和sbrk时，需要考虑以下几点：

       上面这些都是理论知识，和实际还有不小的差距，大家不要直接记这些理论，一定要动手自己实践，看到什么样的结果，就是什么样，看不到的就后面有机会再补充。

       (文章内涉及的源码截图或者片段，若您需要源码工程，可以关注后留言找我要。 )

       首先在大多数系统中，栈是有固定大小的，当程序启动时系统会为栈分配一块固定大小的内存空间。栈的大小受限于系统的限制，当栈空间用尽时会引发栈溢出（stack overflow）错误。所以栈不存动态增长的可能，所以我们暂时只分析堆的内存分配。

       注意这个KB，说的是每次沈内存的时候判断，不是说累计情况，比如你每次申请1KB，申请了多次，那肯定超了，此时还是会继续使用brk分配，并不会使用mmap。 只有你一次性申请超过KB是才会调用mmap

       场景：申请5次内存，前3次申请小内存，后面2次申请超过KB，看看linux系统分配的内存是怎样的？

       代码路径：\usr\cbasics_demo\1_malloc_Demo\4_malloc_demo.cpp

       sbrk(0)会返回当前brk指针的位置。具体来说，它返回当前数据段的结束地址，也就是堆的顶端。当你调用sbrk(0)时，它实际上并不会改变brk指针的位置，只是返回当前brk指针的值。

       可以看到上面的ptr1到ptr3内存地址很接近，说明是连续的，因为我写的代码申请的都是小内存，只有几个字母。

       而从ptr4开始，内存地址完全变了，你可以理解pt3的分布还在秦皇岛，而pt4和pt5直接给你放北京了。

       他们的区别就在于大小，pt4和pt5是超过KB的，由此可以证明这块的内存分配肯定是不同的。

       而继续看Current brk的打印，这里打印的是当前进程内的内存地址：0xc 这很明显和pt1,pt2,pt3 都是在一块区域的，我觉得这足以证明 这三个是用的brk进行分配，而pt4和5没有用brk，因为brk的最新指针地址没有包含他俩。他俩的地址，早就超出了brk的指针范围。

       继续看释放哪里的打印，我分别释放了pt1一直到pt5，但是brk的指针地址，一点没变，还是0xc 说明，在底层free函数，不会立即释放内存，brk指针地址并没有改变。 下次申请内存时肯定会重复使用，所以它的性能比较高。

       我基于这个demo画了个内存图，方便理解：

       malloc函数，会调用brk和mmap（也就相当于syscall），所以性能测试只需触发malloc的小块内存和大块内存分配即可。测试场景如下：

       （1）暴力基础测试，不考虑场景，直接测试申请内存效率

       （2）触发malloc函数，持续申请小块内存，比如一个list集合或者数组数据，每个内容很小，但是加在一起很大，这时候我们是直接申请一大块内存，还是递增的申请小块内存呢？

       （3）触发malloc函数的，大块内存申请，就是内存映射mmap，如果我创建的对象每个都很大，比如里面存储的是业务数据，一个对象就几百兆，那我是直接申请一大块内存做内存映射？还是将该对象拆分掉小块，去申请一堆小块内存呢？

       使用malloc申请1万次小块内存，每个内存只有sizeof(char)大小。再使用mmap申请1万次内存，每次申请

*

       小块内存：0. 秒 大块内存：0. 秒 相差了了倍。

       修改限制，不在使用次数，而是固定大小，申请小块内存最大只申请MB，但是需要申请很多次，因为每次只是申请*sizeof(char)。

       而大块内存每次申请：2** 但是最大申请MB。

       结果：

       小块：0. 秒 大块：0.秒 相差了倍

       总结：从上面的实验得知，申请大块内存和申请小块内存在性能上并没有太大的区别，根本原因是申请次数，你申请大块内存是为了减少申请次数，并不是申请大块内存就快。同样的小块内存申请也一样，你申请的小，也不能频繁的申请，比如第二个场景，为了MB的空间，小块内存申请了万次，结果性能比申请大块内存相差了倍。

       重点是：频率

       对于内存分配的性能，通常需要考虑以下几个方面：

       尝试分析小块内存申请情况

       代码如下：

       运行结果如下：

       第一次打印的结果：

       第二次打印的结果：

       根据这些数据，我们可以初步分析内存碎片的情况：

       malloc和free是C语言库函数，而在C++中常用的是new和delete，

       C里面是用malloc_stats();

       而C++则需要用/proc/self/smaps文件来查看进程的内存映射情况 ,但是大块内存无法用这个查看，比如mmap分配的。需要其他内存分析工具

       A：他们直接的区别

       new和delete是C++中的运算符，而malloc和free是C语言中的函数。它们之间有几个重要的区别：

       总的来说，new和delete更适合在C++中使用，因为它们提供了更好的类型安全性、异常处理和对象构造/析构的支持。而在C语言中，或者需要与C代码进行交互时，可以使用malloc和free。

       B：单纯性能的对比

       从性能和原理的角度来看，new和delete与malloc和free之间也存在一些区别：

       总的来说，从性能和原理的角度来看，new和delete在处理类对象和支持面向对象编程方面更加方便和安全，而malloc和free则更适合于处理简单的内存分配和释放操作。

       然而在C++中，operator new通常会调用malloc来分配内存，但它并不是直接调用malloc函数。相反，C++标准库会提供operator new的重载版本，以便用户可以自定义内存分配行为。这意味着operator new可以使用不同的内存分配策略，而不仅仅是调用malloc。

       因此，尽管new操作符在底层可能会使用operator new来执行内存分配，而operator new可能会使用malloc来分配内存，但new操作符并不会直接调用malloc函数。这种分层的设计使得C++的内存分配更加灵活，并且允许用户自定义内存分配策略。

       最后这个总结我没法证明，毕竟还没看new的源码，现在查询到的资料看底层最终还是会到c的malloc函数上。

       编译：g++ -o 5_2_pmTest_malloc_demo.o 5_2_pmTest_malloc_demo.cpp -lrt

       运行： ./5_2_pmTest_malloc_demo.o

       运行结果：可以看到C++并没有多太多。

       C malloc and free time: 0. seconds

       C++ new and delete time: 0. seconds

Linux内核黑科技——mmap实现详解

       本文旨在详细阐述 Linux 内核中的 mmap 实现机制。mmap 的全称是 memory map，即内存映射，其功能是将文件内容映射到内存中，允许我们直接对映射的内存区域进行读写操作，效果等同于直接对文件进行读写。

       mmap 实现分为两个关键步骤：文件映射和缺页异常处理。首先，使用 mmap() 系统调用时，内核会通过 do_mmap_pgoff() 函数进行处理，这一过程主要是为进程分配虚拟内存空间，并初始化相关数据结构。文件映射则通过 mmmap_region() 函数完成，该函数负责在 vm_area_struct 结构中登记文件信息，以便后续的内存访问操作。

       在文件映射阶段，虚拟内存地址会映射到文件的页缓存中。当进程试图访问映射后的虚拟内存地址时，若该地址对应的内容未被加载到物理内存中，则会导致缺页异常。这就是我们接下来要介绍的第二步：缺页异常处理。

       当 CPU 触发缺页异常时，内核会调用 do_page_fault() 函数来处理这一异常情况。在这一过程中，文件的页缓存内容会被加载到物理内存中，与虚拟内存地址建立起映射关系。这一机制确保了当进程访问文件内容时，可以无缝地在物理内存和文件之间进行数据交换，从而实现高效的文件读写操作。

       综上所述，mmap 通过将文件内容映射到虚拟内存中，允许我们直接对映射区域进行读写操作，而背后的关键在于文件的页缓存与虚拟内存地址之间的动态映射。这一机制是 Linux 内核实现高效文件访问和管理的重要技术之一。

       对于需要深入学习 Linux 内核源码、内存调优、文件系统、进程管理、设备驱动、网络协议栈等领域的开发者，推荐加入 Linux 内核源码交流群：，群内提供丰富的学习资源，包括精选书籍、视频资料等，以及价值的内核资料包，包含视频教程、电子书、实战项目及代码。前名加入者还将获得额外赠送的资料。

       此外，我们整理了以下精选文章，供对 Linux 内核感兴趣的读者参考：

       浅谈 ARM Linux 内核页表的块映射

       内核大神教你从 Linux 进程的角度看 Docker

       Linux 下 CAN 总线是如何使用的？

       谈谈 Linux 内存管理的前世今生

       深入分析 Linux socket 数据发送过程

       盘点那些 Linux 内核调试手段——内核打印

       Linux 环境下网络分析和抓包是怎么操作的？

java mmap

       java mmap是什么，让我们一起了解一下？

        mmap是将一个文件或者其它对象映射进内存，文件被映射到多个页上，如果文件的大小不是所有页的大小之和，最后一个页不被使用的空间将会清零。mmap在用户空间映射调用系统中作用很大。

        目前Java提供的mmap只有内存文件映射，其他IO操作还没有内存映射功能。

        Java内存映射文件（Memory Mapped Files）就已经在java.nio包中，但它对很多程序开发者来说仍然是一个相当新的概念。引入NIO后，Java IO已经相当快，而且内存映射文件提供了Java有可能达到的最快IO操作，这也是为什么那些高性能Java应用应该使用内存映射文件来持久化数据。

       mmap在Java中的用途是什么？

        1、对普通文件使用mmap提供内存映射I/O，以避免系统调用(read、write、lseek)带来的性能开销。同时减少了数据在内核缓冲区和进程地址空间的拷贝次数。

       2、使用特殊文件提供匿名内存映射。

        3、使用shm_open以提供无亲缘关系进程间的Posix共享内存区。

        mmap在Java中是如何使用的？（具体参考kafka源码中的OffsetIndex这个类）

       æ“ä½œæ–‡ä»¶ï¼Œå°±ç›¸å½“于操作一个ByteBuffer一样。 public class TestMmap { undefined public static String path = "C:\\Users\\\\Desktop\\mmap"; public static void main(String[] args) throws IOException { undefined File file1 = new File(path, "1"); RandomAccessFile randomAccessFile = new RandomAccessFile(file1, "rw"); int len = ; // æ˜ å°„为2kb，那么生成的文件也是2kb MappedByteBuffer mmap = randomAccessFile.getChannel().map(FileChannel.MapMode.READ_WRITE, 0, len); System.out.println(mmap.isReadOnly()); System.out.println(mmap.position()); System.out.println(mmap.limit()); // å†™æ•°æ®ä¹‹åŽï¼ŒJVM é€€å‡ºä¹‹åŽä¼šå¼ºåˆ¶åˆ·æ–°çš„ mmap.put("a".getBytes()); mmap.put("b".getBytes()); mmap.put("c".getBytes()); mmap.put("d".getBytes()); // System.out.println(mmap.position()); // System.out.println(mmap.limit()); // // mmap.force(); // å‚考OffsetIndex强制回收已经分配的mmap，不必等到下次GC， unmap(mmap); // åœ¨Windows上需要执行unmap(mmap); å¦åˆ™æŠ¥é”™ // Windows won't let us modify the file length while the file is mmapped // java.io.IOException: è¯·æ±‚的操作无法在使用用户映射区域打开的文件上执行 randomAccessFile.setLength(len/2); mmap = randomAccessFile.getChannel().map(FileChannel.MapMode.READ_WRITE, 0, len/2); // A mapping, once established, is not dependent upon the file channel // that was used to create it. Closing the channel, in particular, has no // effect upon the validity of the mapping. randomAccessFile.close(); mmap.put(, "z".getBytes()[0]); } // copy from FileChannelImpl#unmap(私有方法) private static void unmap(MappedByteBuffer bb) { undefined Cleaner cl = ((DirectBuffer)bb).cleaner(); if (cl != null) cl.clean(); } }

记一次源码追踪分析，从Java到JNI，再到JVM的C++：fileChannel.map()为什么快；源码分析map方法，put方法

       前言

       在系统IO相关的系统调用有read/write，mmap，sendfile等这些。

       其中read/write是普通的读写，每次都需要将buffer从用户空间拷贝到内核空间；

       而mmap使用的是内存映射，会将磁盘文件对应的页映射（拷贝）到内核空间的page cache，并记录到用户进程的页表中，使得用户空间也可以像操作用户空间一样操作该文件的映射，最后再由操作系统来讲该映射（脏页）回写到磁盘；

       sendfile则使用的是零拷贝技术，在mmap的基础上，当发送数据的时候只拷贝fd和offset等元数据信息，而将数据主体直接拷贝至protocol buffer，实现了内核数据零冗余的零拷贝技术

       本文地址：/post//

问题/目的问题1Java中哪些API使用到了mmap问题2怎么知道该API使用到了mmap，如何追踪程序的系统调用目的1源码中分析验证，从Java到JNI，再到C++：fileChannel.map()使用的是系统调用mmap目的2源码验证分析：调用mmapedByteBuffer.put(Byte[])时JVM在搞些什么？mmap比普通的read/write快在哪？揭晓答案1mmap在Java NIO中的体现/使用

       看一个例子

// 1GBpublic static final int _GB = 1**;File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer mmapedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB);for (int i = 0; i < _GB; i++) { count++;mmapedByteBuffer.put((byte)0);}

       其中fileChannel.map()底层使用的就是系统调用mmap，函数签名为： public abstract MappedByteBuffer map(MapMode mode,long position, long size)throws IOException

答案2程序执行的系统调用追踪/** * @author Tptogiar * @description * @date /5/ - : */public class TestMappedByteBuffer{ public static final int _4kb = 4*;public static final int _GB= 1**;public static void main(String[] args) throws IOException, InterruptedException { // 为了方便在日志中找到本段代码的开始位置和结束位置，这里利用文件io来打开始标记FileInputStream startInput = null;try { startInput = new FileInputStream("start1.txt");startInput.read();} catch (IOException e) { e.printStackTrace();}File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB); //我们想分析的语句问题2for (int i = 0; i < _GB; i++) { map.put((byte)0); // 下文中需要分析的语句目的2}// 打结束标记FileInputStream endInput = null;try { endInput = new FileInputStream("end.txt");endInput.read();} catch (IOException e) { e.printStackTrace();}}}

       把上面这段代码编译后把“.class”文件拉到linux执行，并用linux上的strace工具记录其系统调用日志，拿到日志文件我们可以在日志中看到以下信息（关于怎么拿到日志可以参照我的博文：无（代写））：

       注：日志有多行，这里只选取我们关注的

// ...// 看到了我们打的开始标志openat(AT_FDCWD, "start1.txt", O_RDONLY) = -1 ENOENT (No such file or directory)// ... // 打开文件，文件描述符fd为6openat(AT_FDCWD, "filename", O_RDWR|O_CREAT, ) = 6// 判断文件状态fstat(6, { st_mode=S_IFREG|, st_size=, ...}) = 0// ... // 判断文件状态fstat(6, { st_mode=S_IFREG|, st_size=, ...}) = 0// 进行内存映射mmap(NULL, , PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x7f2fd6cd// ...// 程序退出exit(0)// 看到了我们打的结束标志openat(AT_FDCWD, "end.txt", O_RDONLY) = -1 ENOENT (No such file or directory)

       在上面程序的系统调用日志中我们确实看到了我们打的开始标志，结束标志。在开始标志和结束标志之间我们看到了我们的文件"filename"确实被打开了，文件描述符fd = 6；在打开文件后紧接着又执行了系统调用mmap，这一点我们Java代码一致，这样，我们就验证了我们答案1中的结论，可以开始我们的下文了

源码追踪分析，从Java到JNI，再到JVM的C++目的1寻源之旅：fileChannel.map()

       我们知道我们执行Java代码fileChannel.map()确实会在底层调用系统调用，那怎么在源码中得到验证呢？怎么落脚于源码进行分析呢？下面开始我们的寻源之旅

       FileChannelImpl.map() 注：由于代码较长，这里代码中略去了一些我们不关注的,比如异常捕获等

public MappedByteBuffer map(MapMode mode, long position, long size)throws IOException{ // ...try { // ...synchronized (positionLock) { // ...long mapPosition = position - pagePosition;mapSize = size + pagePosition;try { // ！我们要找的语句就在这！addr = map0(imode, mapPosition, mapSize);} catch (OutOfMemoryError x) { // 如果内存不足，先尝试进行GCSystem.gc();try { Thread.sleep();} catch (InterruptedException y) { Thread.currentThread().interrupt();}try { // 再次试着mmapaddr = map0(imode, mapPosition, mapSize);} catch (OutOfMemoryError y) { // After a second OOME, failthrow new IOException("Map failed", y);}}} // ...} finally { // ...}}

       上面函数源码中真正执行mmap的语句是在addr = map0(imode, mapPosition, mapSize),于是我们寻着这里继续追踪

       FileChannelImpl.map0()

// Creates a new mappingprivate native long map0(int prot, long position, long length)throws IOException;

       可以看到，该方法是一个native方法，所以后面的源码我们需要到这个FileChannelImpl.class对应的fileChannelImpl.c中去看，所以我们需要去找到JDK的源码

       在JDK源码中我们找到fileChannelImpl.c文件

       fileChannelImpl.c 根据JNI的对应规则，我们找到该文件内对应的Java_sun_nio_ch_FileChannelImpl_map0方法，其源码如下：

JNIEXPORT jlong JNICALLJava_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this, jint prot, jlong off, jlong len){ void *mapAddress = 0;jobject fdo = (*env)->GetObjectField(env, this, chan_fd);jint fd = fdval(env, fdo);int protections = 0;int flags = 0;if (prot == sun_nio_ch_FileChannelImpl_MAP_RO) { protections = PROT_READ;flags = MAP_SHARED;} else if (prot == sun_nio_ch_FileChannelImpl_MAP_RW) { protections = PROT_WRITE | PROT_READ;flags = MAP_SHARED;} else if (prot == sun_nio_ch_FileChannelImpl_MAP_PV) { protections =PROT_WRITE | PROT_READ;flags = MAP_PRIVATE;}// ！我们要找的语句就在这里！mapAddress = mmap(0,/* Let OS decide location */len,/* Number of bytes to map */protections,/* File permissions */flags,/* Changes are shared */fd, /* File descriptor of mapped file */off); /* Offset into file */if (mapAddress == MAP_FAILED) { if (errno == ENOMEM) { JNU_ThrowOutOfMemoryError(env, "Map failed");return IOS_THROWN;}return handle(env, -1, "Map failed");}return ((jlong) (unsigned long) mapAddress);}

       我们要找的语句就上面代码中的mapAddress = mmap(0,len,protections,flags,fd,off),至于为什么不是直接的mmap，而是mmap，是因为这里的mmap是一个宏，在文件上方有其定义，如下：

#define mmap mmap

       至此，我们就在源码中得到验证了我们问题2中的结论：fileChannelImpl.map()底层使用的是mmap系统调用

目的2寻源之旅：mmapedByteBuffer.put(Byte[ ])

       接着我们来看看当我们调用mmapedByteBuffer.put(Byte[])JVM底层在搞些什么动作

       MappedByteBuffer ?首先我们得知道，当我们执行MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB)时，实际返回的对象是DirectByteBuffer类的实例，因为MappedByteBuffer为抽象类，且只有DirectByteBuffer继承了它，看下面两图就明白了

       DirectByteBuffer 于是我们找到DirectByteBuffer内的put(Byte[ ])方法

public ByteBuffer put(byte x) { unsafe.putByte(ix(nextPutIndex()), ((x)));return this;}

       可以看到该方法内实际是调用Unsafe类内的putByte方法来实现功能的，所以我们还得去看Unsafe类

       Unsafe.class

public native voidputByte(long address, byte x);

       该方法在Unsafe内是一个native方法，所以所以我们还得去看unsafe.cpp文件内对应的实现

       unsafe.cpp

       在JDK源码中，我们找到unsafe.cpp

       在这份源码内，没有使用JNI内普通加前缀的方法来形成对应关系

       不过我们还是能顺着源码的蛛丝轨迹找到我们要找的方法

       注意到源码中有这样的注册机制，所以我们可以知道我们要找的代码就是上图中标注的代码

       顺藤摸瓜，我们就找到了该方法的定义

UNSAFE_ENTRY(void, Unsafe_SetNative##Type(JNIEnv *env, jobject unsafe, jlong addr, java_type x)) \UnsafeWrapper("Unsafe_SetNative"#Type); \JavaThread* t = JavaThread::current(); \t->set_doing_unsafe_access(true); \void* p = addr_from_java(addr); \*(volatile native_type*)p = x; \t->set_doing_unsafe_access(false); \UNSAFE_END \

       该方法内主要的逻辑语句就是以下两句：

/** * @author Tptogiar * @description * @date /5/ - : */public class TestMappedByteBuffer{ public static final int _4kb = 4*;public static final int _GB= 1**;public static void main(String[] args) throws IOException, InterruptedException { // 为了方便在日志中找到本段代码的开始位置和结束位置，这里利用文件io来打开始标记FileInputStream startInput = null;try { startInput = new FileInputStream("start1.txt");startInput.read();} catch (IOException e) { e.printStackTrace();}File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB); //我们想分析的语句问题2for (int i = 0; i < _GB; i++) { map.put((byte)0); // 下文中需要分析的语句目的2}// 打结束标记FileInputStream endInput = null;try { endInput = new FileInputStream("end.txt");endInput.read();} catch (IOException e) { e.printStackTrace();}}}0

       至此，我们就知道：其实我们调用mmapedByteBuffer.put(Byte[ ])时，JVM底层并不需要涉及到系统调用（这里也可以用strace工具追踪从而得到验证）。也就是说通过mmap映射的空间在内核空间和用户空间是共享的，我们在用户空间只需要像平时使用用户空间那样就行了————获取地址，设置值，而不涉及用户态，内核态的切换

总结

       fileChannelImpl.map()底层用调用系统函数mmap

       fileChannelImpl.map()返回的其实不是MappedByteBuffer类对象，而是DirectByteBuffer类对象

       在linux上可以通过strace来追踪系统调用

       JNI中“.class”文件内方法与“.cpp”文件内函数的对应关系不止是前缀对应的方法，还可以是注册的方式，这一点的追寻代码的时候有很大帮助

       directByteBuffer.put()方法底层并没有涉及系统调用，也就不需要涉及切态的性能开销(其底层知识执行获取地址，设置值的操作)，所以mmap的性能就比普通读写read/write好

       ...

原文：/post/