WebLocksAPI如何实现并发控制？

在现代Web应用中，尤其当应用需要在多个浏览器标签页、Web Worker甚至Service Worker之间协调工作时，管理共享资源和并发访问是关键挑战。Web Locks API提供了一种原生的、标准化的并发控制方案，通过`navigator.locks.request()`方法，允许开发者安全地锁定共享资源，避免数据冲突和竞态条件。它支持`exclusive`（独占）和`shared`（共享）两种模式，分别适用于写操作和读操作的协调，实现“多读单写”的高效同步。开发者可以通过锁名称统一标识资源，结合`options`配置`ifAvailable`、`steal`和`AbortSignal`等行为，灵活应对各种并发场景。相比传统的`localStorage`事件或`postMessage`等手动方案，Web Locks API具备原子性、自动释放和浏览器级可靠性等显著优势，广泛应用于全局状态更新、缓存读写和资源预加载等领域。然而，使用时需警惕死锁、长时间持锁和错误处理缺失等问题，遵循缩小锁粒度、统一命名、避免嵌套锁和结合`AbortSignal`取消请求等最佳实践，并利用`navigator.locks.query()`进行调试监控，才能确保并发安全和系统稳定性。

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

在现代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()接受两个主要参数：

1. name：一个字符串，代表你想要锁定的资源名称。这是跨上下文同步的关键，所有试图锁定同一名称的请求都会相互协调。
2. callback：一个异步函数，当锁被成功获取后，这个函数会被执行。锁的生命周期与这个函数的执行周期绑定。
3. 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锁可以在资源需要被重新下载或更新时使用。

• 日志记录： 多个上下文可以同时向一个共享的日志存储写入日志，但如果需要执行一个日志归档或清理的特殊操作，则可能需要一个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()来检查当前活跃和待定的锁状态。这对于理解并发行为、诊断性能瓶颈或死锁问题非常有帮助。

总而言之，Web Locks API是一个强大的工具，它极大地简化了Web平台上的并发控制。但就像任何强大的工具一样，理解其工作原理、潜在风险并遵循最佳实践，才能真正发挥它的价值，构建出健壮、高效的Web应用。

本篇关于《WebLocksAPI如何实现并发控制？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！