大家好，我是[晚风依旧似温柔]，新人一枚，欢迎大家关注~

前言

在 HarmonyOS 应用的长稳测试与高强度压测中，经常会出现应用崩溃或卡顿的稳定性问题。分析日志时，常常会遇到诸如 Too many open files 异常、Native 内存持续走高，或是线程数突破上限等现象。很多开发者的第一反应是检查代码中是否少写了 fs.closeSync() 或 fs.close()。然而在实际工程排查中，往往会发现即便是所有的文件调用地方都加上了 close，资源泄漏依然可能在角落里悄然发生。

在 HarmonyOS 的 ArkTS 与 Native (C/C++) 双引擎架构下，资源泄漏的形态比单语言环境更加复杂。本文将从文件句柄、线程以及 Native 内存三个维度，详细剖析 HarmonyOS 应用稳定性排查的全流程，结合 DevEco Testing 工具与 DevEco Profiler 的离线分析定位能力，一步步还原并解决资源泄漏问题。

一、鸿蒙应用中的三种典型资源泄漏场景

在 HarmonyOS 中，资源不仅存在于 ArkTS 托管堆中，更大量存在于系统底层的 Native 堆与内核资源表中。仅仅依靠 JavaScript/ArkTS 的垃圾回收机制（GC），无法完全自动解决下层物理资源的释放。

1. 文件句柄（File Descriptor, FD）泄漏

在 ArkTS 中使用 @ohos.file.fs 进行文件读写时，fs.openSync() 会返回一个包含 fd 属性的 File 对象。
即使显式调用了 fs.closeSync(file)，依然可能在以下场景导致 FD 泄漏：

• 异常流分支未覆盖：文件打开后，在读写逻辑中抛出了未捕获的 Exception，导致后续的 closeSync 代码未被执行。
• 文件流（Stream）未关闭：通过 fs.createStreamSync() 或 fs.fdopenStreamSync() 创建了流对象，仅关闭了底层 File 对象，而没有调用 stream.closeSync()，导致系统内部引用的 FD 句柄未能释放。
• C++ 跨界传输持有：将 FD 传递至 Native 侧处理（例如使用 napi 传入 fd 参数），Native 侧通过 dup() 复制了文件描述符或在 C++ 内部重新打开，而在 Native 生命周期结束时未匹配 close()。

2. 线程泄漏（Thread Leak）

HarmonyOS 提供了 ArkTS Worker 与 TaskPool 两种多线程并发机制，同时在 Native 侧支持 POSIX 线程（pthread）和 C++11 std::thread：

• Worker 未销毁：ArkTS 中通过 new worker.ThreadWorker() 创建并发线程后，如果 Worker 完成任务未调用 worker.terminate()，或者宿主线程未调用 worker.terminate()，该 Worker 对应的后台线程及其底层 JS 引擎实例将长期驻留内存。
• NAPI 异步线程未清理：Native 侧使用 napi_create_async_work 执行异步耗时任务，如果异步任务结束后未匹配执行 napi_delete_async_work；或者在 C++ 中启动了长期等待信号量的子线程，导致线程无法退出。

3. Native 内存泄漏（Native Memory Leak）

ArkTS 运行时支持对 JS 堆内存进行自动垃圾回收，但对于 Native (C/C++) 侧通过 malloc、new 分配的内存，ArkTS GC 无法直接掌控：

• 未绑定 Finalizer：当 ArkTS 对象包裹了一个 Native 对象（如 C++ 实例指针）时，若没有使用 napi_add_finalizer 为 ArkTS 对象注册回收回调，当 ArkTS 对象被 GC 回收时，底层 C++ 对象的内存便永远丢失了引用，造成 Native 堆持续膨胀。
• C++ 侧数据结构膨胀：全局 C++ 单例或静态容器（如 std::vector、std::map）持续追加缓存数据，却没有设置淘汰机制或释放逻辑。

二、官方规则与限制核对

在进行稳定性排查与代码修复前，需要先厘清 HarmonyOS 系统对资源开限制的约束条件：

资源类型	系统限制与特征	官方推荐排查工具	关键机制与 API
文件句柄 (FD)	单个进程 FD 存在上限（通常为 1024）。超出抛出 Too many open files 错误。	DevEco Testing / DevEco Profiler	@ohos.file.fs 的 fs.open / fs.close
线程 (Thread)	单应用最大线程数受限，Worker 数量上限为 8 个（同线程组）。	DevEco Profiler (Threads UI)	@ohos.worker 的 terminate()
Native 内存	受进程虚拟内存限制，超限引发 OOM 崩溃。GC 无法感知 Native 内存压力。	Profiler Allocation Profiler / Call Trees	Node-API 的 napi_add_finalizer

