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命令中已经显示申请内存的ios导入项目源码线程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环境变量，android 设置的源码发现没什么效果。查看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、编译android源码说明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的蓝牙app源码讲解内存管理机制通过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/