发布于 由admin

WebLocks API 与底层操作系统互斥量：实现浏览器多进程间的资源竞态管理与死锁预防算法

各位同学、各位开发者，欢迎来到今天的讲座。我们将深入探讨一个在现代Web应用开发中日益重要的话题：WebLocks API 与底层操作系统互斥量。我们将分析它们如何协同作用，共同解决浏览器多进程架构下复杂的资源竞态管理问题，并学习如何有效地预防死锁。

随着Web技术的发展，浏览器不再仅仅是文档阅读器，而是承载着复杂交互和大量数据处理的“操作系统”。现代浏览器普遍采用多进程架构，例如Chrome浏览器就有主进程（Browser Process）、渲染进程（Renderer Process）、GPU进程、插件进程、Service Worker进程等。这种架构带来了诸多优势，如更高的安全性、稳定性（一个渲染进程崩溃不会影响整个浏览器）以及更好的性能隔离。然而，随之而来的挑战便是如何在这些独立的进程之间安全、高效地共享和访问资源。

想象一下，如果多个浏览器标签页或Web Worker试图同时修改用户的本地存储数据，或者对同一个IndexedDB数据库进行写入，如果没有适当的同步机制，就可能导致数据损坏、不一致，甚至更严重的程序错误——这就是我们常说的“竞态条件”（Race Condition）。为了解决这些问题，Web平台引入了 WebLocks API，它为Web开发者提供了一种标准化的、跨Tab、跨Worker的互斥机制。

一、操作系统互斥量：同步的基石

在深入WebLocks API之前，我们有必要回顾一下计算机科学中最基础也是最重要的同步原语之一：操作系统互斥量（Mutex）。理解它的工作原理，能帮助我们更好地把握WebLocks API的本质和它所解决的问题。

1.1 什么是互斥量？

互斥量（Mutual Exclusion Lock，简称Mutex）是操作系统提供的一种同步机制，用于确保同一时间只有一个线程或进程可以访问某个特定的共享资源。它就像一把锁：当一个线程/进程需要访问共享资源时，它必须先尝试“获取”这把锁；如果锁是可用的，它就成功获取并进入“临界区”（Critical Section），执行对共享资源的操作；操作完成后，它必须“释放”这把锁，以便其他等待的线程/进程可以获取。如果锁已被其他线程/进程持有，那么尝试获取锁的线程/进程将被阻塞（等待），直到锁被释放。

1.2 互斥量的工作原理

互斥量通过两种基本操作实现其功能：

  • 加锁 (Lock/Acquire)：尝试获取互斥量。如果成功，则持有锁；如果失败（锁已被持有），则通常会阻塞当前执行流。
  • 解锁 (Unlock/Release)：释放互斥量。这会唤醒一个或多个等待该互斥量的线程/进程。

互斥量的实现依赖于底层硬件的原子操作指令，例如Test-and-Set或Compare-and-Swap (CAS)。这些指令能够在一个不可中断的步骤中完成读取、修改和写入内存的操作，从而避免在多核处理器环境下出现竞态条件。

1.3 用户态与内核态互斥量

互斥量可以分为用户态互斥量和内核态互斥量。

  • 用户态互斥量：在用户空间完成加锁和解锁操作，避免了系统调用的开销。例如，自旋锁（Spinlock）在尝试获取锁失败时，会持续循环检查锁的状态，直到锁可用，这在锁持有时间非常短的场景下效率较高，但会浪费CPU周期。
  • 内核态互斥量：当用户态互斥量无法获取锁时，会通过系统调用进入内核，由操作系统将当前线程/进程置于等待状态，直到锁可用时再被唤醒。这避免了CPU的忙等，但系统调用本身有上下文切换的开销。大多数高级互斥量（如pthread_mutex_t）结合了这两种机制，先尝试用户态自旋，失败后再进入内核态阻塞。

1.4 进程间互斥 (IPC Mutex)

标准的线程互斥量（如pthread_mutex_t）通常只在单个进程内的多线程之间有效。对于不同进程间的互斥，操作系统提供了更高级的“进程间互斥量”（IPC Mutex），也常称为“命名互斥量”或“文件锁”。这些机制通常通过共享内存、文件系统或特定的IPC原语来实现。例如，在Unix-like系统中，可以使用semaphores或flock；在Windows中，可以使用CreateMutex创建命名互斥量。