三、利用 DevEco Testing 获取稳定性泄漏日志

在开发测试阶段，人工点击很难触发极端的稳定性与泄漏问题。华为官方提供的 DevEco Testing（测试套件）具备自动化稳定性压测能力，能够长时间对应用施加随机事件并监控底层资源使用情况。

1. 配置并运行稳定性测试

1. 在 DevEco Studio 中打开 DevEco Testing 视图，选择 Stability Test（稳定性测试）。
2. 选择连接的真机或模拟器设备，设置测试时长（例如 2 小时或 12 小时长稳压测）。
3. 配置应用包名以及事件随机概率，启动压测。

2. 导出与分析泄漏日志

压测结束后，DevEco Testing 会自动收集日志并生成报告。如果应用存在句柄或内存泄漏，报告中会产生对应的 Crash 日志或 Warning 标记：

• FD 泄漏特征日志：在 hilog 或 crash 日志中检索 Failed to open file 或 Errno: 24 (Too many open files)。
• Native 内存泄漏特征日志：日志中出现 Out of Memory 或进程收到 SIGABRT，且在崩溃前的系统日志中可看到应用进程内存 (PSS) 呈线性递增状态。

当拿到带有资源异常特征的测试报告后，需要导出对应的 htrace 轨迹文件或 Heap Snapshot 堆快照文件，以便在 DevEco Profiler 中进行精细定位。

四、使用 DevEco Profiler 导入与 Call Trees 定位技术

获得跟踪文件后，打开 DevEco Studio 的 Profiler 离线分析功能，导入抓取的跟踪数据。

1. 导入数据文件

点击 Profiler 界面左侧的 Import File 按钮，选中由测试工具导出的 .htrace 或 .heapsnapshot 文件。

2. 利用 Call Trees 分析长期未释放资源

在 Profiler 界面选择 Memory / Allocation Profiler 视图，关键步骤如下：

1. 选择时间段：框选稳定性压测后期内存/句柄处于高水位的区域。
2. 切换至 Call Trees：将视图从 List 模式切换至 Call Trees。
3. 设置过滤条件：勾选 Arrange by Callstacks，并关注 Live Bytes（存活字节数）与 Allocation Size（分配总额）。
4. 定位异常分配根节点：展开调用树，寻找顶级分配量极大且没有被收回的函数调用路径。Profiler 会将 ArkTS 源码与 Native C++ 代码的调用栈融合展示，顺着调用栈即可直接定位到未释放资源的源码文件名与行号。

五、最小可复现场景与代码实现

为了直观理解这三种泄漏场景及其修复方案，下面用一个包含 ArkTS 文件读写、Worker 线程以及 Native C++ 绑定的最小示例进行展示。

1. 存在资源泄漏隐患的代码实现

ArkTS 侧（存在 FD 泄漏与 Worker 泄漏隐患）

// FaultyResourceManager.ts
import fs from '@ohos.file.fs';
import worker from '@ohos.worker';
import { BusinessError } from '@ohos.base';

export class FaultyResourceManager {
  private workerInstance: worker.ThreadWorker | null = null;

  // 场景一：读写日志文件，异常跳过 close，且使用 Stream 未关闭
  public readLogFile(filePath: string): string {
    // 打开文件
    let file = fs.openSync(filePath, fs.OpenMode.READ_WRITE | fs.OpenMode.CREATE);
    
    // 创建文件流
    let stream = fs.fdopenStreamSync(file.fd, 'r+');
    
    // 如果中途逻辑出现异常，下面的 closeSync 将不会被执行，造成 FD 泄漏
    if (filePath.includes('invalid')) {
      throw new Error('Invalid path encountered');
    }

    let buf = new ArrayBuffer(1024);
    stream.readSync(buf);

    // 仅关闭了 file，但未关闭 stream，底层 FD 依然可能被流句柄持有
    fs.closeSync(file);
    return 'success';
  }

  // 场景二：频繁创建 Worker 线程未关闭
  public startBackgroundProcessing(): void {
    // 每次调用都创建新 Worker，但未存储引用，也未在处理完成后 terminate
    let tempWorker = new worker.ThreadWorker('entry/ets/workers/DataWorker.ets');
    tempWorker.onmessage = (e) => {
      console.info('Worker task finished');
      // 错误：缺少 tempWorker.terminate()
    };
    tempWorker.postMessage({ type: 'START' });
  }
}

