AppFreeze采样栈定位“锁竞争”，解决鸿蒙应用全局锁主线程等待

本原创文章帖发布在华为开发者联盟社区，欢迎开发者前往访问评论交流，更多与该内容相关讨论，请点击原帖查看：AppFreeze采样栈定位“锁竞争”，解决鸿蒙应用全局锁主线程等待-华为开发者话题 | 华为开发者联盟

本系列实战第一篇，我们将介绍“锁竞争”引发的冻屏问题。在鸿蒙应用开发中，使用 Worker 或 TaskPool 进行并行计算时，如果多个子线程竞争同一个全局锁，会导致子线程执行变慢，进而拖慢等待子线程的主线程，最终引发冻屏。本文将演示如何利用采样栈识别“频繁等锁”故障模式。

1. 问题现象

用户在触发某项业务操作后，应用界面出现明显卡死，随后进入无响应状态，系统最终强制退出应用。需要从系统生成的 AppFreeze 日志中，找出导致主线程卡死的根因。

2. 问题分析：从快照到采样

第一步：常规快照排查（初步诊断）

查看 AppFreeze 日志中的 THREAD_BLOCK_3S 和 THREAD_BLOCK_6S 主线程堆栈快照。

THREAD_BLOCK_3S 部分：

Tid:58244, Name:mainstate=R, utime=597, stime=24, priority=-54, nice=-10, clk=100#00 pc 00000000000018a4 [shmm](__kernel_gettimeofday+68)#01 pc 00000000001fdfac /system/lib/ld-musl-aarch64.so.1(gettimeofday+52)#02 pc 0000000000240024 /system/lib64/platformsdk/libark_jsruntime.so(panda::ecmascript::JSDate::Now()+40)#03 pc 0000000000e8b488 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#04 pc 000000000047dd94 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#05 at triggerFrequentLockWait entry (entry/src/main/ets/pages/OrderSubmit.ets:103:15)

复制代码

THREAD_BLOCK_6S 部分：

Tid:58244, Name:mainstate=S, utime=741, stime=24, priority=-54, nice=-10, clk=100#00 pc 00000000001f6bf8 /system/lib/ld-musl-aarch64.so.1(pthread_join+132)#01 pc 00000000000d3d34 /data/storage/el1/bundle/libs/arm64/libc++_shared.so(std::__n1::thread::join()+28)#02 pc 00000000000be8fc /data/storage/el1/bundle/libs/arm64/libentry.so(WaitThread(napi_env__*, napi_callback_info__*)+400)#03 pc 000000000005f6b8 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+240)#04 pc 0000000000e8b488 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#05 pc 000000000047dd94 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#06 at triggerFrequentLockWait entry (entry/src/main/ets/pages/OrderSubmit.ets:110:12)

复制代码

证据 1：两次堆栈不一致

深度解析：

1. 状态变化：从 R (Running) 变为 S (Sleep)，说明主线程从"正在执行"变成了"等待子线程"。

2. 堆栈不一致：3 秒时在执行业务逻辑，6 秒时在等待子线程。这表明主线程在繁忙执行中，但单凭两次快照无法判断哪个环节耗时最长。

3. 结论：常规快照只能看到"点"，看不到"面"。仅凭快照无法判断具体是哪个环节耗时过长，必须引入增强日志中的多帧采样统计来寻找"热点"。

第二步：深入挖掘（增强日志采样分析）

开启增强日志后，查看采样频率最高的关键栈帧序列（Top Hotspot）。在日志文件中搜索 FREEZE_EXT_INFO 关键字即可定位到增强日志部分。

证据 2：增强日志中的"热点"栈帧

