精通 Salesforce 记录锁定：Apex 中 FOR UPDATE 的开发者指南

十一月 19, 2025

背景与应用场景

作为一名 Salesforce 开发人员，我们经常需要处理复杂的业务逻辑，这些逻辑可能涉及在单个事务中读取和更新多条记录。在多用户并发环境下，一个常见的挑战是确保数据的完整性 (Data Integrity)。想象这样一个场景：两个财务人员同时尝试根据新关闭的 Opportunity 更新同一个 Account 的年度总收入。如果他们的操作同时进行，用户 A 读取了旧的总收入，用户 B 也读取了同一个旧的总收入。用户 A 加上新的 Opportunity 金额并保存，紧接着用户 B 也加上他处理的 Opportunity 金额并保存。最终的结果是，只有用户 B 的更新被保留了下来，用户 A 的更新被完全覆盖了。这就是典型的“丢失更新”(Lost Update) 问题。

为了解决这类并发问题，Salesforce 平台提供了一个强大的机制：Record Locking (记录锁定)。记录锁定是一种防止在同一时刻有多个事务修改同一条记录的机制。当一个事务锁定了某条记录后，其他试图修改该记录的事务必须等待，直到锁被释放。这确保了事务的原子性和数据的一致性。

在声明式工具（如 Flow 或 Process Builder）中，Salesforce 会在后台自动处理大部分记录锁定。但作为开发人员，在使用 Apex 进行编程时，我们必须显式地控制记录锁定，尤其是在处理以下场景时：

财务计算： 在多个子记录（如 OpportunityLineItem）更新时，需要锁定父记录（如 Opportunity 或 Account）以进行汇总计算。
复杂的审批流程： 在一个多步骤的审批逻辑中，需要确保审批状态和相关记录在整个流程中不被外部操作干扰。
库存管理： 当多个订单同时尝试扣减同一个产品的库存时，必须锁定库存记录以防止超卖。
集成场景： 从外部系统接收数据并更新 Salesforce 记录时，需要确保在“读取-处理-写入”的整个周期中，目标记录不被其他用户或系统修改。

理解并正确使用记录锁定，是编写健壮、可靠的 Salesforce Apex 代码的关键技能。

原理说明

在 Salesforce 中，记录锁定主要通过 Apex 中的 SOQL (Salesforce Object Query Language) 查询语句的 FOR UPDATE 子句来实现。当你在一个 SOQL 查询的末尾添加 FOR UPDATE 时，你就在向 Salesforce 平台声明：“我即将要更新这些我查询出来的记录，请为我锁定它们，直到我的事务完成。”

其核心工作原理如下：

1. 获取排他锁 (Exclusive Lock)

执行 SELECT ... FOR UPDATE 查询时，Salesforce 会尝试为查询返回的所有记录行加上一个排他锁。这个锁会阻止任何其他事务更新或删除这些记录。其他事务仍然可以读取这些记录的旧版本，但任何修改操作（DML 操作，如 update, delete）都会被阻塞。

2. 事务范围 (Transaction Scope)

这个锁的生命周期与当前的 Apex 事务绑定。锁会在事务开始时（即 FOR UPDATE 查询执行时）获取，并在事务结束时（通过 commit 成功提交或 rollback 失败回滚）自动释放。这意味着，从你锁定记录到你的代码执行完毕，这些记录都是为你“保留”的。

3. 锁争用与超时 (Lock Contention and Timeout)

如果当你的事务尝试用 FOR UPDATE 锁定记录时，这些记录已经被另一个事务锁定了，会发生什么？你的事务不会立即失败。它会进入等待状态，等待前一个事务释放锁。这个等待时间是有限的，通常最多为 10 秒。如果在超时时间内锁被释放，你的事务会继续执行。如果超过了等待时间，锁仍未被释放，Salesforce 会终止你的事务，并抛出一个致命的 System.QueryException，错误消息为 "UNABLE_TO_LOCK_ROW"。这是我们作为开发者必须妥善处理的关键异常。

4. 父子记录锁定 (Parent-Child Locking)

在处理具有主从关系 (Master-Detail) 或查找关系 (Lookup) 的记录时，情况会更复杂。当你更新一个子记录时，Salesforce 通常也会在父记录上放置一个锁，以防止在子记录更新期间，父记录被删除或修改，从而导致数据不一致（例如，汇总字段的计算）。这种行为被称为“父锁”(Parent Lock)。在高并发下，对不同子记录的更新可能会因为试图锁定同一个父记录而导致锁争用，这是一种常见的性能瓶颈，称为 Parent-Child Lock Contention (父子锁争用)。

因此，使用 FOR UPDATE 是我们主动控制数据完整性的主要手段。它将数据并发问题的处理从“听天由命”变成了“主动管理”。

示例代码

处理记录锁定的最经典示例是银行账户转账。我们需要确保从一个账户扣款并向另一个账户存款这两个操作是一个原子操作。如果在我们读取账户 A 的余额后，准备扣款前，有另一个事务修改了账户 A 的余额，我们的整个计算就会出错。使用 FOR UPDATE 可以完美解决这个问题。

以下示例代码直接取自 Salesforce 官方 Apex 开发者指南，演示了如何安全地在两个账户记录之间转移资金。

场景：从一个账户向另一个账户转移 100 元。