Native C++ 侧（存在 Native 内存泄漏隐患）

// native_bridge.cpp
#include "napi/native_api.h"
#include <cstdlib>
#include <cstring>

struct NativeBufferContext {
    char* data;
    size_t size;
};

// ArkTS 调用该方法创建 Native 结构体
static napi_value CreateNativeContext(napi_env env, napi_callback_info info) {
    NativeBufferContext* context = new NativeBufferContext();
    context->size = 1024 * 1024; // 1MB
    context->data = static_cast<char*>(malloc(context->size));

    napi_value result;
    NAPI_CALL(env, napi_create_object(env, &result));

    // 将指针存入 JS 对象
    NAPI_CALL(env, napi_wrap(env, result, context, nullptr, nullptr, nullptr));
    
    // 错误：此处 napi_wrap 的 4,5,6 参数传入了 nullptr！
    // 没有为 context 绑定 napi_finalize 回调，当 ArkTS 对象 GC 时，C++ 的 context 内存泄漏！

    return result;
}

2. 规范的修复方案与代码实现

ArkTS 侧规范修复

通过 try ... finally 语法块确保文件及流句柄在任何情况下均能安全释放；对 Worker 进行显式生命周期管理。

// CorrectResourceManager.ts
import fs from '@ohos.file.fs';
import worker from '@ohos.worker';

export class CorrectResourceManager {
  // 规范一：安全的文件与流释放
  public readLogFileSafely(filePath: string): string {
    let file: fs.File | null = null;
    let stream: fs.Stream | null = null;

    try {
      file = fs.openSync(filePath, fs.OpenMode.READ_WRITE | fs.OpenMode.CREATE);
      stream = fs.fdopenStreamSync(file.fd, 'r+');

      let buf = new ArrayBuffer(1024);
      stream.readSync(buf);

      if (filePath.includes('invalid')) {
        throw new Error('Invalid path encountered');
      }

      return 'success';
    } finally {
      // 在 finally 块中逐层安全关闭资源
      if (stream) {
        try {
          stream.closeSync(); // 优先关闭封装的流
        } catch (e) {
          console.error(`Failed to close stream: ${JSON.stringify(e)}`);
        }
      }
      if (file) {
        try {
          fs.closeSync(file); // 再关闭底层的 File 句柄
        } catch (e) {
          console.error(`Failed to close file: ${JSON.stringify(e)}`);
        }
      }
    }
  }

  // 规范二：Worker 线程生命周期显式管理
  public startBackgroundProcessingSafely(): void {
    let tempWorker = new worker.ThreadWorker('entry/ets/workers/DataWorker.ets');
    
    tempWorker.onmessage = (e) => {
      console.info('Worker task finished');
      // 任务完成后显式销毁 Worker 线程
      tempWorker.terminate();
    };

    tempWorker.onerror = (err) => {
      console.error(`Worker error: ${err.message}`);
      // 异常情况下同样需要销毁 Worker 线程
      tempWorker.terminate();
    };

    tempWorker.postMessage({ type: 'START' });
  }
}

Native C++ 侧规范修复

使用 napi_add_finalizer 为 ArkTS 对象绑定终结器回调函数，当垃圾回收器清理该对象时，触发 C++ 内存释放逻辑。

// native_bridge_corrected.cpp
#include "napi/native_api.h"
#include <cstdlib>

struct NativeBufferContext {
    char* data;
    size_t size;
};

// 终结器回调函数：在 ArkTS 对象被 GC 回收时由系统调用
static void FinalizeNativeContext(napi_env env, void* finalize_data, void* finalize_hint) {
    if (finalize_data != nullptr) {
        NativeBufferContext* context = static_cast<NativeBufferContext*>(finalize_data);
        if (context->data != nullptr) {
            free(context->data);
            context->data = nullptr;
        }
        delete context;
    }
}

static napi_value CreateNativeContextSafely(napi_env env, napi_callback_info info) {
    NativeBufferContext* context = new NativeBufferContext();
    context->size = 1024 * 1024; // 1MB
    context->data = static_cast<char*>(malloc(context->size));

    napi_value result;
    NAPI_CALL(env, napi_create_object(env, &result));

    // 正确：注册 Finalizer 回调，将 C++ 对象的生命周期与 ArkTS JSObject 绑定
    NAPI_CALL(env, napi_wrap(
        env,
        result,
        context,
        FinalizeNativeContext, // 传入终结器函数指针
        nullptr,
        nullptr
    ));

    return result;
}