1.5 C/C++ 示例：pthread_mutex_t (概念性)

虽然WebLocks API是用JavaScript编写的，但理解底层互斥量的概念有助于我们理解其语义。以下是一个C语言使用pthread_mutex_t的示例，展示了线程内互斥的基本模式：

#include <stdio.h>
#include <pthread.h>
#include <unistd.h> // For sleep

pthread_mutex_t my_mutex; // 定义一个互斥量
int shared_resource = 0;   // 共享资源

// 线程函数
void* thread_function(void* arg) {
    for (int i = 0; i < 5; ++i) {
        // 尝试获取锁
        pthread_mutex_lock(&my_mutex);

        // 临界区：访问共享资源
        int temp = shared_resource;
        printf("Thread %ld read: %dn", (long)arg, temp);
        temp++;
        sleep(1); // 模拟耗时操作
        shared_resource = temp;
        printf("Thread %ld wrote: %dn", (long)arg, shared_resource);

        // 释放锁
        pthread_mutex_unlock(&my_mutex);

        sleep(1); // 模拟其他操作
    }
    return NULL;
}

int main() {
    // 初始化互斥量
    pthread_mutex_init(&my_mutex, NULL);

    pthread_t tid1, tid2;

    // 创建两个线程
    pthread_create(&tid1, NULL, thread_function, (void*)1);
    pthread_create(&tid2, NULL, thread_function, (void*)2);

    // 等待线程结束
    pthread_join(tid1, NULL);
    pthread_join(tid2, NULL);

    // 销毁互斥量
    pthread_mutex_destroy(&my_mutex);

    printf("Final shared_resource value: %dn", shared_resource);

    return 0;
}

在这个例子中，my_mutex确保了shared_resource在任何时候都只被一个线程修改，从而避免了竞态条件。

二、WebLocks API：浏览器层面的互斥抽象

WebLocks API（navigator.locks）是Web平台为解决浏览器多进程（包括不同Tab页、Web Worker、Service Worker等）间的资源同步问题而设计的标准化接口。它提供了一种声明式的、Promise-based的机制来管理对共享资源的访问。

2.1 WebLocks API 的核心概念

WebLocks API 的核心是 navigator.locks.request() 方法。

navigator.locks.request(name, [options,] callback)
  • name (字符串)：锁的名称。这是最关键的部分，因为它是识别和协调不同请求的关键。所有试图获取同名锁的请求都会被管理。锁名是区分大小写的。
  • options (可选对象)：用于配置锁的行为。
    • mode (字符串，默认 ‘exclusive’)：锁的模式。
      • 'exclusive' (独占锁)：同一时间只有一个请求可以持有此锁。
      • 'shared' (共享锁)：允许多个共享请求同时持有此锁，但任何独占锁请求都必须等待所有共享锁释放，反之亦然。
    • signal (AbortSignal 对象)：允许外部中止锁请求。如果信号触发，请求会被拒绝。
    • ifAvailable (布尔值，默认 false)：如果设置为 true，则请求锁时如果锁不可用，不会等待，而是立即拒绝Promise。这使得可以非阻塞地尝试获取锁。
    • steal (布尔值，默认 false)：如果设置为 true 并且锁已被持有，则会强制“窃取”锁，原持有者会立即失去锁并被拒绝其Promise。这是一个强大的功能，应谨慎使用，主要用于恢复或优先级更高的任务。
  • callback (异步函数)：当成功获取锁后，会执行此函数。此函数必须返回一个Promise，或者是一个同步函数。当此函数（或其返回的Promise）完成时，锁会自动释放。

2.2 锁的生命周期与自动释放

WebLocks API的一个重要特性是它的自动释放机制。当callback函数执行完毕（无论是正常返回、Promise解决，还是抛出错误、Promise拒绝），锁都会自动释放。这大大简化了锁的管理，减少了忘记释放锁导致死锁或资源泄露的风险。

2.3 WebLocks API 与底层 OS 互斥量的关系

WebLocks API 并非直接暴露操作系统互斥量给JavaScript。相反，它是浏览器引擎在用户空间对底层操作系统进程间通信（IPC）机制的抽象和封装。

