Web Locks API通过navigator.locks.request()提供原生并发控制，解决跨上下文数据冲突问题。它支持exclusive（独占）和shared（共享）两种模式，分别用于写操作和读操作的协调，实现“多读单写”的高效同步。开发者可利用锁名称统一标识资源，结合options配置ifAvailable、steal和AbortSignal等行为，避免竞态条件与资源争用。相比localStorage事件或postMessage等手动方案，Web Locks具备原子性、自动释放、浏览器级可靠性等优势。典型应用场景包括全局状态更新、缓存读写、资源预加载等。使用时需警惕死锁、长时间持锁、错误处理缺失等问题，最佳实践包括缩小锁粒度、统一命名、避免嵌套锁、结合AbortSignal取消请求，并利用navigator.locks.query()进行调试监控，确保并发安全与系统稳定性。
在现代Web应用中，尤其当你的应用需要在多个浏览器标签页、Web Worker甚至Service Worker之间协调工作时，管理共享资源和并发访问无疑是个老大难问题。简单来说，Web Locks API提供了一种原生的、标准化的方式，让你能够安全地锁定一个共享资源，确保在某个时刻只有一个（或特定数量的）代码段能够访问它，从而有效避免数据冲突和竞态条件。这就像给你的数据加了一把锁，只有拿到钥匙的人才能进去操作，大大简化了跨上下文同步的复杂性。
解决方案
使用Web Locks API的核心在于
navigator.locks.request()
方法。它是一个基于Promise的异步函数，允许你请求一个具名锁。当你成功获取到锁后，你的回调函数会被执行，而一旦回调函数执行完毕（无论是正常返回还是抛出错误），锁都会被自动释放。这机制在我看来，简直是开发者福音，省去了手动管理锁状态的繁琐。
基本的用法是这样的：
async function updateSharedCounter() { const lockName = 'my_shared_counter_lock'; try { await navigator.locks.request(lockName, async lock => { // 成功获取到锁，现在可以安全地访问共享资源了 console.log(`Lock '${lockName}' acquired.`); // 模拟一个耗时操作，例如从localStorage读取、修改、写入 let count = parseInt(localStorage.getItem('shared_counter') || '0', 10); count++; localStorage.setItem('shared_counter', count.toString()); console.log(`Counter updated to: ${count}`); // 锁会在这个异步操作完成后自动释放 // 如果这里有其他异步操作，确保它们在锁的范围内完成 await new Promise(resolve => setTimeout(resolve, 500)); // 模拟异步工作 }); console.log(`Lock '${lockName}' released.`); } catch (error) { // 请求锁失败或回调函数中出现错误 console.error(`Failed to acquire or execute with lock '${lockName}':`, error); }}// 可以在多个标签页或worker中同时调用updateSharedCounter();
navigator.locks.request()
接受两个主要参数：
name
：一个字符串，代表你想要锁定的资源名称。这是跨上下文同步的关键，所有试图锁定同一名称的请求都会相互协调。
callback
：一个异步函数，当锁被成功获取后，这个函数会被执行。锁的生命周期与这个函数的执行周期绑定。
options
（可选）：一个配置对象，可以指定锁的模式（
exclusive
或
shared
）、行为（
ifAvailable
、
steal
）以及一个
AbortSignal
。
模式选择上，
exclusive
（默认）意味着一次只有一个请求可以持有这个锁；而
shared
模式则允许多个请求同时持有锁，但任何
exclusive
模式的请求都会被阻塞，直到所有
shared
锁都被释放。这是一个非常巧妙的设计，允许“多读单写”的场景。
// 带有选项的请求示例async function tryUpdateCounterConditionally() { const lockName = 'my_shared_counter_lock'; const options = { mode: 'exclusive', ifAvailable: true // 如果锁不可用，则立即拒绝，而不是等待 }; try { const lock = await navigator.locks.request(lockName, options, async lock => { console.log(`Conditionally acquired lock '${lockName}'.`); // ... 执行操作 ... }); if (!lock) { console.log(`Lock '${lockName}' was not available, skipping update.`); } } catch (error) { console.error(`Error during conditional lock request:`, error); }}
值得一提的是，你还可以通过
navigator.locks.query()
方法来查看当前活跃的锁和处于待定状态的锁，这对于调试和理解应用中的并发行为非常有帮助。
Web Locks API如何解决传统并发访问的痛点？
在我看来，Web Locks API的出现，简直是对Web并发编程领域的一次“降维打击”。过去，我们为了在不同浏览器标签页或Worker之间同步状态，简直是绞尽脑汁，各种土法炼钢。你可能尝试过利用
localStorage
的事件监听来通知其他上下文，或者在
IndexedDB
事务中模拟锁，甚至更复杂的基于
postMessage
的消息队列机制。这些方案，无一例外，都伴随着高昂的开发成本、潜在的竞态条件以及难以调试的“幽灵Bug”。
想想看，手动管理一个全局的“忙碌”状态，需要确保所有操作都正确地设置和清除了这个状态，一旦有任何遗漏，数据不一致就可能发生。而且，这些自定义方案往往缺乏原子性，一个复杂的操作可能被中断，留下一个半成品的数据状态。Web Locks API则不然，它是由浏览器底层提供的原生能力，天生就具备原子性、可靠性和跨上下文的可见性。你不需要再担心某个标签页崩溃导致锁永远不释放（浏览器会自动处理），也不用编写大量的样板代码来协调消息。它把并发控制的复杂性封装起来，暴露一个简洁的API，让我们能更专注于业务逻辑本身，而不是与底层机制搏斗。这就像从自己造轮子，直接升级到了使用汽车厂商提供的标准组件，效率和稳定性都不可同日而语。
在实际开发中，Web Locks API的
exclusive
与
shared
模式有何应用场景？
exclusive
和
shared
这两种模式，在我看来，是Web Locks API最精妙的设计之一，它们完美契合了“读多写少”和“独占写入”这两种最常见的并发场景。
exclusive
模式（独占锁）的应用场景：
更新关键配置或状态： 假设你的应用有一个全局配置对象存储在
localStorage
或
IndexedDB
中，多个标签页可能会尝试修改它。使用
exclusive
锁可以确保在任何给定时间只有一个标签页能进行修改，防止配置被覆盖或损坏。
// 示例：独占更新用户偏好设置async function updateUserSettings(newSettings) { await navigator.locks.request('user_settings_lock', async () => { const currentSettings = JSON.parse(localStorage.getItem('userSettings') || '{}'); const mergedSettings = { ...currentSettings, ...newSettings }; localStorage.setItem('userSettings', JSON.stringify(mergedSettings)); console.log('User settings updated exclusively.'); });}
执行一次性的、资源密集型任务： 例如，一个Web Worker负责从服务器下载大量数据并缓存到
IndexedDB
。你可能希望只有一个Worker实例执行这个下载和缓存过程，避免重复下载和资源浪费。跨标签页的UI同步： 当一个用户操作需要在多个标签页中产生同步的UI效果时（例如，用户在一个标签页中登出，所有其他标签页也应立即登出），
exclusive
锁可以用来确保登出逻辑的原子性执行，并通知所有相关上下文。
shared
模式（共享锁）的应用场景：
缓存读取与更新： 这是
shared
模式最典型的应用。多个标签页可以同时从一个共享缓存（例如，
IndexedDB
中的数据）中读取数据，而不会相互阻塞。但是，当需要更新这个缓存时，就需要一个
exclusive
锁。
// 示例：共享读取缓存，独占更新缓存async function readFromCache(key) { let data = null; await navigator.locks.request('data_cache_lock', { mode: 'shared' }, async () => { data = localStorage.getItem(`cache_${key}`); console.log(`Read from cache (shared): ${key}`); }); return data;}async function updateCache(key, value) { await navigator.locks.request('data_cache_lock', { mode: 'exclusive' }, async () => { localStorage.setItem(`cache_${key}`, value); console.log(`Updated cache (exclusive): ${key}`); });}// 多个标签页可以同时调用 readFromCache// 只有一个标签页可以调用 updateCache，当 updateCache 运行时，所有 readFromCache 都会被阻塞
资源预加载状态管理： 多个页面可能都需要同一个大型资源（如一个WebAssembly模块或大型图片）。
shared
锁可以表示资源正在被使用，而
exclusive
锁可以在资源需要被重新下载或更新时使用。
日志记录： 多个上下文可以同时向一个共享的日志存储写入日志，但如果需要执行一个日志归档或清理的特殊操作，则可能需要一个
exclusive
锁来确保操作的完整性。
这种读写分离的模式，在我看来，极大地提高了并发系统的效率，因为它允许并发读取，只在真正需要修改数据时才引入独占阻塞，这在Web应用中非常常见。
使用Web Locks API时，有哪些常见的陷阱和最佳实践？
Web Locks API虽然强大，但并非万能药，使用不当同样会引入新的问题。在我有限的经验中，以下几点是需要特别注意的：
常见陷阱：
死锁（Deadlock）： 这是并发编程的经典难题。如果你在不同的上下文中以不同的顺序请求多个锁，就可能发生死锁。例如，标签A请求锁X，然后请求锁Y；标签B请求锁Y，然后请求锁X。如果两者同时发生，A可能持有X并等待Y，B持有Y并等待X，导致双方都无法继续。长时间持有锁： 锁的目的是保护临界区。如果你的回调函数中包含了耗时很长的同步操作，或者不必要的异步等待，那么锁就会被长时间持有，严重影响其他上下文的性能和响应性。误解
ifAvailable
和
steal
选项：
ifAvailable: true
会使
request
方法立即返回
null
如果锁不可用，而不是等待。这适用于非关键的、可以跳过的操作。而
steal: true
则更为激进，它会强制获取锁，即使当前有其他上下文持有该锁。这会中断其他上下文的操作，导致数据不一致或错误，务必慎用，除非你明确知道自己在做什么。忽略错误处理：
navigator.locks.request()
返回的是一个Promise，它可能会因为各种原因（如
AbortSignal
被触发、浏览器内部错误）而拒绝。不进行适当的
try...catch
处理，可能导致未捕获的错误。
最佳实践：
保持锁的粒度尽可能小，持有时间尽可能短： 只在真正需要保护共享资源的代码块中使用锁，并且一旦操作完成，就让锁自动释放。避免在锁的回调函数中执行与共享资源无关的、耗时的操作。
统一命名约定： 为你的锁选择清晰、一致的名称。所有需要协调访问某个资源的上下文，都必须使用完全相同的锁名称。一个好的做法是使用模块名或资源路径作为锁名称的一部分。
避免嵌套锁，或确保一致的锁请求顺序： 如果你确实需要获取多个锁，请确保在所有上下文中都以相同的顺序请求它们，这是避免死锁的关键策略。
利用
AbortSignal
： 对于那些可能被用户取消或不再需要的操作，你可以传入一个
AbortSignal
到
request
方法的选项中。当
AbortSignal
被触发时，如果锁还在等待队列中，请求就会被取消，避免不必要的等待。
const controller = new AbortController();const signal = controller.signal;// 某个事件触发时，取消锁请求// controller.abort();navigator.locks.request('cancellable_task_lock', { signal }, async () => { // ... 任务逻辑 ...}).catch(error => { if (error.name === 'AbortError') { console.log('Lock request was aborted.'); } else { console.error('Lock request failed:', error); }});
结合Web Workers： 即使使用了Web Locks API，长时间运行或计算密集型任务仍然应该在Web Worker中执行，以避免阻塞主线程，确保用户界面的响应性。锁可以用于协调Worker与主线程之间，或不同Worker之间的共享数据访问。
监控与调试： 使用
navigator.locks.query()
来检查当前活跃和待定的锁状态。这对于理解并发行为、诊断性能瓶颈或死锁问题非常有帮助。
总而言之，Web Locks API是一个强大的工具，它极大地简化了Web平台上的并发控制。但就像任何强大的工具一样，理解其工作原理、潜在风险并遵循最佳实践，才能真正发挥它的价值，构建出健壮、高效的Web应用。
以上就是如何用Web Locks API管理资源共享与并发访问？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/57377.html
微信扫一扫 
支付宝扫一扫 
