精通 Salesforce 记录锁定：Apex 与 SOQL FOR UPDATE 深度解析

背景与应用场景

作为一名 Salesforce 开发人员，我们日常工作中最核心的挑战之一就是保证数据的完整性和一致性。在一个多用户、高并发的 CRM 环境中，多个用户、自动化流程或 API 集成可能在同一时刻尝试修改同一条记录。如果缺乏有效的控制机制，这种情况极易导致“race conditions”（竞争条件），最终造成数据覆盖、计算错误或业务逻辑中断，严重影响系统的可靠性。

Record locking（记录锁定）正是 Salesforce 平台提供的解决此类问题的关键机制。它通过在事务处理期间临时锁定正在被修改的记录，来防止其他事务对该记录进行更改，从而确保数据操作的原子性和隔离性。简单来说，当一个事务锁定了某条记录后，其他任何想修改这条记录的事务都必须排队等待，直到锁被释放。

以下是一些典型的应用场景，在这些场景中，理解并正确使用记录锁定至关重要：

1. 复杂的汇总计算

想象一个场景：当“订单项” (OpportunityLineItem) 被添加或修改时，需要通过 Apex 触发器实时更新父级“商机” (Opportunity) 上的一个自定义“总金额”字段。如果在短时间内有多个订单项被并发创建（例如，通过 API 批量导入），多个触发器实例会同时尝试读取商机的当前总额，各自加上自己的金额，然后写回。如果没有锁定，后执行的更新会覆盖掉先执行的更新，导致最终的总金额不准确。通过在计算前锁定商机记录，我们可以保证每次计算都基于最新的、未被其他事务干扰的数据。

2. 高并发的 API 集成

当外部系统（如 ERP）频繁地向 Salesforce 推送客户或订单状态更新时，很容易出现数据争用。例如，一个 API 调用正在更新某个客户的联系信息，而几乎同时，另一个 API 调用正在更新该客户的信用等级。这两个操作都需要修改同一条客户 (Account) 记录。显式地锁定客户记录可以确保这些更新被序列化，避免数据冲突。

3. 防止重复创建关联记录

在一个自定义流程中，系统需要检查某个父记录下是否已存在特定类型的子记录，如果不存在则创建一个。这是一个经典的“检查-然后-行动”（check-then-act）模式。如果两个事务同时执行此检查，它们可能都发现子记录不存在，然后都尝试创建，最终导致重复数据的产生。通过在检查之前锁定父记录，可以确保只有一个事务能够成功创建子记录。

4. 序列号或计数器生成

在某些业务场景中，需要为一个对象生成唯一的、连续的序列号。这通常涉及到读取一个“计数器”记录的当前值，将其加一，然后更新回去。这个“读取-修改-写回”的过程必须是原子操作。使用记录锁定可以确保在任何时刻只有一个进程能够更新这个计数器，从而保证序列号的唯一性和连续性。

理解并掌握记录锁定，特别是 Apex 中的 FOR UPDATE 语句，是我们作为 Salesforce 开发人员构建健壮、可扩展应用程序的基石。

---

原理说明

在 Salesforce 中，记录锁定主要分为两种类型：平台自动处理的隐式锁定 (Implicit Locking) 和由开发人员通过代码控制的显式锁定 (Explicit Locking)。

隐式锁定

当你执行标准的 DML (Data Manipulation Language) 操作，如 insert、update 或 delete 时，Salesforce 平台会自动在后台为这些正在被修改的记录加上锁。这种锁定是短暂的，仅在 DML 操作执行期间存在，目的是为了保护数据库的物理完整性。开发人员通常不需要关心这种锁定，但需要知道它的存在，因为它同样可能导致锁定竞争。

此外，在主从关系 (Master-Detail Relationship) 中，当子记录被修改时，其父记录也会被隐式锁定。这是为了确保父记录上可能存在的汇总字段或验证规则能够正确执行。这种父记录锁定是锁定争用 (lock contention) 的一个常见来源，尤其是在子记录更新非常频繁的场景下。

显式锁定 (Explicit Locking)

对于开发人员来说，最有力的工具是显式锁定。在 Apex 中，我们通过在 SOQL 查询语句末尾添加 FOR UPDATE 关键字来实现这一点。当一个事务执行了包含 FOR UPDATE 的查询后，查询返回的所有记录都会被锁定，直到该事务结束（成功提交或失败回滚）。

其工作流程如下：

