内存泄漏-ashmem(KERNEL\_MEMORY)问题排查
===============================

#### 问题现象

应用在使用过程中出现闪退，hilog日志中PROCESS\_KILL的Reason为ResourceLeak:Ashmem Leak，memory\_leak中生成memleak-kernel-\[process\_name\]-0-sample和memleak-kernel-\[process\_name\]-0-\[timestamp\]的内存泄漏日志文件。

#### 背景知识

*   ashmem（匿名共享内存）泄漏是指调用了申请ashmem内存接口后，由于疏忽或错误未能及时释放，导致ashmem内存持续累积，对整机运行造成影响。
*   ashmem泄漏的检测机制是通过内核监控整机ashmem内存是否超过阈值，当触发泄漏管控时，系统会对使用ashmem内存最多的应用进行终止。
*   应用被管控后，会在/data/log/memory\_leak/目录生成两个故障日志文件以供分析：
    *   memleak-native-\[process\_name\]-\[pid\]-0-sample.txt：采样日志文件，用于观察内存增长趋势，确认泄漏情况。
    *   memleak-native-\[process\_name\]-\[pid\]-0-\[timestamp\].txt：维测日志文件，记录了一些内存相关的统计信息，用于不同泄漏问题的维测。

*   DevEco Profiler提供了基础的内存场景分析Allocation，可以使用Allocation来分析应用或元服务在运行时的内存分配及使用情况，识别和定位内存泄漏、内存抖动以及内存溢出等问题，对应用或元服务的内存使用进行优化，参考文档[内存分析介绍](https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/ide-insight-session-allocations-memory)。

#### 问题定位

应用进程触发ashmem泄漏的管控后，系统会抓取泄漏相关的信息，在memory\_leak目录生成两个故障日志文件以供分析。

**步骤一：分析采样日志memleak-native-\[process\_name\]-\[pid\]-sample.txt。**

排查ashmem内存增长情况，是否超过了hardThreshold，或是超过softThreshold长时间未下降。

日志如下：

memoryName:ashmem
softThreshold:2048(MB)	<- 进程软门限
hardThreshold:4096(MB)	<- 进程硬门限
topMemory:3387703(KB)	<- ashmem内存峰值


              time(s)       kernelMemory(KB)         realtime
0               219             310903          2026/01/06 18:24:21
1               439             1321613         2026/01/06 18:28:01
2               659             1307039         2026/01/06 18:31:41
3               879             1377038         2026/01/06 18:35:21
4               1099            1374640         2026/01/06 18:39:01
5               1319            1369825         2026/01/06 18:42:41
6               1539            1363453         2026/01/06 18:46:21
7               1759            1364565         2026/01/06 18:50:01
8               1979            1299033         2026/01/06 18:53:41
9               2199            1299033         2026/01/06 18:57:21
10              2419            1930830         2026/01/06 19:01:01
11              2639            2017218         2026/01/06 19:04:41
12              2859            1875315         2026/01/06 19:08:29
13              3079            3322171         2026/01/06 19:12:09
14              3299            3387703         2026/01/06 19:15:49
15              3519            3387703         2026/01/06 19:19:29
16              3739            3387703         2026/01/06 19:23:09
17              3959            3367434         2026/01/06 20:06:46
18              4179            3325124         2026/01/06 20:45:02
19              4399            3338757         2026/01/06 20:48:42
20              4619            3340933         2026/01/06 21:00:05

**步骤二：分析维测日志memleak-native-\[process\_name\]-\[pid\]-0-\[timestamp\]。**

日志规格如下：

Generated by HiviewDFX @OpenHarmony
LOGGER\_MEMCHECK\_GERNAL\_INFO
memoryName:ashmem
softThreshold:2048(MB)
hardThreshold:4096(MB)
appHardThreshold:5460(MB)
topMemory:3387703(KB)


\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
LOGGER\_MEMCHECK\_MEMINFO		<- 整机内存统计信息
MemTotal:       15815588 kB
IonTotalUsed:     559284 kB
GpuTotalUsed:      48576 kB
AshmemUsed:      3340933 kB
\*\*\*\*\*\*\*\*\*\*\*\* endl \*\*\*\*\*\*\*\*\*\*\*\*


