1.开源项目|高性能内存分配库mimalloc
2.优化mysql 多大内存 centos6
3.在英特尔 CPU 上微调 Stable Diffusion 模型
4.Spring Boot引起的源码“堆外内存泄漏”排查及经验总结

开源项目|高性能内存分配库mimalloc

       mimalloc

       开源内存分配库，微软研究院年发布，源码旨在提供高性能内存管理解决方案。源码

       使用方法如下：

       1. 克隆代码库至本地。源码

       2. 编译代码。源码

       3. 将头文件复制至系统目录，源码共享童车 小程序 源码如：

       4. 编译项目时链接mimalloc。源码

       尝试直接使用mimalloc，源码无需编译：

       配置环境变量。源码

       mimalloc特点：

       1. 简洁高效，源码核心代码量少于行。源码

       2. 性能显著优于其他内存分配库，源码如：mi（mimalloc）、源码tc（tcmalloc）、源码je（jemalloc）等。源码

       3. 支持多线程。

       架构：

       mimalloc设计中，每个线程拥有专属堆，线程在分配内存时从各自堆进行。堆中包含多个分段，每个分段对应多个页面，内存分配在页面上进行。

       free列表操作代码。

       源码实现：

       1. malloc函数实现

       2. free函数实现

       [1] cnblogs.com/linkwk7/p/1...

       [2] github.com/microsoft/mi...

       [3] cnblogs.com/linkwk7/p/1...

