如何用Web Locks API管理资源共享与并发访问？

夢幻星辰

发布时间：2025-09-22 09:17:01

994人浏览过

来源于php中文网

原创

Web Locks API通过navigator.locks.request()提供原生并发控制，解决跨上下文数据冲突问题。它支持exclusive（独占）和shared（共享）两种模式，分别用于写操作和读操作的协调，实现“多读单写”的高效同步。开发者可利用锁名称统一标识资源，结合options配置ifAvailable、steal和AbortSignal等行为，避免竞态条件与资源争用。相比localStorage事件或postMessage等手动方案，Web Locks具备原子性、自动释放、浏览器级可靠性等优势。典型应用场景包括全局状态更新、缓存读写、资源预加载等。使用时需警惕死锁、长时间持锁、错误处理缺失等问题，最佳实践包括缩小锁粒度、统一命名、避免嵌套锁、结合AbortSignal取消请求，并利用navigator.locks.query()进行调试监控，确保并发安全与系统稳定性。

如何用web locks api管理资源共享与并发访问？

在现代Web应用中，尤其当你的应用需要在多个浏览器标签页、Web Worker甚至Service Worker之间协调工作时，管理共享资源和并发访问无疑是个老大难问题。简单来说，Web Locks API提供了一种原生的、标准化的方式，让你能够安全地锁定一个共享资源，确保在某个时刻只有一个（或特定数量的）代码段能够访问它，从而有效避免数据冲突和竞态条件。这就像给你的数据加了一把锁，只有拿到钥匙的人才能进去操作，大大简化了跨上下文同步的复杂性。

解决方案

使用Web Locks API的核心在于

navigator.locks.request()

方法。它是一个基于Promise的异步函数，允许你请求一个具名锁。当你成功获取到锁后，你的回调函数会被执行，而一旦回调函数执行完毕（无论是正常返回还是抛出错误），锁都会被自动释放。这机制在我看来，简直是开发者福音，省去了手动管理锁状态的繁琐。

基本的用法是这样的：

async function updateSharedCounter() {
  const lockName = 'my_shared_counter_lock';

  try {
    await navigator.locks.request(lockName, async lock => {
      // 成功获取到锁，现在可以安全地访问共享资源了
      console.log(`Lock '${lockName}' acquired.`);

      // 模拟一个耗时操作，例如从localStorage读取、修改、写入
      let count = parseInt(localStorage.getItem('shared_counter') || '0', 10);
      count++;
      localStorage.setItem('shared_counter', count.toString());
      console.log(`Counter updated to: ${count}`);

      // 锁会在这个异步操作完成后自动释放
      // 如果这里有其他异步操作，确保它们在锁的范围内完成
      await new Promise(resolve => setTimeout(resolve, 500)); // 模拟异步工作
    });
    console.log(`Lock '${lockName}' released.`);
  } catch (error) {
    // 请求锁失败或回调函数中出现错误
    console.error(`Failed to acquire or execute with lock '${lockName}':`, error);
  }
}

// 可以在多个标签页或worker中同时调用
updateSharedCounter();

navigator.locks.request()

接受两个主要参数：

```
name
```
：一个字符串，代表你想要锁定的资源名称。这是跨上下文同步的关键，所有试图锁定同一名称的请求都会相互协调。
```
callback
```
：一个异步函数，当锁被成功获取后，这个函数会被执行。锁的生命周期与这个函数的执行周期绑定。
```
options
```
（可选）：一个配置对象，可以指定锁的模式（
```
exclusive
```
或
```
shared
```
）、行为（
```
ifAvailable
```
、
```
steal
```
）以及一个
```
AbortSignal
```
。

模式选择上，

exclusive

（默认）意味着一次只有一个请求可以持有这个锁；而

shared

模式则允许多个请求同时持有锁，但任何

exclusive

模式的请求都会被阻塞，直到所有

shared

锁都被释放。这是一个非常巧妙的设计，允许“多读单写”的场景。

