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() 方法还可以接受一个可选的选项对象,用于指定锁的模式。有两种模式:
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 的兼容性相对较好,主流浏览器如 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 本身不提供死锁检测或避免机制,需要开发者自行处理。
设置超时: 在请求锁时设置超时时间,如果超过时间仍未获得锁,则放弃请求。
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 中同样可以使用,用于协调多个 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 时,要确保锁的释放逻辑能够可靠执行,避免资源长期被锁定。
传统的 JavaScript 锁机制通常基于变量或标志位来实现,例如:
let isLocked = false; async function doSomething() { if (isLocked) { console.warn('Resource is locked, try again later'); return; } isLocked = true; try { // ... } finally { isLocked = false; } }
这种方式存在一些问题:
Web Locks API 解决了这些问题:
总的来说,Web Locks API 提供了一种更安全、更可靠的锁机制,适用于需要协调多个脚本对共享资源访问的场景。虽然传统的 JavaScript 锁机制在某些简单场景下仍然可用,但在复杂的应用中,Web Locks API 是更好的选择。
以上就是js如何操作Web Locks锁 3种锁机制解决资源竞争问题的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号