浏览器内部通常会使用以下一种或多种底层机制来实现WebLocks的跨进程语义：

  • 命名互斥量 (Named Mutexes)：操作系统提供的命名互斥量可以直接用于跨进程同步。
  • 文件锁 (File Locks)：在某些操作系统上，可以通过对一个特定文件加锁来实现进程间互斥。
  • 共享内存 + 信号量 (Shared Memory + Semaphores)：浏览器进程可能维护一块共享内存，其中包含锁的状态信息，并通过信号量机制来协调对这块共享内存以及实际资源的访问。
  • 中央协调服务 (Central Coordination Service)：在多进程浏览器架构中，通常有一个主进程或某个专门的协调进程负责管理所有子进程的锁请求，它通过内部IPC机制与子进程通信。当一个子进程请求WebLock时，请求会发送给这个协调进程，由它来决定谁获得锁，并通知相应的子进程。

因此，我们可以将WebLocks API理解为Web平台提供的一层高级抽象，它使得Web开发者无需关心底层操作系统的复杂性，就能实现可靠的进程间互斥。它将“锁”的概念从“线程”扩展到了“Web上下文”（Tab、Worker）。

2.4 JavaScript 代码示例

2.4.1 独占锁 (Exclusive Lock)

独占锁是WebLocks API最常用的模式，它确保在任何给定时间只有一个上下文可以持有特定名称的锁。

async function updateSharedResource(resourceName, newValue) {
    console.log(`[${Date.now()}] 尝试获取独占锁：${resourceName}`);
    try {
        await navigator.locks.request(resourceName, async (lock) => {
            // lock 对象包含了锁的信息，例如 lock.name, lock.mode
            console.log(`[${Date.now()}] 成功获取独占锁：${resourceName}，进行资源更新...`);

            // 模拟耗时操作，例如写入 IndexedDB 或 localStorage
            await new Promise(resolve => setTimeout(resolve, Math.random() * 2000 + 500)); 

            // 假设这是我们的共享资源
            localStorage.setItem(resourceName, JSON.stringify(newValue));

            console.log(`[${Date.now()}] 资源 '${resourceName}' 更新为: ${JSON.stringify(newValue)}`);
            console.log(`[${Date.now()}] 独占锁 ${resourceName} 即将自动释放`);
        });
        console.log(`[${Date.now()}] 独占锁请求完成：${resourceName}`);
    } catch (error) {
        console.error(`[${Date.now()}] 获取独占锁或执行回调失败：${resourceName}`, error);
    }
}

// 在不同的Tab页或Worker中调用
// 假设Tab A 调用
updateSharedResource('my-app-config', { theme: 'dark', notifications: true });

// 假设Tab B 调用 (几乎同时)
updateSharedResource('my-app-config', { theme: 'light', notifications: false });

当两个Tab页几乎同时调用updateSharedResource('my-app-config', ...)时，WebLocks API会确保只有一个Tab能够进入回调函数执行对localStorage的修改，另一个Tab会等待，直到前一个Tab的锁被释放。

2.4.2 共享锁 (Shared Lock)

共享锁允许多个请求同时持有同一个锁，只要它们都是共享模式。但如果有一个独占锁请求，所有共享锁都必须释放，独占锁才能获取；反之，如果存在独占锁，任何共享锁请求都必须等待。

async function readSharedResource(resourceName) {
    console.log(`[${Date.now()}] 尝试获取共享锁：${resourceName}`);
    try {
        await navigator.locks.request(resourceName, { mode: 'shared' }, async (lock) => {
            console.log(`[${Date.now()}] 成功获取共享锁：${resourceName}，进行资源读取...`);

            // 模拟耗时读取操作
            await new Promise(resolve => setTimeout(resolve, Math.random() * 1000 + 200)); 

            const value = localStorage.getItem(resourceName);
            console.log(`[${Date.now()}] 资源 '${resourceName}' 读取到: ${value}`);
            console.log(`[${Date.now()}] 共享锁 ${resourceName} 即将自动释放`);
            return value; // 回调函数可以返回值
        });
        console.log(`[${Date.now()}] 共享锁请求完成：${resourceName}`);
    } catch (error) {
        console.error(`[${Date.now()}] 获取共享锁或执行回调失败：${resourceName}`, error);
    }
}

