JavaScript内核与高级编程之：`JavaScript` 的 `Web Locks` API：如何在同源的不同 `tab` 中实现原子操作。

大家好，欢迎来到今天的“JavaScript内核与高级编程”小课堂。今天我们要聊点刺激的——如何在同源的不同标签页（tabs）里，实现原子操作，也就是传说中的“Web Locks API”。

这玩意儿听起来高大上，其实就是个“锁”，就像你家门上的锁一样。不过，它是给浏览器标签页用的，确保同一时间只有一个标签页能修改某个共享资源，避免数据冲突，保证数据的一致性。

先别打瞌睡，咱们用个生动的例子来引入。

想象一下，你和你的小伙伴都在网上抢购限量版球鞋。如果你们同时点击了“购买”按钮，系统怎么知道该把鞋子给谁呢？如果没有“锁”，很可能你们都以为自己抢到了，结果只有一个幸运儿，剩下的人只能哭晕在厕所。Web Locks API 就是来解决这类问题的。

一、什么是 Web Locks API？

Web Locks API 允许你在浏览器中获取和释放锁。这个锁是针对特定资源的，例如一个特定的文件名或者一个简单的字符串标识符。同源（same origin）的不同标签页可以竞争同一个锁，只有一个标签页能成功获取锁，其他的标签页会被阻塞，直到锁被释放。

简单来说，它提供了以下功能：

• 请求锁（navigator.locks.request()）: 尝试获取一个锁。可以指定锁的名称、模式（独占或共享）、以及回调函数。
• 查询锁（navigator.locks.query()）: 查看当前有哪些锁正在被持有，以及哪些锁在等待。
• 锁的释放（自动或手动）: 当回调函数执行完毕，锁会自动释放；也可以手动释放锁。

二、Web Locks API 的基本用法

现在我们来看看怎么用这个锁。

// 定义锁的名称
const lockName = 'my-resource';

// 请求一个独占锁
navigator.locks.request(lockName, { mode: 'exclusive' }, async (lock) => {
  if (lock) {
    console.log('成功获取锁！');

    // 在这里执行你的原子操作
    try {
      // 模拟一个耗时操作
      await new Promise(resolve => setTimeout(resolve, 2000));
      console.log('操作完成！');
    } catch (error) {
      console.error('操作失败：', error);
    } finally {
      console.log('锁已自动释放！');
    }

    // 返回一个 Promise，锁会在 Promise resolve 或 reject 时自动释放
    return Promise.resolve(); // 或者 Promise.reject(new Error('Something went wrong'));
  } else {
    console.log('未能获取锁，可能已被其他标签页占用。');
  }
});

这段代码做了什么呢？

1. lockName: 定义了锁的名称，也就是你要保护的资源的名字。
2. navigator.locks.request(lockName, { mode: 'exclusive' }, async (lock) => { ... }): 这是核心。它尝试请求一个名为 my-resource 的独占锁。mode: 'exclusive' 表示这是一个独占锁，同一时间只能有一个标签页持有。
3. async (lock) => { ... }: 这是一个回调函数，只有当成功获取锁的时候才会执行。lock 参数是一个 Lock 对象，如果获取锁失败，lock 的值是 null。
4. if (lock) { ... }: 检查是否成功获取锁。
5. await new Promise(resolve => setTimeout(resolve, 2000));: 模拟一个耗时操作，比如读取或写入数据库。
6. return Promise.resolve();: 返回一个Promise，锁会在Promise resolve 或 reject 时自动释放。

重要的点：

• navigator.locks.request() 返回一个 Promise，但是回调函数返回的 Promise 才真正控制锁的生命周期。只有当回调函数返回的 Promise resolve 或者 reject 的时候，锁才会被释放。
• 如果在回调函数中抛出异常，锁也会被释放。
• 如果标签页被关闭，锁也会被自动释放。

三、锁的模式：独占锁 vs 共享锁

Web Locks API 提供了两种锁模式：

• 独占锁（exclusive）: 同一时间只能有一个标签页持有。适用于写操作，比如修改数据。
• 共享锁（shared）: 可以被多个标签页同时持有。适用于读操作，比如读取数据。

// 请求一个共享锁
navigator.locks.request(lockName, { mode: 'shared' }, async (lock) => {
  if (lock) {
    console.log('成功获取共享锁！');

    // 在这里执行你的读操作
    try {
      // 模拟读取操作
      const data = await fetchData();
      console.log('读取到的数据：', data);
    } catch (error) {
      console.error('读取数据失败：', error);
    } finally {
      console.log('共享锁已自动释放！');
    }

    return Promise.resolve();
  } else {
    console.log('未能获取共享锁，可能已有独占锁被持有。');
  }
});

什么时候用独占锁？什么时候用共享锁？

用表格说话：

锁模式	用途	适用场景
独占锁	写操作，修改数据	需要保证数据一致性的场景，例如更新数据库
共享锁	读操作，读取数据	允许多个客户端同时读取数据的场景