六、排查与修复的关键点总结

在排查 HarmonyOS 应用稳定性时，以下几个关键细节需要格外留心：

1. fs.fdopenStreamSync 的句柄所有权：
   通过 fdopenStreamSync 将 FD 转为 Stream 后，Stream 内部会接管该 FD。如果仅关闭 File 而未关闭 Stream，会导致 FD 资源无法在内核中真正注销。因此优先建议使用 stream.closeSync() 释放文件流。
2. ArkTS GC 的滞后性与 Native 内存压力：
   GC 何时运行是由 JS 引擎决定的。如果 ArkTS 对象很小（例如只包含一个 Native 指针），但 Native 侧占用了巨大的内存（如解码后的纹理或图片数据），GC 可能无法及时感知到内存压力而触发垃圾回收。因此除了使用 napi_add_finalizer 外，对于大内存 Native 资源，建议设计显式的 release() 或 destroy() ArkTS 接口供上层手动调用。
3. Worker 线程的计数与清理：
   根据系统约束，同一线程组内的 Worker 数量存在限制（最多 8 个）。如果频繁创建短生命周期的 Worker，必须确保在 onmessage / onerror 监听到终止信号后调用 worker.terminate()。如果不确定并发量，优先考虑使用 TaskPool 代替 Worker。

七、稳定性问题排查清单

当在长稳压测中发现应用存在资源异常时，建议按照以下排查顺序逐步定位：

1. 确认报错类型与资源特征
   ├── 报 "Too many open files" ──> 排查 FD 句柄排查清单 (见步骤 2)
   ├── 线程数突破上限 / 卡死 ──> 排查 Worker/TaskPool 清理 (见步骤 3)
   └── 进程 PSS 内存持续上升 ──> 排查 Native 内存与 NAPI 终结器 (见步骤 4)

2. FD 排查清单：
   [ ] 检查所有的 fs.open / fs.openSync 是否被包裹在 try...finally 块中。
   [ ] 检查是否使用了 fs.fdopenStreamSync / createStreamSync，确认流对象调用了 closeSync。
   [ ] 检查 C++ Native 侧传出的 FD 参数，确认 Native 侧使用完毕后是否有 close 调用。

3. 线程排查清单：
   [ ] 检查项目中使用 new worker.ThreadWorker 的位置，确认是否有对应的 terminate 调用。
   [ ] 检查 Worker 内部捕获异常时， onerror 回调是否同样触发了 terminate。
   [ ] 检查 Native C++ 侧 pthread / std::thread 是否正常 detach 或 join，避免产生僵尸线程。

4. Native 内存排查清单：
   [ ] 检查所有 napi_wrap 调用，确认第 4 个参数（napi_finalize）是否传入了有效的清理回调。
   [ ] 在 DevEco Profiler 中导入 Trace/Snapshot，查看 Call Trees 中 Native 堆的 Live Bytes 是否呈增长趋势。
   [ ] 检查 C++ 侧全局单例或 Cache 容器是否有最大容量上限和淘汰清理机制。

八、总结

应用稳定性是衡量高质量鸿蒙应用的核心指标。资源泄漏问题隐蔽性强，往往需要长稳测试与深入底层分析相结合才能彻底解决。

在实际开发中，建立严谨的代码规范是防范资源泄漏的第一道防线——使用 try...finally 保护文件资源，合理管控 Worker 线程生命周期，并在 Native 交互层严格绑定 napi_add_finalizer。当出现稳定性风险时，借助 DevEco Testing 进行自动化压测抓取日志，并结合 DevEco Profiler 的 Call Trees 功能精准寻找未释放资源源头，即可高效完成稳定性排查与修复。

你在 HarmonyOS 应用开发中是否也遇到过极其隐蔽的句柄或内存泄漏问题？欢迎在评论区分享你的排查经验与实用排查小技巧！

参考资料

1. 《HarmonyOS 文件管理开发指南 (ArkTS)》
   华为开发者联盟
   链接：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/file-management-overview

2. 《HarmonyOS Worker 多线程开发指南》
   华为开发者联盟
   链接：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/worker-introduction

3. 《Node-API 在 HarmonyOS 中的使用与内存生命周期管理》
   华为开发者联盟
   链接：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/use-napi-process-concepts

4. 《DevEco Profiler 性能调优与离线分析指南》
   华为开发者联盟
   链接：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/ide-profiler-overview

如果觉得有帮助，别忘了点个赞+关注支持一下~
喜欢记得关注，别让好内容被埋没～