async function demonstrateSharedAndExclusive() {
    const resource = 'shared-data-cache';

    // 多个Tab/Worker同时读取（共享锁）
    readSharedResource(resource);
    readSharedResource(resource);
    readSharedResource(resource);

    // 几秒后，一个Tab/Worker尝试写入（独占锁）
    setTimeout(() => {
        updateSharedResource(resource, { status: 'updated', timestamp: Date.now() });
    }, 2000);

    // 更多的读取请求
    setTimeout(() => {
        readSharedResource(resource);
        readSharedResource(resource);
    }, 3000);
}

demonstrateSharedAndExclusive();

在此示例中，多个readSharedResource可以同时执行。但是，当updateSharedResource被调用时，它会请求一个独占锁，此时所有正在持有的共享锁必须先释放，updateSharedResource才能获得锁并执行，期间新的共享锁请求也会被阻塞。这是一种经典的“读写锁”模式。

2.4.3 非阻塞尝试 (ifAvailable)

有时我们不希望等待锁，而只是想尝试获取，如果不可用就立即放弃或采取其他措施。ifAvailable选项就是为此设计的。

async function tryUpdateSettings(newSettings) {
    const lockName = 'app-settings-lock';
    console.log(`[${Date.now()}] 尝试非阻塞获取锁：${lockName}`);
    try {
        const lock = await navigator.locks.request(lockName, { ifAvailable: true }, async (lock) => {
            if (lock) { // lock对象存在表示成功获取
                console.log(`[${Date.now()}] 成功获取锁 ${lockName}，更新设置...`);
                localStorage.setItem('settings', JSON.stringify(newSettings));
                console.log(`[${Date.now()}] 设置更新为: ${JSON.stringify(newSettings)}`);
                // 模拟操作
                await new Promise(resolve => setTimeout(resolve, 1000));
            } else { // 理论上不会走到这里，因为如果没获取到，promise就会拒绝
                console.log(`[${Date.now()}] 未能获取锁 ${lockName}，但回调被执行（这不应该发生）`);
            }
        });

        if (lock === null) { // 如果 ifAvailable 且锁不可用，request() 会 resolve null
            console.log(`[${Date.now()}] 锁 '${lockName}' 当前不可用，已跳过更新。`);
            // 可以在这里执行备用逻辑，例如稍后重试，或通知用户
        } else {
            console.log(`[${Date.now()}] 成功完成锁操作或已跳过。`);
        }
    } catch (error) {
        console.error(`[${Date.now()}] 尝试更新设置失败：`, error);
    }
}

// 示例调用
// 假设某个Tab已经持有 'app-settings-lock'
// tryUpdateSettings({ theme: 'blue' });

// 另一个Tab几乎同时调用
// tryUpdateSettings({ theme: 'green' });

值得注意的是，当 ifAvailable: true 且锁不可用时，navigator.locks.request() 返回的 Promise 会 resolve(null)，而不是拒绝。因此，在回调函数外部检查返回值是处理这种情况的正确方式。

2.4.4 使用 AbortSignal 实现超时或取消

WebLocks API本身没有内置超时机制，request()会一直等待直到锁可用。但我们可以结合AbortSignal来实现外部的超时或取消功能。

async function performOperationWithTimeout(lockName, timeoutMs = 3000) {
    const abortController = new AbortController();
    const timeoutId = setTimeout(() => abortController.abort(), timeoutMs);

    console.log(`[${Date.now()}] 尝试获取锁：${lockName}，超时设置为 ${timeoutMs}ms`);

    try {
        await navigator.locks.request(lockName, { signal: abortController.signal }, async (lock) => {
            clearTimeout(timeoutId); // 成功获取锁，清除超时
            console.log(`[${Date.now()}] 成功获取锁 ${lockName}。`);
            // 模拟长时间操作
            await new Promise(resolve => setTimeout(resolve, 5000)); 
            console.log(`[${Date.now()}] 锁 ${lockName} 操作完成。`);
        });
    } catch (error) {
        if (error.name === 'AbortError') {
            console.error(`[${Date.now()}] 获取锁 ${lockName} 超时或被取消。`);
        } else {
            console.error(`[${Date.now()}] 获取锁 ${lockName} 失败：`, error);
        }
    } finally {
        clearTimeout(timeoutId); // 确保在任何情况下都清除超时
    }
}

// 示例：一个请求会超时，另一个可能成功
// performOperationWithTimeout('long-running-task', 2000); // 这个会超时
// setTimeout(() => {
//     performOperationWithTimeout('long-running-task', 5000); // 这个可能成功，取决于第一个的执行时间
// }, 1000);