优化mysql 多大内存 centos6

       ä¸€ã€mysql的优化思路

       mysql的优化分为两方面：

       1. 服务器使用前的优化

       2. 服务使用中的优化

       äºŒã€mysql的基础优化步骤

       1. 硬件级优化

       ï¼ˆ1）. 最好mysql自己使用一台物理服务器

       ï¼ˆ2）. 内存和CPU方面，根据需求给予mysql服务器足够大的内存和足够多的CPU核数

       (3). 避免使用Swap交换分区–交换时从硬盘读取的它的速度很慢，有的DBA安装系统时就不装swap分区

       ï¼ˆ4）. 如果是mysql主库，硬盘可以选用比较好的高速硬盘，系统用SSD固态硬盘，数据盘用sas替代sata硬盘，将操作系统和数据分区分开

       ï¼ˆ5）. mysql产生的日志与数据库也放到不同的磁盘分区上面

       ï¼ˆ6）. mysql数据库硬盘格式化时，可以指定更小的硬盘块

       ï¼ˆ7）. 关于做RAID方面，主库尽量做成RAID，既提高了数据的读写速度也提到了数据的安全性

       ï¼ˆ8). 服务器双线双电，保障服务器运行稳定，不会因为突然断电影响业务和损坏磁盘数据

       2. mysql数据库设计优化

       ï¼ˆ1). 根据需求选择正确的存储引擎，比如说读的特别猛就用MySAM,如果对事务性要求高就用InnoDB

       (2). 设置合理的字段类型和字段长度,比如说你这个字段就多个字段你设置成VARCHAR()就是对磁盘空间的浪费

       ï¼ˆ3）. 默认值尽可能的使用 NOT NULL，如果空值太多对mysql的查询会有影响，尤其是在查询语句编写上面

       ï¼ˆ4）. 尽量少的使用VARCHAR，TEXT，BLOB这三个字段

       ï¼ˆ5）. 添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引]

       ï¼ˆ6）. 不要滥用索引，大表索引，小表不索引

       ï¼ˆ7）. 表的设计合理化(符合3NF)

       3. mysql配置参数的优化

       è¿™é‡Œæ˜¯mysql5.5版本的配置文件

       vi my.cnf

       [client]

       port = #mysql客户端连接时的默认端口

       socket = /tmp/mysql.sock #与mysql服务器本地通信所使用的socket文件路径

       default-character-set = utf8 #指定默认字符集为utf8

       [mysql]

       no-auto-rehash #auto-rehash是自动补全的意思，就像我们在linux命令行里输入命令的时候，使用tab键的功能是一样的，这里是默认的不自动补全

       default-character-set = utf8 #指定默认字符集为utf8

       [mysqld]

       user = mysql

       port =

       character-set-server = utf8 #设置服务器端的字符编码

       socket = /tmp/mysql.sock

       basedir = /application/mysql

       datadir = /mysqldata

       skip-locking #避免MySQL的外部锁定，减少出错几率增强稳定性。

       open_files_limit = #MySQL打开的文件描述符限制，默认最小;当open_files_limit没有被配置的时候，比较max_connections*5和ulimit -n的值，哪个大用哪个，当open_file_limit被配置的时候，比较open_files_limit和max_connections*5的值，哪个大用哪个。

       back_log = #back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可 以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的限制。 试图设back_log高于你的操作系统的限制将是无效的。默认值为。对于Linux系统推荐设置为小于的整数。

       max_connections = #MySQL的最大连接数，如果服务器的并发连接请求量比较大，建议调高此值，以增加并行连接数量，当然这建立在机器能支撑的情况下，因为如果连接数越多， 介于MySQL会为每个连接提供连接缓冲区，就会开销越多的内存，所以要适当调整该值，不能盲目提高设值。可以过’conn%’通配符查看当前状态的连接 数量，以定夺该值的大小。

       max_connect_errors = #对于同一主机，如果有超出该参数值个数的中断错误连接，则该主机将被禁止连接。如需对该主机进行解禁，执行：FLUSH HOST。

       table_cache = #物理内存越大,设置就越大.默认为,调到-最佳

       external-locking = FALSE #使用–skip-external-locking MySQL选项以避免外部锁定。该选项默认开启

       max_allowed_packet =8M #设置最大包,限制server接受的数据包大小，避免超长SQL的执行有问题 默认值为M，当MySQL客户端或mysqld服务器收到大于max_allowed_packet字节的信息包时，将发出“信息包过大”错误，并关闭连接。对于某些客户端，如果通信信息包过大，在执行查询期间，可能会遇“丢失与MySQL服务器的连接”错误。默认值M。

       sort_buffer_size = 6M #用于表间关联缓存的大小，查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有个连接，那么实际分配的总共排序缓冲区大小为 × 6 ＝ MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。

       join_buffer_size = 6M #联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。

       thread_cache_size = #服务器线程缓存这个值表示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中,如果线程重新被请求， 那么请求将从缓存中读取,如果缓存中是空的或者是新的请求，那么这个线程将被重新创建,如果有很多新的线程，增加这个值可以改善系统性能.通过比较 Connections 和 Threads_created 状态的变量，可以看到这个变量的作用

       thread_concurrency = 8 #设置thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的情况下，错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU, 那么thread_concurrency的应该为4; 2个双核的cpu, thread_concurrency的值应为8，属重点优化参数

       query_cache_size = 2M #指定MySQL查询缓冲区的大小，在数据库写入量或是更新量也比较大的系统，该参数不适合分配过大。而且在高并发，写入量大的系统，建系把该功能禁掉。

       query_cache_limit = 1M #默认是4KB，设置值大对大数据查询有好处，但如果你的查询都是小数据查询，就容易造成内存碎片和浪费

       query_cache_min_res_unit = 2k #MySQL参数中query_cache_min_res_unit查询缓存中的块是以这个大小进行分配的，使用下面的公式计算查询缓存的平均大小，根据计算结果设置这个变量，MySQL就会更有效地使用查询缓存，缓存更多的查询，减少内存的浪费。

       default_table_type = InnoDB #默认表的引擎为InnoDB

       thread_stack = K #限定用于每个数据库线程的栈大小。默认设置足以满足大多数应用transaction_isolation = READ-COMMITTED #设定默认的事务隔离级别.可用的级别如下:

       READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE,1.READ UNCOMMITTED-读未提交2.READ COMMITTE-读已提交3.REPEATABLE READ -可重复读4.SERIALIZABLE -串行

       tmp_table_size = M #tmp_table_size 的默认大小是 M。如果一张临时表超出该大小，MySQL产生一个 The table tbl_name is full 形式的错误，如果你做很多高级 GROUP BY 查询，增加 tmp_table_size 值。

       max_heap_table_size = M #内存表，内存表不支持事务，内存表使用哈希散列索引把数据保存在内存中，因此具有极快的速度，适合缓存中小型数据库，但是使用上受到一些限制

       long_query_time = 1 #记录时间超过1秒的查询语句

       log_long_format #

       log-error = /logs/error.log #开启mysql错误日志，该选项指定mysqld保存错误日志文件的位置

       log-slow-queries = /logs/slow.log #慢查询日志文件路径

       pid-file = /pids/mysql.pid

       log-bin = /binlog/mysql-bin #binlog日志位置以及binlog的名称

       relay-log = /relaylog/relay-bin #relaylog日志位置以名称

       binlog_cache_size = 1M #binlog_cache_size 就是满足两点的：一个事务，在没有提交（uncommitted）的时候，产生的日志，记录到Cache中；等到事务提交（committed）需要提交的时候，则把日志持久化到磁盘，默认是K。

       max_binlog_cache_size = M #binlog缓存最大使用的内存

       max_binlog_size = 2M #一个binlog日志的大小

       expire_logs_days = 7 #保留7天的binlog

       key_buffer_size = M #索引缓存大小: 它决定了数据库索引处理的速度，尤其是索引读的速度

       read_buffer_size = M #MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能

       read_rnd_buffer_size = 2M #MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如，按照排序顺序)，将分配一个随机读缓存区。进行排序查询时，MySQL会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大

       bulk_insert_buffer_size = 1M #批量插入数据缓存大小，可以有效提高插入效率，默认为8M

       myisam_sort_buffer_size = 1M #MyISAM表发生变化时重新排序所需的缓冲

       myisam_max_sort_file_size = G #MySQL重建索引时所允许的最大临时文件的大小 (当 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE). 如果文件大小比此值更大,索引会通过键值缓冲创建(更慢)

       myisam_repair_threads = 1 #如果一个表拥有超过一个索引, MyISAM 可以通过并行排序使用超过一个线程去修复他们.这对于拥有多个CPU以及大量内存情况的用户,是一个很好的选择.

       myisam_recover #自动检查和修复没有适当关闭的 MyISAM 表

       lower_case_table_names = 1 #让mysql不区分大小写

       skip-name-resolve #禁用DNS解析，连接速度会快很多。不过，这样的话就不能在MySQL的授权表中使用主机名了而只能用ip格式。

       #slave-skip-errors = , #这是选填项让slave库跳过哪些错误继续同步

       #replicate-ignore-db=mysql #选填，同步时候哪个数据库不同步设置

       server-id = 1

       innodb_additional_mem_pool_size = 4M #InnoDB 存储的数据目录信息和其它内部数据结构的内存池大小。应用程序里的表越多，你需要在这里分配越多的内存，默认是2M

       innodb_buffer_pool_size = M #这对Innodb表来说非常重要。Innodb相比MyISAM表对缓冲更为敏感。MyISAM可以在默 认的 key_buffer_size 设置下运行的可以，然而Innodb在默认的 设置下却跟蜗牛似的。由于Innodb把数据和索引都缓存起来，无需留给操作系统太多的内存，因此如果只需要用Innodb的话则可以设置它高达 -% 的可用内存。一些应用于 key_buffer 的规则有 — 如果你的数据量不大，并且不会暴增，那么无需把 innodb_buffer_pool_size 设置的太大了

       innodb_file_io_threads = 4 #文件IO的线程数，一般为 4

       innodb_thread_concurrency = 8 #你的服务器CPU有几个就设置为几,建议用默认一般为8

       innodb_flush_log_at_trx_commit = 2 #默认为1，如果将此参数设置为1，将在每次提交事务后将日志写入磁盘。为提供性能，可以设置为0或2，但要承担在发生故障时丢失数据的风险。设置为0表示事务日志写入日志文件，而日志文件每秒刷新到磁盘一次。设置为2表示事务日志将在提交时写入日志，但日志文件每次刷新到磁盘一次。

       innodb_log_buffer_size = 2M #此参数确定些日志文件所用的内存大小，以M为单位。缓冲区更大能提高性能，但意外的故障将会丢失数据.MySQL开发人员建议设置为1－8M之间

       innodb_log_file_size = 4M #此参数确定数据日志文件的大小，以M为单位，更大的设置可以提高性能，但也会增加恢复故障数据库所需的时间

       innodb_log_files_in_group = 3 #为提高性能，MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3M

       innodb_max_dirty_pages_pct = #Buffer_Pool中Dirty_Page所占的数量，直接影响InnoDB的关闭时间。参数 innodb_max_dirty_pages_pct可以直接控制了Dirty_Page在Buffer_Pool中所占的比率，而且幸运的是 innodb_max_dirty_pages_pct是可以动态改变的。所以，在关闭InnoDB之前先调小，强制数据块Flush一段时间，则能够大大缩短MySQL关闭的时间。

       innodb_lock_wait_timeout = #InnoDB 有其内置的死锁检测机制，能导致未完成的事务回滚。但是，如果结合InnoDB使用MyISAM的lock tables 语句或第三方事务引擎,则InnoDB无法识别死锁。为消除这种可能性，可以将innodb_lock_wait_timeout设置为一个整数值，指示 MySQL在允许其他事务修改那些最终受事务回滚的数据之前要等待多长时间(秒数)

       innodb_file_per_table = 0 #独享表空间（关闭）

       [mysqldump]

       quick

       max_allowed_packet = M

       4. 架构优化

       ï¼ˆ1）. 前端用memcached，redis等缓存分担数据库压力

       ï¼ˆ2）. 数据库读写分离，负载均衡

       ï¼ˆ3）. 数据库分库分表

       ï¼ˆ4）. 存储可采取分布式

       5. 后期优化

       ä¸»è¦æ˜¯å¤šè§‚察，后期就是维护工作了，观察服务器负载是需要添加硬件了，还是有语句有问题啊，还是参数要修改了。

       6. 查询优化（摘抄别人的）

       . 使用慢查询日志去发现慢查询。

       . 使用执行计划去判断查询是否正常运行。

       . 总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。

       . 避免在整个表上使用count(*),它可能锁住整张表。

       . 使查询保持一致以便后续相似的查询可以使用查询缓存。

       . 在适当的情形下使用GROUP BY而不是DISTINCT。

       . 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。

       . 保持索引简单,不在多个索引中包含同一个列。

       . 有时候MySQL会使用错误的索引,对于这种情况使用USE INDEX。

       . 检查使用SQL_MODE=STRICT的问题。

       . 对于记录数小于5的索引字段，在UNION的时候使用LIMIT不是是用OR.

       . 为了 避免在更新前SELECT，使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去实现。

       . 不要使用 MAX,使用索引字段和ORDER BY子句。

       . 避免使用ORDER BY RAND().

       ã€‚LIMIT M，N实际上可以减缓查询在某些情况下，有节制地使用。

       ã€‚在WHERE子句中使用UNION代替子查询。

       ã€‚对于UPDATES（更新），使用 SHARE MODE（共享模式），以防止独占锁。

       ã€‚在重新启动的MySQL，记得来温暖你的数据库，以确保您的数据在内存和查询速度快。

       ã€‚使用DROP TABLE，CREATE TABLE DELETE FROM从表中删除所有数据。

       ã€‚最小化的数据在查询你需要的数据，使用*消耗大量的时间。

       ã€‚考虑持久连接，而不是多个连接，以减少开销。

       ã€‚基准查询，包括使用服务器上的负载，有时一个简单的查询可以影响其他查询。

       ã€‚当负载增加您的服务器上，使用SHOW PROCESSLIST查看慢的和有问题的查询。

       ã€‚在开发环境中产生的镜像数据中 测试的所有可疑的查询。

