sp_getapplock 本身不能直接限制并发数，因其仅支持独占/共享锁而无计数功能；但可配合计数表与会话级锁实现原子化的“读-判-改”，从而模拟信号量控制并发上限。
sp_getapplock 能否真正限制并发数
sp_getapplock 本身不提供「计数型」锁，它只有独占（Exclusive）或共享（Shared）两种模式，一次只能锁住一个资源名。想靠它直接实现「最多 3 个会话同时执行」是不可能的——它不是信号量，也没有内置计数器。
但你可以用它模拟计数控制：把「当前运行数」存到一张表里，每次执行前用 sp_getapplock 锁住一个固定资源名（比如 'proc_execution_counter'），读+更新计数，再释放锁。关键在于锁住的是「计数操作」本身，而不是业务逻辑。
- 必须指定
@LockOwner = 'Session'，否则锁在批处理结束就自动释放，起不到保护计数的作用 - 超时值（
@LockTimeoutMs）建议设为非零值（如5000），避免死等；返回值为-1表示获取失败，需主动处理排队或拒绝 - 不要在事务中长期持有该应用锁——它不参与事务回滚，锁住后即使事务失败也不会自动释放
为什么不能只用表级 UPDATE + WHERE count
单纯靠 UPDATE counter_table SET cnt = cnt + 1 WHERE cnt 是不够的。在高并发下，多个会话可能同时读到 <code>cnt = 2，都判断通过，然后都执行 SET cnt = 3，最终 cnt 变成 3，但实际已有 4 个会话进入临界区。
这就是典型的「检查-执行」竞态（check-then-act race）。你必须让「读当前值 + 判断 + 修改」成为原子操作，而 sp_getapplock 正是用来包裹这个原子段的最轻量手段。
- 替代方案如
sp_lock或行锁（UPDLOCK, HOLDLOCK）也可行，但需要额外建表、索引，且锁粒度更重 -
sp_getapplock不依赖物理对象，资源名可任意定义，适合快速上线控制逻辑 - 注意锁名长度限制：最大 255 字符，且只支持 ASCII 字母、数字、下划线
一个安全可用的并发控制模板
下面是一个带完整错误处理和清理的最小可行结构。假设你要限制存储过程 usp_do_work 最多 2 个并发实例：
DECLARE @result INT;
EXEC @result = sp_getapplock
@Resource = 'usp_do_work_concurrent_guard',
@LockMode = 'Exclusive',
@LockOwner = 'Session',
@LockTimeoutMs = 3000;
<p>IF @result </p><p>-- 此处开始受控逻辑：读计数、判断、更新
IF NOT EXISTS(SELECT 1 FROM dbo.ExecutionCounter WHERE ProcName = 'usp_do_work' AND ActiveCount </p><p>UPDATE dbo.ExecutionCounter
SET ActiveCount = ActiveCount + 1
WHERE ProcName = 'usp_do_work';</p><p>-- 执行你的主业务逻辑……
-- WAITFOR DELAY '00:00:05'; -- 模拟耗时操作</p><p>-- 执行完毕后减计数
UPDATE dbo.ExecutionCounter
SET ActiveCount = CASE WHEN ActiveCount > 0 THEN ActiveCount - 1 ELSE 0 END
WHERE ProcName = 'usp_do_work';</p><p>EXEC sp_releaseapplock @Resource = 'usp_do_work_concurrent_guard', @LockOwner = 'Session';</p>
- 必须显式调用
sp_releaseapplock，不能依赖连接断开自动释放——连接池会让会话复用，锁可能残留 - 计数表
ExecutionCounter需预先创建，并确保ProcName为主键或有唯一索引 - 所有对计数表的读写都发生在应用锁保护区内，这是原子性的唯一保障
容易被忽略的清理与监控点
生产环境最常出问题的地方不在加锁逻辑，而在异常路径下的锁和计数残留。比如主逻辑抛错、客户端中断、SQL Server 异常重启，都会导致计数未减、应用锁未释放。
- 建议在存储过程开头加
IF @@TRANCOUNT > 0 ROLLBACK;清理可能遗留的事务状态 - 定期运行清理脚本：查
sys.dm_tran_locks中长时间持有的APP类型锁，结合sys.dm_exec_sessions定位可疑会话 - 计数表应增加
LastUpdated DATETIME2字段，配合后台作业检测并重置「超时未更新」的计数行（例如 30 分钟无更新） -
sp_getapplock返回值必须检查：0成功，-1超时，-2死锁被选为牺牲品，-999参数错误——每种都要区分处理
真正的难点从来不是“怎么加锁”，而是“怎么确保锁一定被释放、计数一定被修正”。这两件事漏掉任何一个，过几天就会收到告警说“并发数永远卡在上限”。