三、多进程资源竞态管理

在多进程浏览器环境中，WebLocks API是管理资源竞态的强大工具。

3.1 常见的竞态条件场景

  • IndexedDB 写入冲突：多个Tab页或Worker可能同时尝试更新同一个IndexedDB记录。虽然IndexedDB本身有事务机制，但如果高级业务逻辑需要跨多个事务或在事务外部进行协调，WebLocks就很有用。
  • 本地存储 (localStorage/sessionStorage) 更新：localStorage是同步的，且没有内置的并发控制。多个Tab同时写入可能导致最后一个写入覆盖所有之前的写入，或读取到不一致的数据。
  • 共享内存 (SharedArrayBuffer) 访问：尽管SharedArrayBuffer配合Atomics提供了低级的原子操作，但对于更复杂的、涉及多个原子操作的逻辑，仍需要更高级的互斥机制来保证整个逻辑块的原子性。
  • API 请求频率限制：如果需要限制某个API在所有Tab页或Worker中的总请求频率，WebLocks可以用来协调请求。
  • 页面唯一性判断：确保某个操作或功能（如播放背景音乐）在所有Tab页中只有一个在执行。

3.2 WebLocks API 如何解决竞态条件

WebLocks API通过提供一个全局可见的命名锁系统，使得不同的Web上下文能够协调对共享资源的访问。

  • exclusive 模式：保证了对共享资源的独占访问，这对于写入、修改等操作至关重要，确保数据在修改过程中的一致性。
  • shared 模式：允许在不修改资源的情况下进行并发读取，提高了应用程序的响应性和吞吐量，同时仍然能通过与独占锁的交互来保护写入操作。

3.3 表格：WebLocks 模式与应用场景

锁模式 特点 适用场景 示例
exclusive (独占) 同一时间只有一个持有者。请求会排队等待。 写入、修改、更新操作，需要严格数据一致性。 更新用户配置到 localStorage；向 IndexedDB 写入新数据；执行需要全局原子性的复杂业务逻辑。
shared (共享) 允许多个共享持有者，但独占锁必须等待所有共享锁释放，反之亦然。 读取操作，允许多个并发读取，同时保护写入操作。 缓存数据读取；配置信息读取；在多个 Tab 中显示相同的数据视图，当数据更新时，由一个独占锁来负责更新。
ifAvailable: true 非阻塞尝试获取锁。如果锁不可用，Promise 立即 resolve(null)。 避免长时间等待；实现乐观并发控制；在锁不可用时执行备用逻辑。 尝试立即更新 UI 状态，如果锁不可用则稍后重试；防止用户操作因长时间等待锁而卡顿。
steal: true 强制获取锁，如果锁已被持有，原持有者会立即失去锁。 紧急情况下的恢复机制；高优先级任务抢占低优先级任务。谨慎使用！ 浏览器关闭前需要强制保存用户数据；管理员操作覆盖普通用户操作。

四、死锁预防与处理

死锁是并发编程中一个臭名昭著的问题，当多个进程（或线程）互相等待对方释放资源，从而都无法继续执行时，就发生了死锁。理解并预防死锁至关重要。

4.1 死锁的四大必要条件

死锁的发生需要同时满足以下四个条件：

  1. 互斥 (Mutual Exclusion)：资源不能被共享，即一个资源在任何时刻只能被一个进程占用。WebLocks API 提供的锁天生就满足这个条件。
  2. 占有并等待 (Hold and Wait)：一个进程在占有至少一个资源的同时，又去请求获取已经被其他进程占有的资源，并等待其他进程释放。
  3. 不可抢占 (No Preemption)：已经分配给一个进程的资源不能被强制性地从该进程中抢占，只能由拥有它的进程显式释放。WebLocks API 的锁也是不可抢占的（除非使用 steal 选项，这是一种破坏不可抢占性的手段）。
  4. 循环等待 (Circular Wait)：存在一个进程集合 {P0, P1, ..., Pn}，其中 P0 正在等待 P1 占有的资源，P1 正在等待 P2 占有的资源，…，Pn-1 正在等待 Pn 占有的资源，而 Pn 正在等待 P0 占有的资源。形成一个循环链。

WebLocks API 提供了互斥机制，但它本身并不能自动预防死锁。开发者需要遵循特定的编程范式来避免死锁。