// 带有选项的请求示例
async function tryUpdateCounterConditionally() {
  const lockName = 'my_shared_counter_lock';
  const options = {
    mode: 'exclusive',
    ifAvailable: true // 如果锁不可用，则立即拒绝，而不是等待
  };

  try {
    const lock = await navigator.locks.request(lockName, options, async lock => {
      console.log(`Conditionally acquired lock '${lockName}'.`);
      // ... 执行操作 ...
    });

    if (!lock) {
      console.log(`Lock '${lockName}' was not available, skipping update.`);
    }
  } catch (error) {
    console.error(`Error during conditional lock request:`, error);
  }
}

值得一提的是，你还可以通过

navigator.locks.query()

方法来查看当前活跃的锁和处于待定状态的锁，这对于调试和理解应用中的并发行为非常有帮助。

Web Locks API如何解决传统并发访问的痛点？

在我看来，Web Locks API的出现，简直是对Web并发编程领域的一次“降维打击”。过去，我们为了在不同浏览器标签页或Worker之间同步状态，简直是绞尽脑汁，各种土法炼钢。你可能尝试过利用

localStorage

的事件监听来通知其他上下文，或者在

IndexedDB

事务中模拟锁，甚至更复杂的基于

postMessage

的消息队列机制。这些方案，无一例外，都伴随着高昂的开发成本、潜在的竞态条件以及难以调试的“幽灵Bug”。

想想看，手动管理一个全局的“忙碌”状态，需要确保所有操作都正确地设置和清除了这个状态，一旦有任何遗漏，数据不一致就可能发生。而且，这些自定义方案往往缺乏原子性，一个复杂的操作可能被中断，留下一个半成品的数据状态。Web Locks API则不然，它是由浏览器底层提供的原生能力，天生就具备原子性、可靠性和跨上下文的可见性。你不需要再担心某个标签页崩溃导致锁永远不释放（浏览器会自动处理），也不用编写大量的样板代码来协调消息。它把并发控制的复杂性封装起来，暴露一个简洁的API，让我们能更专注于业务逻辑本身，而不是与底层机制搏斗。这就像从自己造轮子，直接升级到了使用汽车厂商提供的标准组件，效率和稳定性都不可同日而语。

在实际开发中，Web Locks API的

exclusive

与

shared

模式有何应用场景？

exclusive

和

shared

这两种模式，在我看来，是Web Locks API最精妙的设计之一，它们完美契合了“读多写少”和“独占写入”这两种最常见的并发场景。

exclusive

模式（独占锁）的应用场景：

更新关键配置或状态： 假设你的应用有一个全局配置对象存储在

localStorage

或

IndexedDB

中，多个标签页可能会尝试修改它。使用

exclusive

锁可以确保在任何给定时间只有一个标签页能进行修改，防止配置被覆盖或损坏。

// 示例：独占更新用户偏好设置
async function updateUserSettings(newSettings) {
  await navigator.locks.request('user_settings_lock', async () => {
    const currentSettings = JSON.parse(localStorage.getItem('userSettings') || '{}');
    const mergedSettings = { ...currentSettings, ...newSettings };
    localStorage.setItem('userSettings', JSON.stringify(mergedSettings));
    console.log('User settings updated exclusively.');
  });
}

执行一次性的、资源密集型任务： 例如，一个Web Worker负责从服务器下载大量数据并缓存到
```
IndexedDB
```
。你可能希望只有一个Worker实例执行这个下载和缓存过程，避免重复下载和资源浪费。
跨标签页的UI同步： 当一个用户操作需要在多个标签页中产生同步的UI效果时（例如，用户在一个标签页中登出，所有其他标签页也应立即登出），
```
exclusive
```
锁可以用来确保登出逻辑的原子性执行，并通知所有相关上下文。

shared

模式（共享锁）的应用场景：

缓存读取与更新： 这是

shared

模式最典型的应用。多个标签页可以同时从一个共享缓存（例如，

IndexedDB

中的数据）中读取数据，而不会相互阻塞。但是，当需要更新这个缓存时，就需要一个

exclusive

锁。

// 示例：共享读取缓存，独占更新缓存
async function readFromCache(key) {
  let data = null;
  await navigator.locks.request('data_cache_lock', { mode: 'shared' }, async () => {
    data = localStorage.getItem(`cache_${key}`);
    console.log(`Read from cache (shared): ${key}`);
  });
  return data;
}

async function updateCache(key, value) {
  await navigator.locks.request('data_cache_lock', { mode: 'exclusive' }, async () => {
    localStorage.setItem(`cache_${key}`, value);
    console.log(`Updated cache (exclusive): ${key}`);
  });
}

