Web Locks API：资源同步与并发访问控制

在现代 Web 开发领域，构建健壮且响应迅速的应用程序通常涉及管理共享资源和处理并发访问。当应用程序的多个部分，甚至是多个浏览器标签页或窗口，试图同时访问和修改相同的数据时，可能会发生竞态条件和数据损坏。Web Locks API 提供了一种同步访问这些资源的机制，确保数据完整性并防止意外行为。

理解资源同步的需求

设想一个场景：用户正在一个 Web 应用程序中编辑文档。可能同时打开了多个包含同一文档的浏览器标签页，或者应用程序有后台进程定期保存文档。如果没有适当的同步，一个标签页中所做的更改可能会被另一个标签页的更改覆盖，导致数据丢失和糟糕的用户体验。同样，在电子商务应用程序中，多个用户可能同时尝试购买库存中的最后一件商品。如果没有防止超卖的机制，可能会产生无法履行的订单，导致客户不满。

管理并发的传统方法，例如仅依赖服务器端锁定机制，可能会引入显著的延迟和复杂性。Web Locks API 提供了一种客户端解决方案，允许开发人员直接在浏览器内协调对资源的访问，从而提高性能并减少服务器负载。

Web Locks API 简介

Web Locks API 是一个 JavaScript API，允许您在 Web 应用程序中获取和释放对命名资源的锁。这些锁是排他性的，意味着在任何给定时间，只有一段代码可以持有特定资源的锁。这种排他性确保了访问和修改共享数据的关键代码段以受控且可预测的方式执行。

该 API 被设计为异步的，使用 Promise 来通知锁何时被获取或释放。这种非阻塞特性可防止 UI 在等待锁时冻结，确保了响应迅速的用户体验。

关键概念与术语

• 锁名称 (Lock Name): 一个标识受锁保护的资源的字符串。此名称用于获取和释放同一资源的锁。锁名称区分大小写。
• 锁模式 (Lock Mode): 指定请求的锁类型。API 支持两种模式：
• `exclusive` (默认): 一次只允许一个锁持有者。
• `shared`: 允许多个锁持有者同时存在，前提是没有其他持有者拥有该资源的排他锁。
• 锁请求 (Lock Request): 一个试图获取锁的异步操作。当锁成功获取时，请求会解析 (resolve)；如果无法获取锁（例如，因为另一段代码已持有排他锁），则会拒绝 (reject)。
• 锁释放 (Lock Release): 释放锁的操作，使其可供其他代码获取。

使用 Web Locks API：实践示例

让我们探讨一些如何在 Web 应用程序中使用 Web Locks API 同步资源访问的实际示例。

示例 1：防止并发文档编辑

想象一个协作文档编辑应用程序，多个用户可以同时编辑同一文档。为防止冲突，我们可以使用 Web Locks API 来确保在任何给定时间只有一个用户可以修改文档。

async function saveDocument(documentId, content) {
  try {
    await navigator.locks.request(documentId, async () => {
      // 关键代码段：将文档内容保存到服务器
      console.log(`已获取文档 ${documentId} 的锁。正在保存...`);
      await saveToServer(documentId, content);
      console.log(`文档 ${documentId} 已成功保存。`);
    });
  } catch (error) {
    console.error(`保存文档 ${documentId} 失败:`, error);
  }
}

async function saveToServer(documentId, content) {
  // 模拟保存到服务器（请替换为实际的 API 调用）
  return new Promise(resolve => setTimeout(resolve, 1000));
}

在此示例中，`saveDocument` 函数尝试使用文档的 ID 作为锁名称来获取文档的锁。`navigator.locks.request` 方法接受两个参数：锁名称和一个回调函数。该回调函数仅在成功获取锁后执行。在回调内部，文档内容被保存到服务器。当回调函数完成时，锁会自动释放。如果该函数的另一个实例尝试使用相同的 `documentId` 执行，它将等待直到锁被释放。如果发生错误，它将被捕获并记录下来。

示例 2：控制对 Local Storage 的访问

Local Storage 是浏览器中存储数据的常用机制。但是，如果应用程序的多个部分试图同时访问和修改 Local Storage，可能会发生数据损坏。Web Locks API 可用于同步对 Local Storage 的访问，确保数据完整性。