在英特尔 CPU 上微调 Stable Diffusion 模型

       扩散模型，一种能够根据文本提示生成逼真图像的能力，显著推动了生成式人工智能的普及。这些模型广泛应用于数据合成和内容创建等领域，语音聊天机器人 源码Hugging Face Hub 上拥有超过5千个预训练的文生图模型。结合Diffusers库，构建图像生成工作流或实验不同的图像生成流程变得极为简便。

       微调扩散模型以满足特定业务需求的图像生成，通常依赖于GPU。然而，这一情况正在发生变化。英特尔推出了代号为Sapphire Rapids的第四代至强CPU，其中包含英特尔先进矩阵扩展(AMX)，专门用于加速深度学习工作负载。在之前的博文中，我们已经展示了AMX的优势，包括微调NLP transformer模型、对NLP transformer模型进行推理以及对Stable Diffusion模型进行推理。

       本文将展示如何在英特尔第四代至强CPU集群上微调Stable Diffusion模型。我们采用文本逆向(Textual Inversion)技术进行微调，仅需少量训练样本即可有效调整模型。使用5个样本即可实现。

       配置集群时，我们利用英特尔开发者云提供的服务器。这些服务器配置了英特尔第四代至强CPU，每颗CPU包含个物理核和个线程。通过nodefile文件，我们管理了服务器IP地址，其中第一行指为主服务器。

       分布式训练要求主节点与其他节点之间实现无密码SSH通信。android 本地音乐播放器源码设置无密码SSH，参考相关文章步骤操作。

       搭建运行环境并安装所需软件，包括英特尔优化库如oneCCL和Intel Extension for PyTorch(IPEX)，以利用Sapphire Rapids的硬件加速功能。此外，我们安装了高性能内存分配库libtcmalloc及其软件依赖项gperftools。

       在每个节点上，我们克隆diffusers代码库并进行源码安装。对diffusers/examples/textual_inversion中的微调脚本进行优化，利用IPEX对U-Net和变分自编码器(VAE)模型进行推理优化。

       下载训练图像，确保在所有节点上的目录路径一致。微调任务启动后，加速器会自动在节点间建立分布式的训练。

       配置微调环境时，使用accelerate库简化分布式训练。在每个节点上运行acclerate config并回答问题。设置环境变量，确保所有节点间的通信。

       启动微调，使用mpirun在nodefile列出的节点间建立分布式通信。运行命令训练步，耗时约5分钟。训练过程中的集群状态显示在截图中。

       分布式训练中可能出现的源码 web代理服务器错误通常包括单节点配置错误，如依赖项缺失或图像位置不同。登录各节点并本地训练可快速定位问题。如果所有节点的训练均成功启动，检查nodefile、环境和mpirun命令。

       微调模型后，直接使用diffusers的pipeline加载模型进行图像生成。进一步使用Optimum Intel和OpenVINO对模型进行推理优化。优化后，仅用单颗CPU即可在不到5秒内生成图像。

       加载优化后的模型，生成5张不同图像并保存。生成的图像显示模型仅用5张图像就能识别dicoo戴眼镜。对模型进行更多微调，如步，可获得更佳效果。

       借助Hugging Face与英特尔的合作，现在能够利用至强CPU服务器生成符合业务需求的高质量图像。CPU不仅比GPU等专用硬件更便宜且易得，还能轻松执行其他任务如Web服务器、数据库等，成为IT基础设施的多功能灵活选择。

       入门资源包括：

       如有任何疑问或反馈，请访问Hugging Face论坛留言。

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

       为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），java web进销存源码下载随后我们就发现系统会频繁报出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升级到最新版本，这个问题也可以得到解决。