1. 发起锁定查询：你的 Apex 代码执行一条 SOQL 查询，例如 SELECT Id, Name FROM Account WHERE Id = :accountId FOR UPDATE。
2. 获取锁：Salesforce 数据库尝试为查询到的 Account 记录上锁。
   • 如果记录当前未被任何其他事务锁定，你的事务将成功获得锁，并可以继续执行后续逻辑。
   • 如果记录已被其他事务锁定，你的事务将进入等待状态。
3. 执行业务逻辑：在成功获取锁之后，你可以安全地读取记录的数据，执行复杂的计算或业务逻辑，因为你知道在这期间没有其他事务可以修改这些数据。
4. 执行 DML 并释放锁：当你执行 DML 操作并提交事务（即代码成功执行完毕）或回滚事务（发生未捕获的异常）时，所有被该事务持有的锁都会被自动释放。其他等待的事务此时可以尝试获取锁并继续执行。

如果一个事务等待锁的时间超过了 Salesforce 设定的阈值（通常约为 10 秒），它将放弃等待并抛出一个致命的 QueryException，错误信息通常为 "UNABLE_TO_LOCK_ROW"（无法锁定行）。这意味着你的代码必须准备好处理这种锁定失败的情况。

FOR UPDATE 的核心价值在于，它将“读取”和“写入”两个步骤绑定在一个原子操作中，完美地解决了前面提到的“读取-修改-写回”场景中的并发问题。它确保了从你读取数据的那一刻到你写回数据的那一刻，数据状态是稳定且未被篡改的。

---

示例代码

以下示例来自 Salesforce 官方文档，它演示了在一个更新发票 (Invoice__c) 相关的商品 (Merchandise__c) 时，如何通过锁定父发票记录来安全地更新其总额。假设我们有一个 Apex 触发器，在每次创建或更新商品时，都会重新计算并发票上的总价。

如果没有锁定，当两个商品记录几乎同时被更新时，两个触发器实例可能会读取到相同的旧的发票总额，各自计算后，后一个更新会覆盖前一个，导致总额计算错误。

场景：更新发票总额的触发器

// 这是一个在 Merchandise__c 对象上的触发器
// 当 Merchandise__c 记录被插入、更新或删除时，它会重新计算父 Invoice__c 记录上的总金额
trigger updateTotal on Merchandise__c (after insert, after update, after delete, after undelete) {

    // 存储需要被重新计算的父发票 ID
    Set<Id> invoiceIds = new Set<Id>();

    // 如果是插入或更新操作，收集相关的发票 ID
    if (Trigger.isInsert || Trigger.isUpdate || Trigger.isUndelete) {
        for (Merchandise__c item : Trigger.new) {
            // 确保商品关联了发票
            if (item.Invoice__c != null) {
                invoiceIds.add(item.Invoice__c);
            }
        }
    }

    // 如果是删除操作，从旧记录中收集发票 ID
    if (Trigger.isDelete) {
        for (Merchandise__c item : Trigger.old) {
            if (item.Invoice__c != null) {
                invoiceIds.add(item.Invoice__c);
            }
        }
    }

    // 如果有需要处理的发票
    if (!invoiceIds.isEmpty()) {
        // ********************** 核心锁定逻辑 **********************
        // 查询并锁定所有相关的父发票记录。
        // FOR UPDATE 确保在本事务完成之前，没有其他进程可以更新这些发票记录，
        // 从而避免了并发更新导致的数据不一致问题。
        List<Invoice__c> invoices = [SELECT Id, (SELECT Total_Price__c FROM Merchandise__r) 
                                     FROM Invoice__c 
                                     WHERE Id IN :invoiceIds FOR UPDATE];
        
        List<Invoice__c> invoicesToUpdate = new List<Invoice__c>();
        
        // 遍历锁定的发票
        for (Invoice__c inv : invoices) {
            Decimal total = 0;
            // 遍历该发票下的所有商品，并累加价格
            for (Merchandise__c item : inv.Merchandise__r) {
                total += item.Total_Price__c;
            }
            // 更新发票的总金额字段
            inv.Total_Amount__c = total;
            invoicesToUpdate.add(inv);
        }

        // 如果有需要更新的发票，执行 DML 操作
        // DML 操作完成后，事务结束，记录锁被自动释放
        if (!invoicesToUpdate.isEmpty()) {
            update invoicesToUpdate;
        }
    }
}

在这个示例中，SELECT ... FOR UPDATE 是关键。它确保了在计算总额（读取所有子记录并求和）和更新发票（执行 update DML）的整个过程中，该发票记录是受保护的。任何其他试图修改这张发票的进程都必须等待，从而保证了计算的准确性。

