web locks api 通过 exclusive 和 shared 两种模式协调浏览器中多个脚本对共享资源的访问，避免竞争条件。1. 请求锁使用 navigator.locks.request() 方法，确保只有锁可用时才执行回调；2. 锁有 exclusive（默认，独占）和 shared（共享）两种模式；3. 锁在回调执行完毕或出错时自动释放，也可手动调用 lock.release()；4. 多个请求按顺序排队获取锁；5. 锁为会话级别，浏览器关闭时释放。基于这两种模式可构建互斥锁、共享锁及读写锁策略以应对不同场景。兼容性方面，主流浏览器如 chrome、firefox、safari（14.1+）均支持，使用前应进行特性检测。死锁处理需开发者自行实现，如设置超时、固定锁请求顺序、避免嵌套锁等。在 service worker 中同样可用，有助于离线应用保持数据一致性，但需注意其生命周期管理。相比传统基于变量的锁机制，web locks api 更安全可靠，具备自动释放、跨线程/进程支持及浏览器级管理等优势。
Web Locks API 允许 JavaScript 脚本在浏览器环境中获取锁，以协调对共享资源的访问，从而避免竞争条件。简单来说，它就像一个交通信号灯，确保只有一个脚本在特定时间内可以修改某个共享数据。
解决方案
Web Locks API 提供了一种在浏览器环境中协调资源访问的机制。它主要通过 navigator.locks 对象来实现。以下是使用 Web Locks API 的基本步骤和示例：
-
请求锁: 使用
navigator.locks.request()方法请求锁。这个方法接受锁的名称和一个回调函数。只有当锁可用时，回调函数才会被执行。
navigator.locks.request('my-resource', async lock => { // 锁被持有期间执行的代码 console.log('Lock acquired!'); try { // 访问或修改共享资源 await doSomethingWithResource(); } finally { console.log('Lock released!'); } }); -
锁的模式:
request()方法还可以接受一个可选的选项对象，用于指定锁的模式。有两种模式：-
exclusive(默认): 只有请求者可以持有锁。 -
shared: 多个请求者可以同时持有锁。
navigator.locks.request('my-resource', { mode: 'shared' }, async lock => { console.log('Shared lock acquired!'); // ... }); -
锁的自动释放: 当回调函数执行完毕或抛出错误时，锁会自动释放。如果需要在回调函数内部手动释放锁，可以通过
lock.release()方法，但这通常是不必要的。锁的竞争: 如果多个脚本同时请求同一个锁，浏览器会按照请求的顺序依次授予锁。后面的请求会等待前面的请求释放锁。
锁的持久性: Web Locks API 的锁是会话级别的，也就是说，当浏览器会话结束时，锁会自动释放。
3 种锁机制解决资源竞争问题
Web Locks API 本身不直接提供三种不同的锁机制，而是通过 exclusive 和 shared 两种模式来应对不同的资源竞争场景。我们可以基于这两种模式，构建更复杂的锁策略。
-
互斥锁 (Exclusive Lock): 这是最常见的锁类型。它确保在任何时候只有一个脚本可以访问共享资源。适用于需要独占访问权限的场景，例如更新数据库记录。
navigator.locks.request('database-record-123', async lock => { // 只有当前脚本可以修改这条记录 await updateDatabaseRecord(123); }); -
共享锁 (Shared Lock): 允许多个脚本同时读取共享资源，但阻止任何脚本写入。适用于读取操作频繁，写入操作较少的场景，例如缓存读取。
navigator.locks.request('cache-data', { mode: 'shared' }, async lock => { // 多个脚本可以同时读取缓存数据 const data = await readCacheData(); return data; }); -
读写锁 (Read-Write Lock): 这是互斥锁和共享锁的组合。它允许多个脚本同时持有读锁，但只允许一个脚本持有写锁。适用于读多写少的场景，可以提高并发性能。虽然 Web Locks API 没有直接提供读写锁，但可以通过结合
exclusive和shared模式来实现。async function withReadLock(resourceName, callback) { await navigator.locks.request(resourceName, { mode: 'shared' }, async lock => { await callback(); }); } async function withWriteLock(resourceName, callback) { await navigator.locks.request(resourceName, async lock => { await callback(); }); } // 读操作 await withReadLock('my-data', async () => { const data = await fetchData(); console.log('Data:', data); }); // 写操作 await withWriteLock('my-data', async () => { await updateData(); });
Web Locks API 的兼容性如何？哪些浏览器支持？
Web Locks API 的兼容性相对较好，主流浏览器如 Chrome, Firefox, Safari (从 14.1 版本开始) 都支持。使用前最好进行特性检测：
if ('locks' in navigator) {
// Web Locks API is supported
console.log('Web Locks API is supported!');
} else {
// Web Locks API is not supported
console.warn('Web Locks API is not supported!');
}虽然兼容性不错，但仍需考虑旧版本浏览器，提供降级方案。例如，可以使用 localStorage 或 IndexedDB 来模拟锁机制，虽然性能和可靠性可能不如原生 API。
如何处理 Web Locks API 中的死锁情况？
死锁是指两个或多个脚本相互等待对方释放锁，导致所有脚本都无法继续执行。Web Locks API 本身不提供死锁检测或避免机制，需要开发者自行处理。
-
设置超时: 在请求锁时设置超时时间，如果超过时间仍未获得锁，则放弃请求。
const timeout = 5000; // 5 seconds let lockAcquired = false; const timeoutId = setTimeout(() => { if (!lockAcquired) { console.error('Failed to acquire lock within timeout'); // Handle timeout: retry, abort, etc. } }, timeout); navigator.locks.request('my-resource', async lock => { lockAcquired = true; clearTimeout(timeoutId); // Clear the timeout // ... }); 锁的排序: 如果需要同时获取多个锁，按照固定的顺序请求锁，避免循环等待。
避免嵌套锁: 尽量避免在一个锁的回调函数中请求另一个锁。
Web Locks API 在 Service Worker 中如何使用？
Web Locks API 在 Service Worker 中同样可以使用，用于协调多个 Service Worker 实例对共享资源的访问。这在离线应用中尤其有用，可以确保数据的一致性。
// In Service Worker
self.addEventListener('fetch', event => {
event.respondWith(
(async () => {
try {
await navigator.locks.request('my-cache', async lock => {
// Access or update cache
const cachedResponse = await caches.match(event.request);
if (cachedResponse) {
return cachedResponse;
}
const networkResponse = await fetch(event.request);
const cache = await caches.open('my-cache');
await cache.put(event.request, networkResponse.clone());
return networkResponse;
});
} catch (error) {
console.error('Failed to acquire lock in Service Worker:', error);
return fetch(event.request); // Fallback to network
}
})()
);
});需要注意的是，Service Worker 的生命周期较短，可能会被浏览器随时终止。因此，在使用 Web Locks API 时，要确保锁的释放逻辑能够可靠执行，避免资源长期被锁定。
Web Locks API 和传统的 JavaScript 锁机制有什么区别？
传统的 JavaScript 锁机制通常基于变量或标志位来实现，例如：
let isLocked = false;
async function doSomething() {
if (isLocked) {
console.warn('Resource is locked, try again later');
return;
}
isLocked = true;
try {
// ...
} finally {
isLocked = false;
}
}这种方式存在一些问题：
- 容易出错: 开发者需要手动管理锁的获取和释放，容易出现忘记释放锁或错误释放锁的情况。
- 竞争条件: 在多线程或多进程环境中，由于 JavaScript 的单线程特性，这种锁机制可能无法正常工作。
- 不可靠: 如果脚本在持有锁期间崩溃或终止，锁可能永远无法释放。
Web Locks API 解决了这些问题：
- 自动释放: 锁在回调函数执行完毕或抛出错误时自动释放，避免忘记释放锁的问题。
- 跨线程/进程: Web Locks API 可以在不同的线程或进程之间协调资源访问，例如在 Service Worker 和主线程之间。
- 可靠性: 浏览器负责管理锁的状态，即使脚本崩溃或终止，锁也能被正确释放。
总的来说，Web Locks API 提供了一种更安全、更可靠的锁机制，适用于需要协调多个脚本对共享资源访问的场景。虽然传统的 JavaScript 锁机制在某些简单场景下仍然可用，但在复杂的应用中，Web Locks API 是更好的选择。
