鸿蒙-阻塞式文件锁

最新推荐文章于 2026-03-10 13:25:24 发布

原创

最新推荐文章于 2026-03-10 13:25:24 发布 · 1.4k 阅读

标签

#harmonyos #华为

一、背景

最近在做鸿蒙版本的埋点SDK，涉及到多线程同步问题。我们都知道多线程存在并发问题（多线程同步和互斥的问题）。今天我介绍一下我在鸿蒙项目中，使用ArkTS的API实现阻塞式的同步锁，来确保线程安全。

在进入正文之前，我先介绍一下鸿蒙系统的并发基础设施，大概分为如下三类：

并发名称	特点	应用场景
TaskPool	短时间任务	网络上传、文件写入(线程来源于线程池) 任务无法和固定的线程绑定
Worker	单开一个线程	可以做一些长的、周期性任务（类似于Java中new Thread）
Native	–	使用C/C++ , 利用NAPI

需要注意的是TaskPool、Worker是鸿蒙ArkTs SDK提供的API，这两种线程(轻量级进程) 之间是内存隔离, 只能够通过特定的API传递一些@Sendable的数据，不能够通过 **变量(引用)**的方式直接访问。

鸿蒙的ArkTS SDK中，提供了 文件管理的API, 其中关于锁的API有：

并发名称	特点
lock(exclusive?: boolean): Promise	文件阻塞式施加共享锁或独占锁，使用Promise异步返回
lock(exclusive?: boolean, callback: AsyncCallback): void	文件阻塞式施加共享锁或独占锁，使Callback异步回调。
tryLock(exclusive?: boolean): void	文件非阻塞式施加共享锁或独占锁
unlock(): void	以同步方式给文件解锁。

上述的API，已经非常丰富了，几乎可以满足所有的开发需求。但是我的情况比较特殊： 我期望的是我的线程通过tryLock去获取互斥锁，如果没有获取到就一直轮训。

你可能会有疑问： lock(exclusive?: boolean): Promise + await 不正好能够满足需求吗？是的，如果确实可以，但是这在鸿蒙当中有一个前提：是需要调用代码块是异步的(方法被async修饰)。这一点我不期望的。

在这里插入图片描述
如上图所示，线程一和线程二同时访问cache.lock的文件锁，获得锁之后，然后对journal文件操作，以确保journal文件内容的完整性和可靠性。

同步代码通过轮训实现的同步锁：

import fs from '@ohos.file.fs';
import {