4.2 死锁预防策略 (适用于 WebLocks)

我们主要通过破坏死锁的后三个必要条件来预防死锁。

4.2.1 破坏“占有并等待”：一次性获取所有锁

最直接的方法是要求进程在开始执行前一次性地获取它所需的所有锁。如果不能一次性获取所有锁，就全部释放，然后稍后重试。

JS 代码示例：一次性获取所有锁

async function performComplexTransaction(id) {
    const lockA = 'resource-A';
    const lockB = 'resource-B';

    console.log(`[${id}] 尝试获取 ${lockA} 和 ${lockB}`);
    try {
        // 尝试获取第一个锁
        await navigator.locks.request(lockA, { ifAvailable: true }, async (lockObjA) => {
            if (!lockObjA) {
                console.log(`[${id}] ${lockA} 不可用，放弃所有并重试。`);
                return null; // 返回 null 表示未能获取
            }
            console.log(`[${id}] 成功获取 ${lockA}，尝试获取 ${lockB}`);

            // 在持有 lockA 的同时，尝试获取 lockB
            const lockObjB = await navigator.locks.request(lockB, { ifAvailable: true }, async (lockObjB) => {
                if (!lockObjB) {
                    console.log(`[${id}] ${lockB} 不可用，释放 ${lockA} 并放弃。`);
                    throw new Error('LockB unavailable'); // 抛出错误会立即释放 lockA
                }
                console.log(`[${id}] 成功获取 ${lockB}。开始执行事务。`);
                // 模拟事务操作
                await new Promise(resolve => setTimeout(resolve, 2000));
                console.log(`[${id}] 事务完成，释放 ${lockA} 和 ${lockB}。`);
            });
            return lockObjB; // 返回 lockObjB 的结果
        });

    } catch (error) {
        if (error.message === 'LockB unavailable') {
            console.log(`[${id}] 由于 ${lockB} 不可用，整个事务失败，稍后重试。`);
        } else {
            console.error(`[${id}] 事务执行异常：`, error);
        }
    }
}

// 模拟两个进程同时执行
// performComplexTransaction('Process-1');
// performComplexTransaction('Process-2');

这个示例中，如果第二个锁不可用，第一个锁也会被释放。但这种嵌套的request结构在处理失败时比较复杂，因为它依赖于内部抛出的错误来强制释放外部锁。更推荐的做法是在外部通过Promise链来管理。

更好的“一次性获取所有锁”的模式（概念性，WebLocks API不支持直接一次性请求多个命名锁）：

WebLocks API的设计理念是请求单个命名锁。如果需要同时操作多个资源，并确保原子性，通常有两种方法：

  1. 使用一个“大”锁：如果多个资源总是需要一起被访问，那么可以定义一个更粗粒度的锁名来覆盖所有这些资源。例如，如果 resource-A 和 resource-B 总是同时更新，就请求一个名为 all-related-resources-lock 的独占锁。
  2. 按序获取锁：这是下面要讨论的一种策略。

4.2.2 破坏“循环等待”：资源排序

这是最常用也是最有效的死锁预防方法之一。它要求所有进程在请求多个资源时，都遵循一个预定义的、全局一致的资源获取顺序。

JS 代码示例：按序获取多锁 (推荐)

async function orderedTransaction(processId) {
    const lockNames = ['resource-X', 'resource-Y', 'resource-Z'].sort(); // 确保全局一致的顺序

    let acquiredLocks = [];
    try {
        console.log(`[${processId}] 尝试按序获取锁: ${lockNames.join(', ')}`);

        for (const lockName of lockNames) {
            await navigator.locks.request(lockName, async (lock) => {
                console.log(`[${processId}] 成功获取锁: ${lockName}`);
                acquiredLocks.push(lockName);
                // 模拟一些操作，但不要释放锁，直到所有锁都获取
                await new Promise(resolve => setTimeout(resolve, 100)); 
            });
        }

        console.log(`[${processId}] 成功获取所有锁: ${acquiredLocks.join(', ')}。执行核心业务逻辑...`);
        // 模拟核心业务逻辑
        await new Promise(resolve => setTimeout(resolve, 2000));

    } catch (error) {
        console.error(`[${processId}] 获取锁或执行业务逻辑失败:`, error);
        // 如果在获取某个锁时失败（例如超时），则已经获取的锁会在各自的回调结束后自动释放。
        // 但如果希望立即释放所有，则需要更复杂的机制，如 AbortSignal。
    } finally {
        console.log(`[${processId}] 所有锁操作完成，已获取的锁将自动释放。`);
    }
}