\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
LOGGER\_MEMCHECK\_PROC\_INFO	<- ashmem/ion/gpu对应泄漏内存节点信息打印(泄漏类型不同，落盘的内存信息不同)
ASHMEM\_PROCESS\_INFO
realtime:	2026/01/06 21:00:05
Process ashmem overview info:	<- 所有进程ashmem概览信息
---------------------------------------------------------------------------------
Process\_name Virtual\_size Physical\_size
Total ashmem  of \[render\_service\] virtual size is  2568215348, physical size is 1387921408 
Total ashmem  of \[com.hx.example\] virtual size is  3099027904, physical size is 1609773056 
// ...
Process ashmem detail info:		<- 进程ashmem详细信息
---------------------------------------------------------------------------------
Process\_name  Process\_ID  Fd   Cnode\_idx Applicant\_Pid	Ashmem\_name                Virtual\_size  Physical\_size magic
com.hx.example	19062	  252	328421	  19062	        dev/ashmem/shared\_memory/E...	4096	  0	       12188
com.hx.example	19062	  291	328421	  1388	        dev/ashmem/gralloc\_shared\_attr	4096	  4096	       12161
com.hx.example	19062	  271	328421	  19062	        dev/ashmem/Create PixelMap	11059200  11059200     31305
com.hx.example	19062	  317	328421	  19062	        dev/ashmem/Create PixelMap	3686400	  0	       12830
// ...
---------------------------------------------------------------------------------


\*\*\*\*\*\*\*\*\*\*\*\* endl \*\*\*\*\*\*\*\*\*\*\*\*

*   从LOGGER\_MEMCHECK\_MEMINFO整机内存统计信息中排查使用情况AshmemUsed。
*   从LOGGER\_MEMCHECK\_PROC\_INFO泄漏内存节点信息的overview概览中，排查应用进程的virtual size是否占比较大。
*   在Process ashmem detail info进程ashmem详细信息中，找到Process\_name为应用进程的数据，排查相同Ashmem\_name出现次数最多的Virtual\_size内存块，可能存在泄漏点。

**步骤三：结合业务代码分析泄漏点。**

排查方向：

*   如使用了Node-API在native层创建并使用decode()解码获取PixelMap，需排查申请未释放、把PixelMap缓存到应用生命周期的容器类中、对象引用计数变量多加等可能。相关接口文档可见[C API](https://developer.huawei.com/consumer/cn/doc/harmonyos-references/image-c)，排查使用后是否调用OH\_XXX\_Release()对应接口释放资源。
*   如使用了JS层的PixelMap，需排查JS对象泄漏或者缓存太多导致PixelMap大量占用，可使用DevEco Studio中的profiler工具抓取两次snapshot，分析对象的增量。相关接口文档可见[ArkTS API](https://developer.huawei.com/consumer/cn/doc/harmonyos-references/image-arkts)，排查使用后是否调用Release()对应接口释放资源。
*   pixmap使用的ashmem内存，应用可自定义绑定pixmap名字，当出现ashmem泄漏，快速根据ashmem块的名字锁定哪张图片存在问题，反推至对应的问题组件。JS层API：[setMemoryNameSync](https://developer.huawei.com/consumer/cn/doc/harmonyos-references/arkts-apis-image-pixelmap#setmemorynamesync13)，NATIVE层API：[OH\_PixelmapNative\_SetMemoryName()](https://developer.huawei.com/consumer/cn/doc/harmonyos-references/capi-pixelmap-native-h#oh_pixelmapnative_setmemoryname)。

#### 分析结论

应用存在ashmem泄漏，使用了PixelMap对象未释放。

#### 修改建议

程序需要正确管理分配的资源，使用完毕后需立刻释放。常见泄漏问题修复方法可见[资源泄漏类问题优化建议](https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-stability-leak-opt)和[资源泄漏类问题案例](https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-scenario-stability-leak)。