// 多个标签页可以同时调用 readFromCache
// 只有一个标签页可以调用 updateCache，当 updateCache 运行时，所有 readFromCache 都会被阻塞

资源预加载状态管理： 多个页面可能都需要同一个大型资源（如一个WebAssembly模块或大型图片）。
```
shared
```
锁可以表示资源正在被使用，而
```
exclusive
```
锁可以在资源需要被重新下载或更新时使用。

Contentfries
将长视频改造成更加引人注目的短视频

下载
日志记录： 多个上下文可以同时向一个共享的日志存储写入日志，但如果需要执行一个日志归档或清理的特殊操作，则可能需要一个
```
exclusive
```
锁来确保操作的完整性。

这种读写分离的模式，在我看来，极大地提高了并发系统的效率，因为它允许并发读取，只在真正需要修改数据时才引入独占阻塞，这在Web应用中非常常见。

使用Web Locks API时，有哪些常见的陷阱和最佳实践？

Web Locks API虽然强大，但并非万能药，使用不当同样会引入新的问题。在我有限的经验中，以下几点是需要特别注意的：

常见陷阱：

死锁（Deadlock）： 这是并发编程的经典难题。如果你在不同的上下文中以不同的顺序请求多个锁，就可能发生死锁。例如，标签A请求锁X，然后请求锁Y；标签B请求锁Y，然后请求锁X。如果两者同时发生，A可能持有X并等待Y，B持有Y并等待X，导致双方都无法继续。
长时间持有锁： 锁的目的是保护临界区。如果你的回调函数中包含了耗时很长的同步操作，或者不必要的异步等待，那么锁就会被长时间持有，严重影响其他上下文的性能和响应性。
误解
ifAvailable
和
steal
选项：
```
ifAvailable: true
```
会使
```
request
```
方法立即返回
```
null
```
如果锁不可用，而不是等待。这适用于非关键的、可以跳过的操作。而
```
steal: true
```
则更为激进，它会强制获取锁，即使当前有其他上下文持有该锁。这会中断其他上下文的操作，导致数据不一致或错误，务必慎用，除非你明确知道自己在做什么。
忽略错误处理：
```
navigator.locks.request()
```
返回的是一个Promise，它可能会因为各种原因（如
```
AbortSignal
```
被触发、浏览器内部错误）而拒绝。不进行适当的
```
try...catch
```
处理，可能导致未捕获的错误。

最佳实践：

保持锁的粒度尽可能小，持有时间尽可能短： 只在真正需要保护共享资源的代码块中使用锁，并且一旦操作完成，就让锁自动释放。避免在锁的回调函数中执行与共享资源无关的、耗时的操作。
统一命名约定： 为你的锁选择清晰、一致的名称。所有需要协调访问某个资源的上下文，都必须使用完全相同的锁名称。一个好的做法是使用模块名或资源路径作为锁名称的一部分。
避免嵌套锁，或确保一致的锁请求顺序： 如果你确实需要获取多个锁，请确保在所有上下文中都以相同的顺序请求它们，这是避免死锁的关键策略。

利用

AbortSignal

：对于那些可能被用户取消或不再需要的操作，你可以传入一个

AbortSignal

到

request

方法的选项中。当

AbortSignal

被触发时，如果锁还在等待队列中，请求就会被取消，避免不必要的等待。

const controller = new AbortController();
const signal = controller.signal;

// 某个事件触发时，取消锁请求
// controller.abort();

navigator.locks.request('cancellable_task_lock', { signal }, async () => {
  // ... 任务逻辑 ...
}).catch(error => {
  if (error.name === 'AbortError') {
    console.log('Lock request was aborted.');
  } else {
    console.error('Lock request failed:', error);
  }
});

结合Web Workers： 即使使用了Web Locks API，长时间运行或计算密集型任务仍然应该在Web Worker中执行，以避免阻塞主线程，确保用户界面的响应性。锁可以用于协调Worker与主线程之间，或不同Worker之间的共享数据访问。
监控与调试： 使用
```
navigator.locks.query()
```
来检查当前活跃和待定的锁状态。这对于理解并发行为、诊断性能瓶颈或死锁问题非常有帮助。