// 模拟两个Tab页或Worker同时执行
// orderedTransaction('Tab-1');
// orderedTransaction('Tab-2');

如果进程1按 X -> Y 的顺序获取锁，而进程2按 Y -> X 的顺序获取锁，就可能发生死锁。通过强制所有进程都按 X -> Y 的顺序获取锁，就可以避免循环等待。

4.2.3 破坏“不可抢占”：使用 steal 选项 (谨慎使用)

WebLocks API 提供了 steal 选项，它允许一个进程强制获取一个已被其他进程持有的独占锁。这本质上是“抢占”了资源。虽然它可以用于打破死锁或解决一些僵局，但它破坏了不可抢占性，可能导致数据不一致或被抢占进程的状态混乱。因此，steal 应该只在特定、明确的恢复或优先级场景下使用，并且需要非常仔细地设计恢复逻辑。

async function emergencyOverride(lockName, data) {
    console.log(`[${Date.now()}] 尝试紧急覆盖：${lockName}`);
    try {
        await navigator.locks.request(lockName, { steal: true }, async (lock) => {
            console.log(`[${Date.now()}] 紧急覆盖成功，获取到锁：${lockName}`);
            // 执行紧急操作
            localStorage.setItem(lockName, JSON.stringify(data));
            console.log(`[${Date.now()}] 紧急操作完成，数据更新为: ${JSON.stringify(data)}`);
            await new Promise(resolve => setTimeout(resolve, 500));
        });
    } catch (error) {
        console.error(`[${Date.now()}] 紧急覆盖失败：`, error);
    }
}

// 假设一个Tab已经持有 'critical-config' 锁并正在执行
// navigator.locks.request('critical-config', async () => {
//     console.log('Original process holding lock...');
//     await new Promise(resolve => setTimeout(resolve, 10000));
//     console.log('Original process finished.');
// });

// 另一个Tab紧急调用
// setTimeout(() => {
//     emergencyOverride('critical-config', { emergency: true, timestamp: Date.now() });
// }, 2000);

当 emergencyOverride 使用 steal: true 成功获取锁时，原持有该锁的 request() Promise 将会被拒绝，并带有一个 AbortError。原持有者必须捕获这个错误并优雅地处理它，例如回滚部分操作或记录状态。

4.2.4 超时机制 (结合 AbortSignal)

虽然不是严格意义上的死锁预防，但超时机制可以避免无限期等待。如果一个进程在尝试获取锁时等待了太长时间，它应该能够放弃请求，释放已持有的资源，并采取其他措施（如重试、报告错误）。这有助于打破潜在的循环等待或活锁情况。

我们前面已经展示了如何结合 AbortSignal 实现超时，这里不再重复代码。

4.3 活锁 (Livelock) 和饥饿 (Starvation)

除了死锁，并发系统中还可能出现活锁和饥饿问题：

  • 活锁 (Livelock)：进程虽然没有被阻塞，但它们却无法取得任何进展，因为它们不断响应其他进程的动作，导致自身也无法完成任务。例如，两个进程都试图获取两个资源，如果不能同时获取，就都释放然后重试，但它们总是互相谦让，导致都无法成功。
  • 饥饿 (Starvation)：一个进程可能因为优先级低或调度算法不公平，而总是无法获取它所需的资源，从而长时间无法执行。

WebLocks API 的实现通常采用公平的队列机制（先进先出），这有助于缓解饥饿问题。对于活锁，开发者需要仔细设计获取锁的逻辑，结合超时和随机退避策略来避免。例如，在释放锁后重试时引入一个随机延迟。

五、WebLocks API 的高级应用与考量

5.1 跨源 (Cross-Origin) 隔离

WebLocks API 的锁是基于源 (origin) 的。这意味着 https://example.com 页面无法获取 https://another-domain.com 页面所持有的锁，即使它们使用相同的锁名。这种设计是Web安全模型的核心，确保了不同源的Web应用之间的隔离，防止恶意网站通过锁机制干扰其他网站。

5.2 Service Workers 中的应用