[Hotspot #1] - Frequency:80% (8/10)，10 次栈帧出现了 8 次

#00 pc 00000000001f6bf4 /system/lib/ld-musl-aarch64.so.1(pthread_join+128)#01 pc 00000000000d3d34 /data/storage/el1/bundle/libs/arm64/libc++_shared.so(std::__n1::thread::join()+28)#02 pc 00000000000be8fc /data/storage/el1/bundle/libs/arm64/libentry.so(WaitThread(napi_env__*, napi_callback_info__*)+400)#03 pc 000000000005f6b8 /system/lib64/platformsdk/libace_napi.z.so(panda::JSValueRef ArkNativeFunctionCallBack<true>(panda::JsiRuntimeCallInfo*)+240)#04 pc 0000000000e8b488 /system/lib64/module/arkcompiler/stub.an(RTStub_PushCallArgsAndDispatchNative+40)#05 pc 000000000047dd94 /system/lib64/module/arkcompiler/stub.an(BCStub_HandleCallthis0Imm8V8StwCopy+396)#06 at triggerFrequentLockWait (entry|entry|1.0.0|src/main/ets/pages/OrderSubmit.ets:97:14)

复制代码

关键线索提取：

• 等锁特征：栈顶高频出现 pthread_join，这是线程等待子线程结束的典型符号，表明主线程大部分时间都在等待子线程完成。

• 业务层定位：明确指向 triggerFrequentLockWait（OrderSubmit.ets:97 行），这是问题的入口函数。

• 根因类型：频繁等锁（关键字：pthread_join、ld-musl-aarch64.so.1），属于"频繁等锁"故障模式。

第三步：锁定根因（代码审查）

根据日志定位到具体文件，查看源码。

证据 3：问题代码片段

// OrderSubmit.ets - Order submit pageimport { worker } from '@kit.ArkTS';function triggerFrequentLockWait() {  const THREAD_COUNT = 8;  let threads: Array<worker.ThreadWorker> = [];  for (let i = 0; i < THREAD_COUNT; i++) {    let threadWorker = new worker.ThreadWorker('entry/ets/workers/OrderProcessor.ets');    threads.push(threadWorker);  }  for (let i = 0; i < threads.length; i++) {    threads[i].start();  }  // Problem: main thread waits for all child threads to finish  for (let i = 0; i < threads.length; i++) {    threads[i].terminate(); // blocking main thread  }  showSuccessPage();}

复制代码

// OrderProcessor.ets - Child threadimport { worker } from '@kit.ArkTS';let globalMutex = new worker.Mutex();  // global lock, all child threads competelet sharedData: Array<OrderItem> = [];export function onMessage(message: MessageEvents) {  for (let i = 0; i < 1000; i++) {    globalMutex.lock();        // 8 child threads compete for the same lock    sharedData.push(processOrderItem());    globalMutex.unlock();  }  worker.postMessage({ type: 'completed' });}

复制代码

根因总结：

• 锁竞争激烈：8 个子线程循环 1000 次，共 8000 次锁操作，全部竞争同一个全局锁。锁争用导致子线程执行时间大幅拉长。

• 主线程阻塞：主线程通过 terminate() 等待所有子线程完成，被子线程的锁竞争拖累，长时间无法响应。

• 级联效应：锁竞争 -> 子线程执行变慢 -> 主线程等待时间变长 -> 应用冻屏。

3. 解决方案与实践案例

优化方案 1：缩小锁粒度（推荐）

核心思路：为每个子线程分配独立的数据，消除锁竞争。

// Optimized OrderProcessor.etsimport { worker } from '@kit.ArkTS';let threadLocalData: Map<number, Array<OrderItem>> = new Map();export function onMessage(message: MessageEvents) {  const workerId = message.data.workerId;  let localItems: Array<OrderItem> = [];  for (let i = 0; i < 1000; i++) {    // No lock needed, each child thread processes independent data    localItems.push(processOrderItem());  }  threadLocalData.set(workerId, localItems);  worker.postMessage({ type: 'completed', workerId: workerId });}// Main thread aggregates resultsfunction aggregateResults() {  let allItems: Array<OrderItem> = [];  for (let [workerId, items] of threadLocalData) {    allItems = allItems.concat(items);  }  return allItems;}

复制代码

优化方案 2：使用 TaskPool（鸿蒙官方推荐）

import taskpool from '@ohos.taskpool';@Concurrentfunction processOrderItemConcurrent(item: OrderItem): OrderItem {  let result = 0;  for (let i = 0; i < 1000; i++) {    result += Math.sqrt(i);  }  return { ...item, processed: true };}async function triggerFrequentLockWait() {  const items: Array<OrderItem> = generateOrderItems();  const tasks: Array<Promise<OrderItem>> = items.map(item => {    return taskpool.execute(processOrderItemConcurrent, item);  });  const results = await Promise.all(tasks);  showSuccessPage(results);}