async function updateLocalStorage(key, value) {
  try {
    await navigator.locks.request('localStorage', async () => {
      // 关键代码段：更新 Local Storage
      console.log(`已获取 localStorage 的锁。正在更新键 ${key}...`);
      localStorage.setItem(key, value);
      console.log(`键 ${key} 已在 localStorage 中更新。`);
    });
  } catch (error) {
    console.error(`更新 localStorage 失败:`, error);
  }
}

在此示例中，`updateLocalStorage` 函数尝试获取 'localStorage' 资源的锁。然后，回调函数更新 Local Storage 中的指定键。该锁确保一次只有一段代码可以访问 Local Storage，从而防止竞态条件。

示例 3：在 Web Worker 中管理共享资源

Web Worker 允许您在后台运行 JavaScript 代码，而不会阻塞主线程。但是，如果 Web Worker 需要与主线程或其他 Web Worker 访问共享资源，同步是必不可少的。Web Locks API 可用于协调对这些资源的访问。

首先，在您的主线程中：

async function mainThreadFunction() {
    try {
        await navigator.locks.request('sharedResource', async () => {
            console.log('主线程已获取 sharedResource 的锁');
            // 访问和修改共享资源
            await new Promise(resolve => setTimeout(resolve, 2000)); // 模拟工作
            console.log('主线程正在释放 sharedResource 的锁');
        });
    } catch (error) {
        console.error('主线程获取锁失败:', error);
    }
}

mainThreadFunction();

然后，在您的 Web Worker 中：

self.addEventListener('message', async (event) => {
    if (event.data.type === 'accessSharedResource') {
        try {
            await navigator.locks.request('sharedResource', async () => {
                console.log('Web Worker 已获取 sharedResource 的锁');
                // 访问和修改共享资源
                await new Promise(resolve => setTimeout(resolve, 3000)); // 模拟工作
                console.log('Web Worker 正在释放 sharedResource 的锁');
                self.postMessage({ type: 'sharedResourceAccessed', success: true });
            });
        } catch (error) {
            console.error('Web Worker 获取锁失败:', error);
            self.postMessage({ type: 'sharedResourceAccessed', success: false, error: error.message });
        }
    }
});

在此示例中，主线程和 Web Worker 都尝试获取 `sharedResource` 的锁。`navigator.locks` 对象在 Web Worker 中可用，允许它们参与与主线程相同的锁定机制。消息用于在主线程和 worker 之间通信，触发获取锁的尝试。

锁模式：排他锁 (Exclusive) vs. 共享锁 (Shared)

Web Locks API 支持两种锁模式：`exclusive` 和 `shared`。锁模式的选择取决于您应用程序的具体要求。

排他锁 (Exclusive Locks)

排他锁授予对资源的独占访问权限。在任何给定时间，只有一段代码可以持有特定资源的排他锁。此模式适用于一次只应有一个进程能够修改资源的场景。例如，将数据写入文件、更新数据库记录或修改 UI 组件的状态。

以上所有示例都默认使用了排他锁。您无需指定模式，因为 `exclusive` 是默认值。

共享锁 (Shared Locks)

共享锁允许多段代码同时持有某个资源的锁，前提是没有其他代码持有该资源的排他锁。此模式适用于多个进程需要并发读取资源，但没有进程需要修改它的场景。例如，从文件读取数据、查询数据库或渲染 UI 组件。

要请求共享锁，您需要在 `navigator.locks.request` 方法中指定 `mode` 选项。

async function readData(resourceId) {
  try {
    await navigator.locks.request(resourceId, { mode: 'shared' }, async () => {
      // 关键代码段：从资源读取数据
      console.log(`已获取资源 ${resourceId} 的共享锁。正在读取...`);
      const data = await readFromResource(resourceId);
      console.log(`从资源 ${resourceId} 读取的数据:`, data);
      return data;
    });
  } catch (error) {
    console.error(`从资源 ${resourceId} 读取数据失败:`, error);
  }
}

async function readFromResource(resourceId) {
  // 模拟从资源读取（请替换为实际的 API 调用）
  return new Promise(resolve => setTimeout(() => resolve({ value: 'Some data' }), 500));
}

在此示例中，`readData` 函数请求指定资源的共享锁。此函数的多个实例可以并发执行，只要没有其他代码持有该资源的排他锁即可。

面向全球应用程序的考量

为全球受众开发 Web 应用程序时，考虑资源同步和并发访问控制在不同环境中的影响至关重要。