四、使用场景举例

除了抢购球鞋，Web Locks API 还有很多其他的应用场景：

• 防止重复提交表单: 用户在提交表单后，如果快速刷新页面或者点击多次提交按钮，可能会导致重复提交。可以使用 Web Locks API 确保同一时间只有一个请求被处理。
• 协同编辑: 多个用户同时编辑同一个文档时，可以使用 Web Locks API 避免冲突。
• 文件同步: 在多个标签页中同步文件数据，可以使用 Web Locks API 确保数据一致性。
• 缓存更新: 当缓存过期时，只有一个标签页可以负责更新缓存，防止多个标签页同时更新导致数据不一致。

五、Web Locks API 的高级用法

除了基本用法，Web Locks API 还有一些高级用法，可以让你更灵活地控制锁的行为。

1. 手动释放锁:

let myLock;

navigator.locks.request('my-resource', { mode: 'exclusive' }, async (lock) => {
  if (lock) {
    myLock = lock; // 保存锁对象
    console.log('成功获取锁！');

    // 执行一些操作
    await doSomething();

    // 手动释放锁
    myLock.release();
    console.log('手动释放锁！');
  } else {
    console.log('未能获取锁。');
  }
});

async function doSomething() {
  await new Promise(resolve => setTimeout(resolve, 2000));
  console.log('操作完成！');
}

注意：

• 要手动释放锁，需要先保存 Lock 对象。
• 手动释放锁后，回调函数返回的 Promise 不再控制锁的生命周期。
• 如果手动释放锁后，回调函数返回的 Promise 仍然没有 resolve 或 reject，可能会导致一些问题。建议手动释放锁后，立即 resolve 或 reject 回调函数返回的 Promise。
• 不建议手动释放锁，除非你有非常明确的需求。让锁自动释放通常更安全。

2. 查询锁的状态:

navigator.locks.query().then(locks => {
  console.log('当前锁的状态：', locks);

  locks.held.forEach(lock => {
    console.log('持有的锁：', lock.name, lock.mode);
  });

  locks.pending.forEach(lock => {
    console.log('等待的锁：', lock.name, lock.mode);
  });
});

navigator.locks.query() 返回一个 Promise，resolve 的值是一个 LockManagerSnapshot 对象，包含以下属性：

*   `held`:  一个数组，包含当前被持有的锁的信息。
*   `pending`:  一个数组，包含当前正在等待的锁的信息。

3. 锁的优先级:

   Web Locks API 没有明确的锁优先级概念，但是可以通过一些技巧来实现类似的效果。例如，可以使用一个时间戳来标记请求锁的时间，然后让回调函数检查当前是否有更早的请求正在等待，如果有，则主动释放锁，让更早的请求先执行。

六、Web Locks API 的兼容性

Web Locks API 的兼容性还不是很好，需要注意：

• Chrome 84+
• Edge 84+
• Firefox 不支持 (截至 2023 年底)
• Safari 不支持 (截至 2023 年底)

在使用 Web Locks API 之前，最好先检查浏览器是否支持：

if ('locks' in navigator) {
  console.log('Web Locks API is supported!');
} else {
  console.log('Web Locks API is not supported.');
  // 使用其他的解决方案，例如 localStorage 或 IndexedDB
}

如果浏览器不支持 Web Locks API，你可以使用其他的解决方案来模拟锁的功能，例如：

• localStorage: 可以使用 localStorage 来存储一个标志，表示资源是否被锁定。但是 localStorage 是同步的，可能会阻塞主线程。
• IndexedDB: 可以使用 IndexedDB 来存储锁的信息，并且可以使用事务来保证原子性。但是 IndexedDB 的 API 比较复杂。
• BroadcastChannel: 可以使用 BroadcastChannel 来在不同的标签页之间广播消息，协调锁的获取和释放。

七、Web Locks API 的一些注意事项

• 死锁: 要避免死锁的发生。死锁是指两个或多个标签页互相等待对方释放锁，导致程序无法继续执行。可以使用超时机制来避免死锁。
• 性能: Web Locks API 可能会影响性能，尤其是在高并发的场景下。要仔细评估其对性能的影响，并进行优化。
• 错误处理: 要处理锁的获取和释放过程中可能发生的错误，例如网络错误或者浏览器崩溃。
• 安全: Web Locks API 只能保证同源的标签页之间的互斥访问。不能防止来自不同源的恶意攻击。

八、总结

Web Locks API 是一个强大的工具，可以让你在浏览器中实现原子操作，保证数据的一致性。但是，它也有一些限制和注意事项。在使用 Web Locks API 之前，要仔细评估其适用性，并进行充分的测试。

总而言之，Web Locks API就像一把双刃剑，用得好，可以解决很多并发问题；用不好，可能会带来性能问题或者安全风险。所以，要谨慎使用，并且要不断学习和实践。

今天的“JavaScript内核与高级编程”小课堂就到这里。希望大家有所收获，也欢迎大家提出问题和建议。下次再见！