皮皮网

【Openmvs源码分析】【requestscope源码】【delphierp源码】jdk源码mmap

来源:马马源码 时间:2024-12-24 10:28:32

1.MappedByteBuffer VS FileChannel 孰强孰弱?
2.12 张图带你彻底理解 ZGC
3.Spring Boot引起的“堆外内存泄漏”排查及经验总结
4.一文搞定 mmap 内存映射原理

jdk源码mmap

MappedByteBuffer VS FileChannel 孰强孰弱?

        Java 在 JDK 1.4 引入了 ByteBuffer 等 NIO 相关的类,使得 Java 程序员可以抛弃基于 Stream ,从而使用基于 Block 的方式读写文件,另外,JDK 还引入了 IO 性能优化之王—— 零拷贝 sendFile 和 mmap。但他们的性能究竟怎么样? 和 RandomAccessFile 比起来,快多少? 什么情况下快?到底是 FileChannel 快还是 MappedByteBuffer å¿«......

        (零拷贝参考 Zero Copy I: User-Mode Perspective )

        天啊,问题太多了!!!!!!

        让我们慢慢分析。

        我们知道,Java 世界有很多 MQ:ActiveMQ,kafka,RocketMQ,去哪儿 MQ,而他们则是 Java 世界使用 NIO 零拷贝的大户。

        然而,他们的性能却大相同,抛开其他的因素,例如网络传输方式,数据结构设计,文件存储方式,我们仅仅讨论 Broker 端对文件的读写,看看他们有什么不同。

        下图是楼主查看源码总结的各个 MQ 使用的文件读写方式。

        那么,到底是 MMAP 强,还是 FileChannel 强?

        MMAP 众所周知,基于 OS 的 mmap 的内存映射技术,通过 MMU 映射文件,使随机读写文件和读写内存相似的速度。

        那 FileChannel 呢?是零拷贝吗?很遗憾,不是。FileChannel 快,只是因为他是基于 block 的。

        接下来,benchmark everything —— 徐妈.

        如何 Benchmark? Benchmark 哪些?

        既然是读写文件,自然就要看读写性能,这是最基本的。但,注意,通常 MQ 会使用定时刷盘,防止数据丢失,MMAP 和 FileChannel 都有 force 方法,用于将 pageCache 的数据刷到硬盘上。force 会影响性能吗? 答案是会。影响到什么程度呢? 不知道。每次写入的数据大小会影响性能吗,毫无疑问会,但规则是什么呢?FileOutputStream 真的一无是处吗?答案是不一定。

        一直以来,文件调优都是艺术,因为影响性能的因素太多,首先,SSD 的出现,已经让传统基于 B+ tree 的树形结构产生了自我疑问,第二,每个文件系统的性能不同,Linux ext3 和 ext4 性能天壤之别(删除文件的性能差距在 倍左右)。而 Max OS 的 HFS+ 系统被 Linus 称之为“有史以来最垃圾的文件系统”,幸运的是,苹果终于在 年推送了 macOS High Sierra 和 iOS .3 系统,这个两个系统都抛弃了 HFS+,换成了性能更高的 APFS。而每个文件系统又可以设置不同的调度算法,另外,还有虚拟内存缺页中断带来的性能毛刺.......

        (tips:良心的 RocketMQ 提供了 Linux IO 调优的脚本,这点做的不错 :)

        跑题了。

        楼主写了一个小项目,用于测试 Java MappedByteBuffer & FileChannel & RandomAccessFile & FileXXXputStream 的读写性能。大家也可以在自己的机器上跑跑看。

        CPU:intel i7 4æ ¸8线程 4.2GHz

        内存:GB DDR4

        磁盘:SSD 读写 2GB/s 左右

        JDK1.8

        OS:Mac OS ..6

        虚拟内存: 未关闭,大小 9GB

        测试注意点:

        1GB 文件:

        测试 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.

        从这张图里,我们看到,mmap 性能完胜,特别是在小数据量的情况下。其他的流,只有在4kb 的情况下,才开始反杀 mmap。因此,读 4kb 以下的数据,请使用 mmap。

        再放大看看 mmap 和 FileChannel 的比较:

        根据上图,我们看到,在写入数据包大于 4kb 以上的情况下,FileChannel 等一众非零拷贝,基本完胜 mmap,除了那个一次读 1G 文件的 BT 测试。

        因此,如果你的数据包大于 4kb,请使用 FileChannel。

        1GB 文件:

        测试 MappedByteBuffer & FileChannel & RandomAccessFile & FileInputStream.

        从上图,我们可以看出,mmap 性能还是一样的稳定。FileChannel 也不差,但是在 字节数据量的情况下,还差点意思。

        再看缩略图:

        我们看到,字节 是 FileChannel 和 mmap 性能的分水岭,从 字节开始,FileChannel 一路反杀,直到 BT 1GB 文件稍稍输了一丢丢。

        因此,我们建议:如果你的数据包大小在 字节以上,请使用 FileChannel 写入。

        我们知道,RocketMQ 使用异步刷盘,那么异步 force 对性能有没有影响呢?benchmark everything。我们使用异步线程,每 kb 刷盘一次,看看性能如何。

        mmap 一直落后,且性能很差,除了在 字节那里有一点点抖动,基本维持 在 左右,而没有 force 的情况下,则在 左右。而 FileChannel 则完全不受 force 的影响。在我的测试中,1GB 的文件,一次 force 需要 毫秒左右。buffer 越大,时间越多,反之则越小。

        说个题外话,Kafka 一直不建议使用 force,大概也有这个原因。当然,Kafka 还有自己的多副本策略保证数据安全。

        这里,我们得出结论,如果你需要经常执行 force,即使是异步的,也请一定不要使用 mmap,请使用 FileChannel。

        基于以上测试,我们得出一张图表:

        假设,我们的系统的数据包在 - 左右,我们应该使用什么策略?

        答:读使用 mmap,仅仅写使用 FileChannel。

        再回过头看看 MQ 的实现者们,似乎只有 QMQ 是 这么做的。当然,RocketMQ 也提供了 FileChannel 的写选项。但默认 mmap 写加异步刷盘,应该是 broker busy 的元凶吧。

        而 Kafka,因为默认不 force,也是使用 FileChannel 进行写入的,为什么使用 FileChannel 读呢?大概是因为消息的大小在 4kb 以上吧。

        这样一揣测,这些 MQ 的设计似乎都非常合理。

        最后,能不用 force 就别用 force。如果要用 force ,就请使用 FileChannel。