Service Workers 是在浏览器后台运行的脚本，即使相关的Tab页关闭，它们也可以继续工作。这使得Service Workers非常适合执行后台数据同步、缓存管理等任务。WebLocks API在Service Workers中尤其有用，因为它允许Service Worker在多个Tab页或其他Worker之间协调对共享资源的访问，确保后台操作的原子性和数据一致性。

// service-worker.js
self.addEventListener('fetch', event => {
    event.respondWith(async function() {
        const cacheLockName = 'my-cache-update-lock';
        let response = await caches.match(event.request);

        if (!response) {
            console.log(`[SW] ${event.request.url} 未命中缓存，尝试获取锁进行网络请求和缓存...`);
            await navigator.locks.request(cacheLockName, async (lock) => {
                // 再次检查缓存，防止在等待锁的过程中其他地方已经更新了缓存
                response = await caches.match(event.request);
                if (response) {
                    console.log(`[SW] 在等待锁期间，${event.request.url} 已被其他进程缓存。`);
                    return; // 退出回调，使用新缓存的响应
                }

                console.log(`[SW] 获取到缓存锁，进行网络请求：${event.request.url}`);
                const networkResponse = await fetch(event.request);
                const cache = await caches.open('v1');
                await cache.put(event.request, networkResponse.clone());
                response = networkResponse;
                console.log(`[SW] ${event.request.url} 已缓存。`);
            });
        }
        return response;
    }());
});

这个Service Worker示例展示了如何使用WebLocks来防止多个fetch请求同时去网络获取并缓存同一个资源，从而避免冗余的网络请求和缓存写入冲突。

5.3 性能考量

  • 锁的粒度：
    • 粗粒度锁：一个锁保护多个不相关的资源。优点是管理简单，减少锁开销。缺点是降低并发性，因为即使只访问其中一个资源，也必须等待整个锁。
    • 细粒度锁：每个独立资源都有自己的锁。优点是提高了并发性。缺点是管理复杂，增加锁的开销（请求、释放锁本身有成本）。
    • 选择合适的粒度是关键。通常建议从粗粒度开始，只有在遇到并发瓶颈时才考虑细化锁。
  • 锁的竞争：如果多个进程频繁地竞争同一个锁，会导致大量的等待时间，降低应用程序的响应速度。应尽量减少临界区的大小，并考虑使用shared锁来提高读取并发性。

5.4 替代方案与权衡

WebLock API是解决浏览器多进程互斥问题的一个优秀且标准化的方案，但它并非唯一。根据具体场景，有时其他Web API可能更合适：

  • IndexedDB 事务：对于数据库操作，IndexedDB自身提供了强大的事务机制来保证原子性和隔离性。对于纯粹的数据库操作，优先使用事务。WebLocks可以在更高级别的业务逻辑中协调对IndexedDB的访问。
  • localStorage / sessionStorage 的事件监听：storage事件可以在不同Tab页之间传递localStorage的变化。这可以用于简单的通知机制，但不能提供互斥。
  • SharedArrayBuffer + Atomics：提供了低级的共享内存和原子操作。对于需要高性能、细粒度共享内存操作的场景非常强大，但编程复杂度高，容易出错，且受限于COOP/COEP（跨域隔离）策略。WebLocks可以用于协调对SharedArrayBuffer中复杂数据结构的访问。
  • BroadcastChannel / MessageChannel：用于进程间通信，传递消息。它们提供了通信机制，但本身不提供互斥或同步。可以通过它们传递锁请求和释放的信号，但需要手动实现复杂的同步逻辑，不如WebLocks API方便。

WebLocks API的优势在于其标准化的、易于使用的互斥语义，它弥补了Web平台在进程间同步方面的长期空白。

六、WebLocks API：Web并发编程的强大助力

WebLocks API 为Web平台带来了急需的、标准化的进程间同步能力。它使得开发者能够更可靠地构建复杂的、多进程协同的Web应用，有效管理共享资源的竞态条件。深入理解WebLocks API的工作原理、它与底层操作系统互斥量的关系，以及如何结合死锁预防策略来使用它，是每一位致力于构建高性能、高可用Web应用的开发者必备的技能。随着Web应用复杂度的不断提升，这类底层协调机制的重要性将日益凸显，WebLocks API无疑是Web并发编程工具箱中的一把利器。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注