PostgreSQL 的 advisory lock 通常被翻译为应用锁或咨询锁，它允许应用在数据库层面申请一把完全由自己定义含义的锁，而不需要绑定到任何具体的表或行。与行级锁、表级锁不同，advisory lock 的锁目标是一个应用自定义的整数或两个整数组合，数据库只负责提供加锁、解锁、冲突判断等原语，至于这个数字代表某个用户余额操作、某个定时任务批次还是某条外部资源记录，完全由应用层解释。这种设计使得 advisory lock 成为跨行、跨表甚至跨服务协调并发的一种轻量级工具。
一、advisory lock 的锁模式与函数分类
PostgreSQL 提供的 advisory lock 从生命周期上可以分为会话级和事务级两类。会话级锁一旦获取，会一直保留到当前数据库会话结束或显式调用解锁函数为止；事务级锁则只在当前事务内有效，事务提交或回滚后自动释放，即使发生异常也不会残留。这个区别在实际使用中非常重要，因为它直接决定了锁的清理方式和连接池场景下的安全性。
从互斥强度来看，advisory lock 又分为排它锁和共享锁。排它锁与任何其他锁都互斥，共享锁之间可以共存，但共享锁与排它锁互斥。这个设计很像读写锁，允许多个会话同时持有一把共享锁用于只读操作，而写操作需要排它锁。常用的函数包括 pg_advisory_lock、pg_try_advisory_lock、pg_advisory_lock_shared，以及对应的事务级版本 pg_advisory_xact_lock、pg_advisory_xact_lock_shared 等。
下面的 SQL 展示了会话级锁的基本用法，其中 pg_try_advisory_lock 是非阻塞版本，拿不到锁时立即返回 false，而不是等待。
-- 会话级排它锁：阻塞直到获取成功 SELECT pg_advisory_lock(100); -- 非阻塞尝试获取排它锁，成功返回 true，失败返回 false SELECT pg_try_advisory_lock(100); -- 会话级共享锁：多个会话可同时持有共享锁 SELECT pg_advisory_lock_shared(100); -- 释放会话级排它锁 SELECT pg_advisory_unlock(100); -- 释放会话级共享锁 SELECT pg_advisory_unlock_shared(100);
PostgreSQL 还允许使用两个 32 位整数来构造一个 64 位的锁键，例如 pg_advisory_lock(classid, objid)。这种方式在锁键需要携带更多语义时非常有用，比如 classid 表示业务模块，objid 表示具体资源 ID。数据库在内部会把这些参数转换成同一个哈希键，因此 pg_advisory_lock(1, 2) 与 pg_advisory_lock(2, 1) 是两把完全不同的锁。
二、典型场景：用 advisory lock 实现分布式任务互斥
一个最常见的场景是定时任务的多实例部署。假设同一个应用部署了多个实例，每个实例都会在固定时间触发清理任务，如果不加控制，可能出现多个实例同时处理同一批数据，导致重复执行或数据不一致。这时可以利用 advisory lock 来保证同一时刻只有一个实例能执行任务。
实现思路很简单：每个实例启动任务时，用同一个固定整数作为锁键去尝试获取排它锁。只有获取成功的实例才继续执行业务逻辑，获取失败的实例直接跳过本轮或进入等待。为了不让任务阻塞在等待锁上，一般使用 pg_try_advisory_lock，这样拿不到锁的实例可以快速退出，避免堆积大量等待连接。
DO $$
DECLARE
lock_acquired boolean;
BEGIN
lock_acquired := pg_try_advisory_lock(42);
IF lock_acquired THEN
-- 执行业务逻辑
PERFORM pg_sleep(5);
PERFORM pg_advisory_unlock(42);
ELSE
RAISE NOTICE 'another worker is already running';
END IF;
END $$;
这段代码模拟了一个任务执行骨架。锁键 42 可以替换为业务相关的常量，例如任务 ID。需要注意的是，这里使用的是会话级锁，所以最后必须手动调用 pg_advisory_unlock 释放。如果业务逻辑执行过程中抛出了异常，PL/pgSQL 块并不会自动释放这把锁，除非在异常处理中也显式释放，或者改用事务级锁。
另一个值得注意的问题是连接池。会话级 advisory lock 绑定在物理连接上，而不是应用层逻辑会话上。如果应用从连接池借出一个连接获取了锁，执行业务后又把连接归还给连接池，那么这把锁依然被这个物理连接持有。当下一个请求从连接池拿到同一个连接时，它可能会意外继承这把锁，或者因为锁未释放而阻碍其他任务。因此，在连接池环境下，更推荐使用事务级 advisory lock，或者确保锁获取与释放严格配对，并且释放后再归还连接。
三、事务级锁与异常安全性分析
事务级 advisory lock 通过 pg_advisory_xact_lock 系列函数获取，它不需要显式调用解锁函数。当事务提交或回滚时，锁会被 PostgreSQL 自动释放。这个特性让事务级锁在异常安全方面表现更好，因为即使业务代码抛出异常，只要事务结束，锁就不会残留。
下面是一个事务级锁的示例。事务开始后获取锁，然后更新任务队列中的一条记录，最后提交事务。提交后锁自动释放，不需要在业务逻辑中处理释放问题。
BEGIN; -- 获取事务级排它锁，事务结束自动释放 SELECT pg_advisory_xact_lock(200); -- 执行受保护的操作 UPDATE task_queue SET status = 'processing' WHERE id = 1; COMMIT;
事务级锁特别适合短事务场景，比如数据库内的状态转换、资源抢占、防重复扣费操作等。它的缺点是锁的持有时间由事务长度决定。如果事务中包含长时间运行的计算或者外部网络调用，锁会被持有更久，增加其他会话的等待时间。所以在长事务中，要谨慎使用事务级锁，必要时可以拆分成小事务，或者将长耗时操作放在事务外。
无论是会话级还是事务级锁，都可以通过查询 pg_locks 视图来观察当前的锁状态。下面的 SQL 可以查看所有 advisory lock 的持有情况，方便定位锁冲突和未释放的锁。
SELECT
l.locktype,
l.mode,
l.granted,
l.pid,
l.classid,
l.objid,
a.query
FROM pg_locks l
LEFT JOIN pg_stat_activity a ON a.pid = l.pid
WHERE l.locktype = 'advisory';
其中 granted 为 true 表示锁已经被成功授予，false 表示该会话正在等待锁。通过关联 pg_stat_activity，可以看到等待锁的会话正在执行什么 SQL，这对排查锁等待问题很有帮助。
四、常见误区和排查方法
第一个常见误区是认为 advisory lock 会自动保护数据。实际上它只是一把由数据库管理的命名锁，并不会阻止其他连接修改真实数据。如果业务中有一条规则要求某个用户同一时刻只能有一笔扣款操作，那么所有涉及该用户扣款的代码都必须遵守同一套锁协议，即先获取该用户编号对应的 advisory lock，再操作相关表。只要有一个入口没有遵守这个协议，锁保护就会被绕过。
第二个误区是锁键设计过于随意。不同业务模块如果使用相同的整数作为锁键，会导致无关业务互相阻塞。例如两个不同的后台任务都用 1 作为锁键，那么它们永远不能并发执行。为了避免这种情况，建议对锁键做统一规划，比如使用业务前缀加上资源 ID 的哈希值，或者使用两个 32 位整数分别表示模块和资源。锁键的值可以是任意 bigint，因此有足够大的空间来分配不同的业务域。
第三个常见问题是会话级锁忘记释放。虽然数据库连接断开时锁会自动清理，但在连接池环境中连接通常不会断开，所以忘记释放就会造成锁长期占用，后续请求持续失败。排查这类问题时，可以先查询 pg_locks 中 locktype = 'advisory' 的记录，找到长期持有且从未变化的 pid，再通过 pg_stat_activity 查看该连接最近的查询。如果确认是泄漏，可以通过 pg_terminate_backend(pid) 强制结束该连接来释放锁，但更根本的方案还是加强代码中的解锁逻辑或改用事务级锁。
advisory lock 是 PostgreSQL 提供的一种灵活而高效的并发控制手段，合理使用可以解决很多行级锁难以覆盖的场景。关键在于理解会话级与事务级的区别、排它锁与共享锁的语义，以及在连接池和异常路径下锁的释放行为。设计锁键时做好业务隔离，再配合 pg_locks 的监控手段，就能把应用锁的作用发挥到最大。
PostgreSQLadvisory lock应用锁修改时间：2026-09-25 20:29:45