• 网络延迟: 高网络延迟会加剧并发问题的影响。服务器端锁定机制可能会引入显著延迟，导致用户体验不佳。Web Locks API 可以通过提供客户端解决方案来同步资源访问，从而帮助缓解此问题。
• 时区: 处理时间敏感数据（如安排事件或处理交易）时，必须考虑不同的时区。适当的同步机制有助于防止冲突并确保跨地理分布系统的数据一致性。
• 文化差异: 不同文化对数据访问和修改的期望可能不同。例如，某些文化可能优先考虑实时协作，而其他文化可能更喜欢异步方法。设计应用程序时，适应这些多样化的需求非常重要。
• 语言和本地化: Web Locks API 本身不直接涉及语言或本地化。但是，被同步的资源可能包含本地化内容。请确保您的同步机制与您的本地化策略兼容。

使用 Web Locks API 的最佳实践

• 保持关键代码段简短: 锁持有的时间越长，发生争用和延迟的可能性就越大。尽可能缩短访问和修改共享数据的关键代码段。
• 避免死锁: 当两个或多个代码段无限期地被阻塞，互相等待对方释放锁时，就会发生死锁。为避免死锁，请确保始终以一致的顺序获取和释放锁。
• 优雅地处理错误: 如果无法获取锁，`navigator.locks.request` 方法可能会拒绝 (reject)。请优雅地处理这些错误，向用户提供有用的反馈。
• 使用有意义的锁名称: 选择能清晰标识受保护资源的锁名称。这将使您的代码更易于理解和维护。
• 考虑锁的作用域: 确定锁的适当作用域。锁应该是全局的（跨所有浏览器标签页和窗口），还是应仅限于特定的标签页或窗口？Web Locks API 允许您控制锁的作用域。
• 彻底测试: 彻底测试您的代码，以确保它能正确处理并发并防止竞态条件。使用并发测试工具模拟多个用户同时访问和修改共享资源。

Web Locks API 的局限性

虽然 Web Locks API 为 Web 应用程序中的资源同步提供了强大的机制，但了解其局限性也很重要。

• 浏览器支持: 并非所有浏览器都支持 Web Locks API。在生产代码中使用该 API 之前，请检查浏览器兼容性。对于旧版浏览器，可能可以使用 Polyfill 提供支持。
• 持久性: 锁在浏览器会话之间不具有持久性。当浏览器关闭或刷新时，所有锁都会被释放。
• 非分布式锁: Web Locks API 仅在单个浏览器实例内提供同步。它不提供跨多台机器或服务器同步资源访问的机制。对于分布式锁，您需要依赖服务器端锁定机制。
• 协作式锁定: Web Locks API 依赖于协作式锁定。开发者有责任确保访问共享资源的代码遵守锁定协议。该 API 无法阻止代码在未首先获取锁的情况下访问资源。

Web Locks API 的替代方案

虽然 Web Locks API 为资源同步提供了宝贵的工具，但也存在几种替代方法，每种方法都有其优缺点。

• 服务器端锁定: 在服务器上实现锁定机制是管理并发的传统方法。这涉及使用数据库事务、乐观锁或悲观锁来保护共享资源。服务器端锁定为分布式并发提供了更健壮可靠的解决方案，但它可能会引入延迟并增加服务器负载。
• 原子操作: 一些数据结构和 API 提供原子操作，保证一系列操作作为单个不可分割的单元执行。这对于同步对简单数据结构的访问非常有用，而无需显式锁。
• 消息传递: 考虑使用消息传递在应用程序的不同部分之间进行通信，而不是共享可变状态。这种方法可以通过消除对共享锁的需求来简化并发管理。
• 不可变性 (Immutability): 使用不可变数据结构也可以简化并发管理。不可变数据在创建后无法修改，从而消除了发生竞态条件的可能性。

结论

Web Locks API 是一个在 Web 应用程序中同步资源访问和管理并发访问的宝贵工具。通过提供客户端锁定机制，该 API 可以提高性能、防止数据损坏并增强用户体验。然而，了解该 API 的局限性并适当使用它非常重要。在实现 Web Locks API 之前，请考虑您应用程序的具体要求、浏览器兼容性以及发生死锁的可能性。

通过遵循本指南中概述的最佳实践，您可以利用 Web Locks API 构建健壮且响应迅速的 Web 应用程序，从而在多样的全球环境中优雅地处理并发并确保数据完整性。