public class TransferBalance {
    public static void transfer(Id fromAcctId, Id toAcctId, Decimal amount) {
        // 定义一个保存点，以便在发生错误时可以回滚事务
        Savepoint sp = Database.setSavepoint();
        try {
            // 步骤 1: 查询并锁定两个账户记录
            // 使用 FOR UPDATE 子句来获取这两个账户记录的排他锁。
            // 这确保了从查询到 DML 操作完成期间，没有其他事务可以修改这两个账户。
            // 将记录按 ID 排序是一种避免死锁 (Deadlock) 的最佳实践。
            List<Account> accts = [SELECT Id, Name, Balance__c 
                                 FROM Account 
                                 WHERE Id IN :new List<Id>{fromAcctId, toAcctId} 
                                 ORDER BY Id
                                 FOR UPDATE];

            Account fromAcct;
            Account toAcct;

            // 识别出款账户和收款账户
            for (Account acct : accts) {
                if (acct.Id == fromAcctId) {
                    fromAcct = acct;
                } else {
                    toAcct = acct;
                }
            }
            
            // 步骤 2: 检查余额并执行业务逻辑
            if (fromAcct.Balance__c >= amount) {
                fromAcct.Balance__c -= amount;
                toAcct.Balance__c += amount;
                
                // 步骤 3: 执行 DML 更新操作
                // 此时，由于记录已被锁定，我们可以安全地更新它们。
                update new List<Account>{fromAcct, toAcct};
            } else {
                // 如果余额不足，可以抛出自定义异常
                System.debug('Insufficient balance.');
                throw new DmlException('Insufficient balance to transfer.');
            }

        } catch (Exception e) {
            // 步骤 4: 错误处理
            // 如果发生任何异常（包括 QueryException: UNABLE_TO_LOCK_ROW），
            // 回滚到保存点，撤销所有 DML 操作。
            Database.rollback(sp);
            
            // 可以在这里记录错误日志或向上抛出异常
            System.debug('An error occurred during transfer: ' + e.getMessage());
            throw e; 
        }
    }
}

在这个例子中，FOR UPDATE 是核心。它保证了从我们查询账户余额到我们更新账户余额的整个过程中，这两个账户记录是“与世隔绝”的，从而确保了转账操作的正确性。

注意事项

虽然 FOR UPDATE 非常强大，但错误地使用它也可能导致性能问题和新的错误。以下是开发人员必须牢记的几个关键点：

1. 必须处理 `UNABLE_TO_LOCK_ROW` 异常

在高并发系统中，锁争用是正常的，而不是意外。因此，你的代码必须将 SELECT ... FOR UPDATE 查询放在 try-catch 块中，并捕获 System.QueryException。在 `catch` 块中，你需要定义一个回退策略。简单的策略是向用户显示一个友好的错误消息，提示他们稍后重试。更复杂的策略可以包括将操作放入一个队列（如 Queueable Apex），在稍后进行异步重试。

2. 保持事务简短

记录锁的持续时间等于事务的持续时间。一个持有锁的长时间运行的事务会阻塞其他许多需要访问这些记录的事务，从而严重影响系统性能。最佳实践是：尽可能晚地获取锁（即在 DML 操作之前立即执行 FOR UPDATE 查询），并尽快完成事务。避免在持有锁的事务中执行 Callout，因为 Callout 会在执行前提交事务，这可能会导致锁被提前释放，或者在 Callout 后无法再执行 DML。

3. 避免死锁 (Deadlock)

当两个或多个事务相互等待对方释放锁时，就会发生死锁。例如，事务 A 锁定了记录 1 并等待记录 2，而事务 B 锁定了记录 2 并等待记录 1。为了避免这种情况，一个公认的最佳实践是以一致的顺序锁定记录。最简单的方法是按记录的 ID 升序排序，就像上面示例代码中的 ORDER BY Id 一样。这样可以确保所有事务都以相同的顺序请求锁，从而打破死锁的循环等待条件。

4. 注意 Governor Limits

SELECT ... FOR UPDATE 仍然是一个标准的 SOQL 查询，它会消耗你的 SOQL 查询 Governor Limit（同步 Apex 中为 100 个）。在复杂的逻辑或循环中要小心使用，确保不会超出限制。

5. 了解锁的粒度

锁是作用在行级别的。但如前所述，对子记录的更新可能会升级为对父记录的锁。在设计数据模型和业务逻辑时，要充分考虑这种锁升级的可能性，尤其是在大量子记录关联到同一个父记录的场景中，这很容易成为性能瓶颈。在可能的情况下，尝试将更新分批处理或分散到不同的父记录下，以减少争用。

总结与最佳实践

记录锁定是 Salesforce 平台提供的用于保障高并发环境下数据完整性的核心机制。作为 Salesforce 开发人员，熟练掌握 SOQL FOR UPDATE 子句的用法是编写企业级健壮应用的基础。

总结一下，最佳实践包括：

仅在必要时使用： 不要滥用 FOR UPDATE。只在你需要以“先读后写”模式原子性地更新记录，并且存在真实的数据争用风险时才使用它。
最小化锁持有时间： 将你的事务设计得尽可能快和高效。在事务中，将 FOR UPDATE 查询放在紧邻 DML 操作之前执行。
优雅地处理锁异常： 始终准备好捕获 UNABLE_TO_LOCK_ROW 异常，并为用户或系统提供明确的重试逻辑或错误反馈。
按顺序加锁以防死锁： 在一个事务中需要锁定多条记录时，始终以一个确定的顺序（如按 ID 排序）来查询和锁定它们。
关注性能影响： 意识到记录锁定会降低系统的并行处理能力。在性能测试期间，要特别关注高频更新对象上的锁争用情况。

通过遵循这些原则，你可以有效地利用 Salesforce 的记录锁定功能，构建出既能处理复杂业务逻辑，又能在多用户环境中保持数据高度一致性的强大应用程序。

Salesforce中文网