1.ptmalloc2 源码剖析3 -- 源码剖析
2.FPGA使用MIG调用SODIMM内存条接口教程，申请申请提供vivado工程源码和技术支持
3.Flink源码编译
4.Linux源码分析-RDMA的远程源码远程源码通信连接管理CM模块与编程示例
5.Spring Boot引起的“堆外内存泄漏”排查及经验总结

ptmalloc2 源码剖析3 -- 源码剖析

       文章内容包含平台配置、malloc_state、内存内存弄arena实例、调用调用new_arena、申请申请arena_get、远程源码远程源码群地址源码arena_get2、内存内存弄heap、调用调用new_heap、申请申请grow_heap、远程源码远程源码heap_trim、内存内存弄init、调用调用malloc_hook、申请申请malloc_hook_ini、远程源码远程源码ptmalloc_init、内存内存弄malloc_consolidate、public_mALLOc、sYSMALLOc、freepublic_fREe、systrim等关键模块。

       平台配置为 Debian AMD，使用ptmalloc2作为内存分配机制。

       malloc_state 表征一个arena，全局只有一个main_arena实例，arena实例通过malloc_init_state()函数初始化。

       当线程尝试获取arena失败时，通过new_heap获取内存区域，构建非main_arena实例。

       arena_get和arena_get2分别尝试线程的私有实例和全局arena链表获取arena，若获取失败，则创建new_arena。

       heap表示mmap映射连续内存区域，每个arena至少包含一个heap，且起始地址为HEAP_MAX_SIZE整数倍。

       new_heap尝试mmap映射内存，实现内存对齐，确保起始地址满足要求。

       grow_heap用于内存扩展与收缩，依据当前heap状态调用mprotect或mmap进行操作。

       heap_trim释放heap，电商springboot源码条件为当前heap无已分配chunk或可用空间不足。

       init阶段，通过malloc_hook、realloc_hook和__memalign_hook函数进行内存分配。

       malloc_consolidate合并fastbins和unsortedbin，优化内存分配。

       public_mALLOc作为内存分配入口。

       sYSMALLOc尝试系统申请内存，实现内存分配。

       freepublic_fREe用于释放内存，针对map映射内存调用munmap，其他情况归还给对应arena。

       systrim使用sbrk归还内存。

FPGA使用MIG调用SODIMM内存条接口教程，提供vivado工程源码和技术支持

       在FPGA应用中，数据缓存扮演着至关重要的角色，尤其在图像处理、AD采集及PCIe等领域。通常，FPGA会配备SDRAM、DDR3或DDR4等内存颗粒作为缓存资源，但有时受限于I/O端口或FPGA型号，可能需要额外设计SODIMM适配器以满足更高数据缓存需求。本文将介绍使用Xilinx V7 FPGA开发板NetFPGA-SUME平台实现SODIMM内存条接口的详细教程，并提供完整的vivado工程源码和技术支持，适用于学生、研究项目及在职工程师的学习与实践。

       实验板载有2个SODIMM接口，可插入内存条作为缓存，支持在FPGA开发板上进行视频缓存、处理和显示的测试。本例程使用HDMI输入视频或内部生成的彩条视频作为数据源，将视频缓存到SODIMM内存条中，进行三帧缓存后再输出至HDMI端口显示。成功或失败可通过输出图像质量直观判断，进而验证FPGA与SODIMM内存条的读写功能。

       本文提供了完整的工程源码和使用指南，旨在帮助读者快速掌握FPGA使用SODIMM内存条接口的实现方法，并支持项目移植。党务app 源码 下载内容涵盖从设计思路、硬件接口、内存配置到VGA时序生成的详细步骤，适用于医疗、军工等高速接口或图像处理领域的专业应用。

       请阅读至文章末尾以获取完整工程源码和技术支持的获取方式。请注意，本工程源码的使用仅限于个人学习和研究，禁止用于商业目的。若在使用过程中遇到问题或有建议，欢迎通过私信进行交流。

       为了确保本教程的实用性与合法性，部分源码和资源可能通过网络渠道获取，包括CSDN、Xilinx官网、Altera官网等。若在使用过程中发现任何侵权行为，请私信博主予以纠正。本教程及其相关资源仅供个人学习使用，博主不承担任何因个人使用导致的法律责任。

       在设计过程中，首先介绍了SODIMM内存条的基本信息及特点，与现代主板相比，它在紧凑性和灵活性上具有一定优势。接下来，设计思路包括了视频输入、缓存、SODIMM内存条配置、VGA时序生成及视频输出等关键步骤。

       视频输入部分，利用FMC接口接入HDMI输入或动态彩条视频源，其中HDMI输入通过silcom芯片解码，动态彩条视频则作为模拟输入源。视频缓存采用FDMA控制器实现，适用于各种类型数据的读写操作。MIG配置调用SODIMM内存条的关键在于正确配置内存参数以适应特定的内存条类型。

       VGA时序驱动的实现确保了视频流的正确输出，通过Verilog源码提供支持，可灵活调整分辨率。java个人项目源码最后，视频输出通过HDMI接口实现，利用silcom芯片进行编码，完成从FPGA到显示设备的视频传输。

       本教程详细解析了从硬件配置到软件实现的全过程，包括Vivado工程的设置、综合编译结果分析及上板调试验证。通过实际案例，展示了如何在FPGA开发板上利用SODIMM内存条进行数据缓存和处理。

       为了确保读者能够轻松获取到工程源码，提供了链接方式获取完整资源，确保学习者能够直接实践和应用教程内容。请注意遵守资源获取的规则，仅用于个人学习与研究目的。