---

注意事项

虽然 FOR UPDATE 是一个强大的工具，但不当使用也可能导致性能问题和新的错误。以下是作为开发人员必须牢记的几个关键点：

1. 锁定竞争与错误处理

最常见的错误是 UNABLE_TO_LOCK_ROW。这并非你的代码逻辑有误，而是系统在高并发下的正常表现。你的代码必须具备处理这种异常的能力。最佳实践是使用 try-catch 块捕获 DmlException 或 QueryException，并检查错误类型。

try {
    // 尝试锁定并更新记录
    Account[] accts = [SELECT Id FROM Account WHERE Name = 'Test' LIMIT 1 FOR UPDATE];
    accts[0].Phone = '555-555-1212';
    update accts;
} catch (DmlException e) {
    // 检查是否为锁定错误
    if (e.getMessage().contains('UNABLE_TO_LOCK_ROW')) {
        // 记录日志或实现重试逻辑
        System.debug('Record is locked, could not update. Consider retrying.');
        // 在某些异步场景下（如 Queueable Apex），可以重新入队任务进行重试
    } else {
        // 处理其他 DML 异常
        throw e;
    }
}

简单的重试逻辑可能并不总是最佳方案，需要根据业务需求设计，例如引入延迟重试或将失败的任务放入一个待处理队列。

2. 性能影响与事务时长

记录锁定会降低系统的并行处理能力。一个持有锁的事务会阻塞其他需要访问相同记录的事务。因此，持有锁的时间应尽可能短。在你的 Apex 事务中，应将 FOR UPDATE 查询尽可能地推后，仅在即将进行关键的读-改-写操作前执行。在持有锁的期间，避免执行耗时操作，如复杂的循环、多次查询，尤其是绝对禁止执行 Callout（因为 Callout 会使事务长时间挂起，极易导致锁定超时和占用大量系统资源）。

3. 死锁 (Deadlock)

当两个或多个事务互相等待对方释放锁时，就会发生死锁。例如，事务 A 锁定了记录 1 并等待记录 2，而事务 B 锁定了记录 2 并等待记录 1。为了避免死锁，必须确保所有代码在需要锁定多条记录时，都遵循一致的锁定顺序。最简单和可靠的方法是按记录的 ID 升序进行锁定。

// 假设 accountIds 是一个包含多个需要锁定 ID 的列表
List<Id> sortedIds = new List<Id>(accountIds);
sortedIds.sort(); // 按 ID 字符串排序，确保一致性

// 按照排序后的 ID 列表进行查询和锁定
List<Account> lockedAccounts = [SELECT Id FROM Account WHERE Id IN :sortedIds FOR UPDATE];

4. API 版本与权限

使用 FOR UPDATE 不需要特殊权限。只要用户有权限查询和编辑相关记录，就可以使用此功能。该功能在所有主流的 Apex API 版本中都得到支持。

---

总结与最佳实践

记录锁定是 Salesforce 开发中保证数据一致性的高级但必不可少的工具。通过 SOQL 的 FOR UPDATE 子句，我们可以有效地解决高并发环境下的数据争用问题。然而，权力与责任并存，不当的使用会带来性能瓶颈和死锁风险。

作为专业的 Salesforce 开发人员，我们应遵循以下最佳实践：

• 精确锁定，而非滥用：只在确实存在并发风险的“读取-修改-写回”场景中使用 FOR UPDATE。对于简单的、独立的更新操作，平台的隐式锁定通常已经足够。

• 最小化锁定范围：在 WHERE 子句中尽可能精确地筛选，只锁定绝对必要的记录。避免锁定大量无关记录。

• 缩短事务周期：将锁定查询放在事务的最后阶段，并确保锁定后的代码执行得尽可能快。避免在持有锁时执行任何耗时操作。

• 建立一致的锁定顺序：在需要锁定多条记录时，始终按记录 ID 排序，这是防止死锁最有效的策略。

• 构建健壮的错误处理：始终准备好捕获并优雅地处理 UNABLE_TO_LOCK_ROW 异常。根据业务场景，考虑实现合理的重试机制。

• 充分测试并发场景：在编写测试类时，需要有意识地模拟并发情况，以验证锁定逻辑和错误处理是否按预期工作。虽然在 Apex Test 中模拟真实并发很困难，但可以通过精心设计的测试数据和事务边界来触发相关逻辑。

最终，对记录锁定的深刻理解和审慎使用，是区分普通开发者和高级开发者的重要标志之一，也是构建企业级、高可靠性 Salesforce 应用程序的关键所在。