张图带你彻底理解 ZGC

       ZGC(Z Garbage Collector)是一款性能优于G1的垃圾收集器。ZGC自JDK 作为实验特性引入,至JDK 正式投入使用。启用方式为使用–XX:+UseZGC。ZGC有三大特色:

       1. 内存多重映射:ZGC使用mmap技术将不同的虚拟内存地址映射到同一物理内存地址,从而在Marked0、Openmvs源码分析Marked1和Remapped三个虚拟内存中灵活高效地管理内存。应用程序在创建对象时,为对象在上述三个视图空间分别申请一个虚拟地址,这三个虚拟地址映射到同一物理地址。Marked0、Marked1和Remapped作为ZGC的三个视图空间,同一时间点内只能有一个有效,通过切换视图空间完成并发的垃圾回收。

       2. 染色指针:ZGC使用染色指针技术将GC信息保存在指针上,提升GC效率。在位JVM中,对象指针为位,高位用于寻址,剩下位可管理内存达到TB。ZGC仅用高4位存储4个标志位,最大内存管理可达TB。通过这4个标志位,JVM可以直接从指针上获取对象的三色标记状态、是否进入重分配集和是否需要通过finalizer访问的信息,无需进行对象访问即可获得GC信息。

       3. 内存布局:ZGC基于Region进行内存分布,requestscope源码不区分新生代和老年代,支持动态创建和销毁,包括三种类型的Region。与G1类似,ZGC的内存布局同样基于Region,但其设计更注重并发和效率。

       4. 读屏障:读屏障技术是ZGC在解释执行时向应用代码中插入的小段代码,当线程从堆中读取对象引用时执行。它判断对象引用是否满足条件,执行相应动作,以实现高效的并发收集。读屏障会略微影响应用性能,但提高了GC并发能力,降低了停顿时间。

       5. GC过程:ZGC的垃圾收集过程包括标记、转移和重定位三个阶段。标记阶段从GC Roots出发,找出直接引用的对象,放入活跃对象集合。并发标记阶段GC线程和应用线程并行运行,标记过程中可能有引用关系变化导致的漏标记问题,再标记阶段重新标记并发标记阶段变化的对象。初始转移和并发转移阶段将活跃对象复制到新内存,转移过程对象地址发生改变,在重定位阶段调整所有指向对象旧地址的指针。

       6. 垃圾收集算法:ZGC采用标记-整理算法,delphierp源码将存活对象移动到堆的一侧,移动完成后回收边界以外的对象。在JDK 之前,ZGC预留了一块堆内存,以支持简单的并行收集算法,但存在预留内存的问题。JDK 改进后支持就地搬移对象,无需预留空闲内存。尽管就地搬移带来了挑战,如考虑搬移对象顺序,但总体提高了GC表现。

       ZGC的引入使并发性能大幅度提升,STW时间几乎只与GC Roots数量相关,不随堆大小和对象数量变化。ZGC的并发性能和内存管理技术显著改善了Java应用的垃圾回收效率,但其浮动垃圾问题仍然存在。

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申请内存请求,但是wbc源码并没有发现有可疑内存申请。

       接着,使用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升级到最新版本,这个问题也可以得到解决。

一文搞定 mmap 内存映射原理

       本文将深入解析内存映射文件技术mmap,它通过将文件或对象映射到进程地址空间,实现地址空间与文件磁盘地址的一一对应,使得进程能够通过指针操作内存,而系统会自动管理数据同步,无需频繁的系统调用。

       在Linux内核中,内存管理采用页式结构,进程通过task_struct和mm_struct描述其内存空间,其中vm_area_struct用于描述虚拟内存区域。当内存空间需求变化,会使用链表或红黑树进行动态管理。

       mmap的核心功能包括:建立内存和文件的映射关系、仅初始化映射而不进行数据拷贝、解除映射关系、对内存区域设置保护和同步操作。例如,mprotect允许调整内存保护级别,msync则确保映射区域的修改被写回文件。

       在JDK的DirectByteBuffer示例中,我们看到了mmap在内存管理中的实际应用,通过strace跟踪,可以看到一系列mmap、mprotect、brk和munmap等系统调用的交互过程,显示了mmap如何高效地进行内存操作,避免了常规IO中的两次数据拷贝。

       与常规IO相比,mmap的优势在于减少了数据复制的步骤,直接在用户空间和内核空间间交互,显著提高了数据访问速度。它广泛应用于需要高性能IO操作的场景,如NIO编程和直接内存访问。