Flink源码编译

       1. 下载Flink稳定版1..2，可以从官方下载链接获取，将源码同步至远程机器，使用Jetbrains Gateway打开。

       2. 以Jetbrains Gateway打开源码，源码目录存放于远程机器，它会自动解析为Maven项目。

       3. 注意事项：在flink-runtime-web/pom.xml文件中，需将部分内容替换，具体如下：

       确保先安装npm，通过命令`yum install npm`。否则编译过程中可能会出现错误。

       为了编译时内存充足，需要调整Maven设置，增加JDK可用内存。在命令行中，可以在/etc/profile中配置，或在Maven配置中指定更大的内存。

       编译命令如下，对于Jetbrains Gateway，需在Run Configurations中新增配置，调整执行参数以执行mvn install或mvn clean。

       编译完成后，每个模块目标文件夹会生成相应的文件。

       4. 接下来进行运行。12306 易语言源码首先启动JobManager，查看flink-runtime下的StandaloneSessionClusterEntrypoint类，配置文件目录需指定，如`--configDir configpath`，并配置日志参数。

       主类缺失时，需在IDEA的项目结构模块中给flink-runtime添加依赖，从flink-dist/target目录下添加jar包。

       修改配置文件，将允许访问的IP设置为0.0.0.0，以便外部访问。然后映射web端口，启动JobManager后可通过外部IP访问。

       运行TaskManager的参数与JobManager类似，启动后自动注册到JobManager，外部访问验证成功。

       源码编译与启动完成后，其他机器无需重复编译，只需在相应环境中执行预编译的可执行文件，即可实现分布式环境的Flink使用。

Linux源码分析-RDMA的通信连接管理CM模块与编程示例

       RDMA（远程直接内存访问）是一种高性能的网络通信技术，它允许在两个系统之间直接访问对方的内存，从而减少数据传输中的网络开销。RDMA CM（通信管理器）作为关键组件，负责设置和管理可靠、连接和不可靠的数据报数据传输。它提供了一种传输中立的接口，类似于套接字，但更适合于基于队列对（QP）的语义，强调通信必须通过特定的RDMA设备进行，并且数据传输基于消息。RDMA CM能够控制RDMA API的QP和通信管理部分，或者仅控制通信管理部分，与libibverbs库协同工作。libibverbs库提供了发送和接收数据所需的底层接口。

       在编程中，RDMA CM提供了多种操作模式，包括异步和同步操作。用户可以通过在特定调用中使用rdma_cm事件通道参数来控制操作模式。如果提供了事件通道，rdma_cm标识符将报告该通道上的事件数据（如连接结果）。如果未提供通道，则所选rdma_cm标识符的所有rdma_cm操作将被阻止，直到完成。此外，RDMA CM还为不同的libibverbs提供商提供了宣传和使用特定于该提供商的各种QP配置选项的功能，称为ECE（增强连接建立）。

       为了帮助开发者更好地理解和使用RDMA CM，提供了编程参考模型，其中包括对客户端和服务器端操作的概述。客户端操作通常涉及异步操作，而服务器端操作则侧重于被动等待连接。整个流程通常包括创建事件通道、分配通信标识、绑定地址、监听、初始化QP属性、建立连接等步骤。对于同步操作，相关的事件通道操作会被省略。

       以RDMA用户态驱动中的CM服务端为例，操作流程包括创建事件通道、分配通信标识、绑定地址、监听、初始化QP属性、建立连接等步骤。服务端还需要接收请求并处理连接接受。在内核态，还会涉及到更多调用接口，用于完成更复杂的操作。

       为了进一步了解RDMA CM的使用，推荐查阅RDMA CM用户手册和相关用户态仓库的笔记。此外，开发者可以通过访问晓兵的博客和加入DPU技术交流群来获取更多关于DPU、智能网卡、卸载、网络存储加速、安全隔离等技术的信息和资源。DPU专栏提供了更多关于DPU技术的深入讨论和最新进展。

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