048、锁对象与锁机制
048、锁对象与锁机制
半夜两点被电话吵醒，客户说那张采购订单保存时卡死了，整个物料主数据都锁住，业务员在电话里急得骂人。我远程一看，SM12里躺着一个大锁，owner是一个早就下线的后台作业，锁了三天没释放。那会儿我刚从C#转ABAP没多久，第一反应是“这锁怎么还能超时？”，后来才明白，ABAP的锁不是数据库锁，它压根不防并发，它防的是你自己人。
先讲一个最坑的场景：你以为写了CALL FUNCTION ‘ENQUEUE_EZPO’，数据就安全了，结果两个用户同时点保存，第二个居然也进去了，数据照样被覆盖。为什么？因为锁对象只是你程序里的一个约定，别人不遵守，锁就是个摆设。你得让所有写这张表的程序都去加同一把锁，否则就是裸奔。
那锁到底锁什么？锁参数里那个表字段的赋值，决定了这把锁的影响范围。比如锁对象里定义了WERKS（工厂）和MATNR（物料）作为锁字段，你传了工厂1000、物料A001进去，那别的会话想锁同样工厂1000、物料A001时就会被拒绝。如果你只传工厂1000、物料留空，那等于把1000工厂下所有物料都锁住，这跟拿大炮打蚊子没区别。好多新手喜欢把键值全填上，觉得锁得越细越好，其实未必，你锁的粒度越细，锁记录越多，SM12里密密麻麻全是你的小锁，管理成本反而高。
锁对象在SE11里创建，激活后自动生成两个函数：ENQUEUE_和DEQUEUE_。创建时注意那个“Lock Mode”下拉框，有E（独占）、S（共享）、X（排他）三种。E是默认的，别人不能再加E或X，但可以加S；S是共享锁，别人还能加S，但不能加E或X；X是排他锁，谁都不能再加任何锁。实际业务里用到X的极少，除非你真的要“我锁了别人连读都不行”。大多数场景用E就够了，别一上来就X，容易把整个系统锁成瘫痪。
加锁调用很简单，但坑都在参数里。那个_SCOPE参数，默认是1，意思是在当前会话内有效，提交工作（COMMIT WORK）时自动释放。如果你设成2，则是提交后仍然保留，直到显式调用DEQUEUE或者会话结束。我见过有人把_SCOPE设成2，然后忘了释放，第二天SM12里全是他留下的僵尸锁，背了生产事故。记住：除非你有跨LUW（逻辑工作单元）的需求，否则永远用默认1。
还有那个_COLLECT参数，默认是空，表示每条ENQUEUE都是独立锁记录。如果你设为X，则相同锁参数的调用会合并成一条，重复使用。这在循环里加锁时特别有讲究——如果循环里反复对同一把锁调用ENQUEUE，_COLLECT设成X能减少锁表记录数，但如果你忘了在循环结束后DEQUEUE_ALL，那锁会一直攒着，直到会话结束。我建议循环里不要频繁加锁，把锁提到循环外面，一次搞定，这才是正解。
解锁函数DEQUEUE_，参数和加锁几乎一样，但有个容易忽视的_BUSTIMESTAMP，只在系统启用RFC安全性检查时才需要填，日常开发全留空就行。DEQUEUE_ALL是Disconnect时自动执行的，但你不能指望系统帮你兜底，程序里异常分支必须自己写CLEANUP，否则一旦程序发生运行时错误，锁还在，别人就干瞪眼。
锁的等待行为：如果你加锁时发现已有冲突锁，函数会直接返回SY-SUBRC = 4，不会自动重试，也不会阻塞。这跟数据库锁不一样，数据库锁是阻塞等待，ABAP锁是“打招呼失败就撤”。所以你得自己写重试逻辑，或者干脆告诉用户“数据正被别人改，稍后再试”。这里踩过坑：很多新手以为ENQUEUE会像数据库UPDATE一样卡住，其实它秒回失败，你判断SY-SUBRC等于0才继续往下走，否则直接EXIT，别傻傻地去查数据。
那锁和数据库锁之间是什么关系？ABAP锁是应用层的锁，锁的对象是逻辑上的业务数据，比如一笔采购凭证。真正写数据库时，数据库自己还有行锁。ABAP锁解决的是“多个对话在多台应用服务器上”的冲突，而数据库锁只在你真正UPDATE INSERT DELETE那一刻生效。如果你不加ABAP锁，A用户读了数据进界面，B用户也读了数据进界面，两人同时保存，后保存的覆盖先保存的，这就是丢失更新。ABAP锁的作用就是让第二个用户压根进不了编辑界面，从源头掐断冲突。
有一次生产系统出现死锁，我查SM12发现两个锁互相等：程序P1锁了表A想锁B，程序P2锁了表B想锁A。ABAP锁没有死锁检测机制，不会自动回滚，只能人工去SM12里删除一个锁才能解开。所以写程序时加锁的顺序一定要全公司统一，比如先锁主数据后锁单据，别这程序先锁单据再锁主数据，那程序先锁主数据再锁单据，早晚要撞车。这个约定得写进开发规范里，靠人自觉不如靠规则强制。
再说锁对象的创建细节。SE11里创建锁对象，维护表时注意选择“Lock Table Entries”选项，通常你只想锁表里的某些行，那就选这个。如果你选了“Lock Entire Table”，那等于整个表被锁，动静太大，除非是配置表一次性重写，否则别这么干。添加表后要勾选“Lock Parameter”字段，这些字段才是锁的主键。字段顺序很重要，第一个字段会生成到ENQUEUE函数的IMPORT参数里作为必填，后面的可选。如果你把MANDT客户端字段也设成锁参数，那你就把整个客户端的数据全锁了，妥妥的生产事故。新建锁对象时系统会自动带上MANDT，但默认不在锁参数里，你千万别手贱去勾。
调试问题切入：一次用户报错说“物料主数据被用户张三锁定”，但张三明明下班了。我SM12一看，张三的锁还在，锁创建时间是上午十点，张三的会话中午就断了。原来张三的程序里有一个更新函数（UPDATE TASK），它的锁是独立于主程序会话的，_SCOPE参数如果设成2，或者更新函数里又调用了ENQUEUE，锁就会挂到更新任务里。更新任务执行完会自动释放，但更新任务如果失败重试，锁就一直留着。后来我们检查发现是更新函数里逻辑错误，导致更新任务不停重试，锁就死守不放。从那之后我要求所有涉及更新任务的锁，必须在更新函数里显式解锁，并且更新失败时用ROLLBACK WORK来让系统清理锁，别指望后台自动释放。
写到最后，给点个人经验。第一，锁对象是团队契约，不是个人工具，新增一个锁对象前，先查一下已有的锁对象和表是否重复，别整出两把锁来管同一个表，那样会互相冲突，而且别人根本不知道用哪把。第二，加锁和解锁必须成对出现在同一个方法里，最好用TRY EXPANDING CATCH，把DEQUEUE放在CLEANUP中，这样无论中间怎么异常都能释放锁。第三，不要在更新功能模块里传锁参数，那玩意跟锁机制是两条线，更新任务有自己的锁管理，乱传容易锁残留。第四，测试锁时用两个SAPGUI会话，一个设置断点停在ENQUEUE之后，另一个去加同一把锁，看返回码是否为4，这招比你自己瞎想靠谱。第五，也是最实在的，遇到锁问题先查SM12，看看是谁的锁、锁的是什么对象、锁了多久，别急着杀进程，先通知owner确认，那些跨天的锁多半是后台作业异常，可以在SM37里检查作业状态再清理。
锁机制这东西，不复杂，但恶心就恶心在它跟业务逻辑纠缠在一起。你把锁加宽了，影响别人；加窄了，自己漏风。每把锁背后都是用户体验和生产安全。别以为调通一个ENQUEUE就完事了，你得多想想，如果程序崩溃怎么办？如果用户中途关屏怎么办？如果更新任务失败怎么办？把这几个问题想清楚，你的锁才是真的锁。