CL_ABAP_PARALLEL并行处理实战与调优

1. 为什么批量处理慢，根因不在数据量

很多人一遇到大批量数据更新就下意识认为是数据库慢，实际上数据库这一层往往并不是真正的瓶颈。真正拖垮整个任务的是“串行”本身：一条一条地读、一条一条地算、一条一条地写，单挑整个流程，任何一步网络抖动或锁等待，都会让后面的数据全部堵住。这就像一个人搬一百箱货，不管箱子多轻，来回跑一百趟的时间摆在那里，和仓库大小没关系，瓶颈在“只有一个人”。

我第一次接触 CL_ABAP_PARALLEL 是在一个库存调整项目里，当时要一次性处理 80 万条物料凭证，单会话跑了一个多小时还没结束，用户那边早就等得不耐烦了。后来改用 CL_ABAP_PARALLEL 把数据切分成块，分发到多个对话进程并行处理，整个任务被压缩到十分钟以内。这个速度差异不是算法优化带来的，而是“用人多了”。

但这里必须说清楚：CL_ABAP_PARALLEL 不是真正意义上的“多线程”。ABAP 每一个会话只能跑一条逻辑流，并行只是把数据分给多个进程，每个进程独立跑同一段代码，跑完再把结果汇总回来。本质上是“多进程 + 数据分片 + 结果合并”的套路。理解这一点非常重要，因为很多人在设计并行任务时，总是想着共享内存、锁数据，结果反而踩坑。

CL_ABAP_PARALLEL 更适合什么样的场景？独立的、无状态的、可以分段处理的业务操作。比如批量过账、批量更新状态、批量发送消息、批量调用第三方接口。这类任务每一条数据之间没有先后依赖，随便切成多少块，各跑各的，最后汇总失败信息和处理结果就行。反过来，如果两条数据之间有业务逻辑依赖，比如后一条要等前一条生成的内码才能落库，那就不适合并行，硬用只会更糟糕。

2. 先弄懂 CL_ABAP_PARALLEL 的资源模型，再谈优化

2.1 对话进程不是无限的，先看清楚家底

CL_ABAP_PARALLEL 跑的是“并行对话进程”，它依赖的是应用服务器的可配置工作进程。一个 ABAP 实例上通常会配置三种工作进程类型：对话、后台、更新。每种进程的数量在事务码 SM50 里看得一清二楚。如果要跑并行对话进程，就得保证系统里还有空闲的对话进程可用，否则并行任务只会排在那里发呆。

这里有个很容易被忽略的点：生产系统里对话进程往往被大量在线用户占用，你根本抢不到多少空闲进程。所以我通常会先看 SM50，确认当前空闲进程数量再决定并行度。如果高峰期只有 3 个空闲对话进程，你非塞进去 10 个并行任务，多出来的 7 个不会立刻报错，而是进入等待，反而让整批任务的时间更长。

有个经验值可以分享：并行度一般设置成“当前空闲进程数 - 1”，留一个进程做兜底。比如空闲对话进程 10 个，就设 9 个并行度。别贪多，进程太多会带来额外的上下文切换和数据传输开销，性能不升反降。

2.2 RFC 与内存是隐形约束

CL_ABAP_PARALLEL 的工作方式是把数据块和代码逻辑一起“分发”到其他对话进程中执行。这意味着每一块数据都要通过内部 RFC 或并行 RFC 机制拷贝一次。数据量越大，单块切得越大，网络传输和内存开销就越明显。

按照 SAP 官方最佳实践，单块数据建议控制在 5000 到 10000 条以内。块太小会导致频繁创建会话和销毁，大量时间浪费在初始化上；块太大会让内存峰值暴涨，尤其在多个块同时执行时，内存压力几倍放大。

我曾经遇到过一个场景：把 100 万条数据按 5 万条的块大小分发，结果系统直接报了一个内存不足的错误。原因很简单，5 个进程同时各加载 5 万条数据到内存，加起来的峰值已经超过了单个进程的限制。后来把块大小调到 8000 条，并行度降为 6，问题立刻消失。

所以并行优化的本质不是调一个参数，而是把“数据块大小”“并行度”“内存配额”“会话数”这几个变量同时权衡好。

3. 一个可以直接复制的落地模板

3.1 模板的结构设计

基于 CL_ABAP_PARALLEL 的并行任务，我建议你直接套用下面的四层结构，这样可以避免很多坑：

第一层是“入口层”。负责接收完整的待处理数据，将总数传给第二层，并触发并行调度。第二层是“分片层”。把总数据按照规则切成块，并约定每块的标识。第三层是“执行层”。这里放真正要并行的业务逻辑，比如更新表、调 BAPI、发消息。第四层是“聚合层”。回收每个块的执行结果，统计成功数量、失败明细、耗时情况。

四层结构有一个好处：后续任何一层需要改动，都不会牵连其他层。比如你想把业务逻辑从更新物料状态改成调用服务，只动第三层就够了，不需要重新设计分片策略。

3.2 模板代码框架

这里给一个最小可用的模板，基于 REUSE 方式实现。实际项目中你可以根据自己的版本选择使用 OPEN SQL 或新旧语法，核心逻辑是一样的。

DATA: lt_data TYPE TABLE OF ztest_data, lt_chunks TYPE TABLE OF ztest_chunk. " 入口层：装载全量数据 SELECT * FROM ztest_data INTO TABLE lt_data. " 分片层：按 5000 条一组切块 DATA(ls_chunk) = VALUE ztest_chunk( ). DATA(lv_index) = 1. LOOP AT lt_data INTO DATA(ls_data). ls_chunk-data = ls_chunk-data. APPEND ls_data TO ls_chunk-data. IF lines( ls_chunk-data ) >= 5000. ls_chunk-id = lv_index. APPEND ls_chunk TO lt_chunks. CLEAR: ls_chunk. ADD 1 TO lv_index. ENDIF. ENDLOOP. IF lines( ls_chunk-data ) > 0. ls_chunk-id = lv_index. APPEND ls_chunk TO lt_chunks. ENDIF.

这个切块方式虽然简单，但有一个潜在问题：如果数据本身有主键范围，按顺序切会导致某些块的数据分布不均衡。更稳妥的做法是先按主键分组，再把组打包成块，这样每块的业务数据密度更均匀。

执行层的核心方法可以参照下面的形式：

METHOD process_chunk. LOOP AT is_chunk-data INTO DATA(ls_data). " 这里放真正要执行的业务逻辑 MODIFY ztest_data FROM ls_data. ENDLOOP. ENDMETHOD.

注意这个方法必须是一个实例方法，而且需要定义在公共接口中，否则并行调用时无法通过 RFC 找到执行入口。SAP 的要求是不能把私有方法传给并行任务，这一点很多人第一次跑通代码时会忽略。

3.3 触发并行部分

DATA: lo_parallel TYPE REF TO cl_abap_parallel, lt_results TYPE TABLE OF ztest_result. CREATE OBJECT lo_parallel. CALL METHOD lo_parallel->balanaced_process EXPORTING input = lt_chunks output = lt_results methods = 'PROCESS_CHUNK' config = co_parallel_groups.

注意，co_parallel_groups是一个标准常量，用于指定并行配置。实际项目中我建议创建一个配置表，把并行度、块大小、超时时间存进去，通过入参传入，而不是在代码里写死。这样后续调优并行度时不用改代码，直接改配置就可以。

4. 资源配额到底怎么配，才能不把系统拖垮

4.1 并行度与系统配额的关系

资源配额的“配额”不只是指进程数量，还包括内存配额、CPU 配额和时间窗口。为了不让并行任务抢占在线用户的资源，我建议在系统参数上做两层限制。

第一层是全局限制。可以调整 RFC 服务器的最大并行进程数，通过事务码 SM58 或 RZ12 检查当前的 RFC 服务器配置。如果条件允许，最好单独建一个内部 RFC 组，专门用于并行任务，这样在线用户和并行任务之间有资源隔离，不会互相影响。

第二层是任务内限制。cl_abap_parallel生成的并行任务数可以通过配置文件控制。具体来说，在调用并行方法前，把最大进程数映射到一个自定义的配置项上。我建议在项目里加一张配置表，字段包括：应用服务器名、最大并行进程数、单块数据量、超时时间。每次跑任务前先从表里读配置，再执行并行调用。

这样做的原因很简单：不同服务器的硬件配置不一样，开发机可能只有 4 个对话进程，生产机可能有 20 个。同一套代码在不同环境里能承受的并行度完全不同。硬编码并行度是灾难，放在配置表里才能应环境调优。

4.2 切块策略影响资源峰值

切块策略直接决定内存峰值。有一种很容易犯的错误是：先把全量 100 万条数据全load到内存，然后再切块分发。这样内存峰值就是全量数据的占用，并行优势还没发挥出来，系统先被内存拖垮。

更好的做法是分段读取，边读边切。比如用OPEN CURSOR，每读完 5000 条就形成一个 chunk，立即加入并行任务队列。这样内存里同时只有当前正在处理的几个 chunk，峰值可控。

如果业务数据必须全量加载后再切，那就需要配合内存配额限制，避免内存溢出。可以用SET/GET PARAMETER或者自定义检查，在任务启动前预估数据量与内存余量，不够就提示用户强制部分处理。

4.3 数据更新与锁定配额

并行任务更新同一张表时会产生一个非常头疼的问题：数据库行锁。比如两个进程同时更新同一条物料记录，一个拿到锁，另一个等待，严重的还会死锁导致任务整体崩溃。

我常用的解决方案是把数据按“锁粒度”切块。如果你更新的字段在同一行，那就按主键范围切块，保证同一个主键的块只被一个进程处理。如果更新的是不同表，那就要考虑锁的顺序，统一约定进程内按同一顺序更新，避免交叉等待。

还有一个粗暴但有效的方式：更新时采用“最终一致”模式，不直接更新业务表，而是先记录变更日志，最后统一提交。这种方式可以把锁时间压缩到极短，大幅降低锁冲突概率。不过它不适用于所有业务场景，只有在更新逻辑允许“后统一处理”的前提下才推荐。

5. 超时治理：别让并行任务失控“挂死”

5.1 系统层超时与任务层超时

超时治理是并行任务里最容易踩坑的地方。很多人以为配置了系统 RFC 超时时间就够了，但实际上，任务一旦进入等待队列，RFC 超时未必会触发。更危险的是，有些任务已经执行完成了，但因为结果回收环节卡住，整个程序看起来像挂死了一样。

我一般会在两个层面同时设置超时：

第一层是系统参数。在事务码 RZ11 里查找并调整RFC 相关的超时时间，比如 rdisp/rfc_max_time。这是全局参数，可以限制单个 RFC 调用的最长执行时间。

第二层是代码层。cl_abap_parallel的核心方法并不直接提供“总超时”参数，但可以通过配合 wrapper 方式来实现。具体做法是：在并行任务启动后，循环检查状态，超过预设时间后强制终止任务并进入错误处理分支。

这里给一个简单的时间监控思路：

DATA(lv_start) = cl_abap_runtime=>get_ticks( ). DO. WAIT UP TO 1 SECONDS. IF cl_abap_runtime=>get_ticks( ) - lv_start > lv_max_wait_time. " 超时，取消剩余任务 MESSAGE '并行任务运行超时' TYPE 'E'. EXIT. ENDIF. " 检查结果是否已全部返回 ENDDO.

这个循环只是示例，实际使用时需要配合状态检查方法，否则只是一个死循环。

5.2 设计重试机制与失败补偿

超时之后，最忌讳的事情是“整个任务直接报错退出”。正常设计应该先把已完成的任务结果保存，再对超时或失败的任务块执行重试。重试次数一般不超过 3 次，重试间隔可以按指数退避方式设置，比如第一次等 5 秒，第二次等 10 秒。

失败的数据块不要丢弃，记录到失败日志表里。日志表建议包含以下字段：块 ID、数据范围、失败原因、重试次数、首次失败时间、最后执行时间。这样后续如果要做补偿或重跑，直接查这张表就能定位到失败的那块数据，不需要把整批数据重新跑一遍。

这套补偿机制对于长时间并行任务非常重要。80 万行数据不可能一次成功率 100%，总有网络抖动、数据异常、锁冲突导致部分块失败。如果没有失败记录，就要整批重跑，代价太高。

5.3 监控体系怎么搭

并行任务跑起来之后，如果没有监控，就像闭着眼开车。我常用的监控工具有三个层次：

第一层是事务码 SM37，查看后台任务队列状态。CL_ABAP_PARALLEL 的并行任务通常会在后台组中显示多个任务记录，可以清晰看到每个块对应的任务是否执行成功。

第二层是事务码 SM50，查看当前系统的进程占用情况。如果并行任务正在运行，这里会看到多个对话进程同时处于 Running 状态。如果很多进程都在 Waiting，说明你的并行任务在等待资源，可能需要降低并行度。

第三层是代码层自定义的日志表。我会把每个块的开始时间、结束时间、处理条数、失败条数写进一张自定义日志表。任务跑完以后，可以用一个简单的报表查询各块耗时，快速定位是哪个块出了问题，是数据原因还是锁原因一目了然。

6. 常见问题与排查技巧实录

6.1 任务一直显示 Running，但实际什么都没跑

这种情况十有八九是并行度设置超过了实际可用对话进程数。任务被调度进队列，但找不到可用的对话进程执行，只能排队等待。排查方法是在 SM50 里看是否有一批进程都处于 Waiting 状态，如果是，说明进程池满了。解决办法是把并行度调低，或者在非高峰时段跑大批量任务。

还有一种可能是数据块加载时发生锁等待。某个块需要更新一张被其他程序锁住的表，直接卡在那里。这时候看数据库监控会发现锁住的时间很长，严重时还会死锁。解决方案是简化更新逻辑，缩短单块持有锁的时间，比如把 UPDATE 拆成多次小提交。

我个人的习惯是所有并行任务在启动前先执行一次“心跳预检”，选择一小块数据试跑一次，成功后再放量跑全量。这个预检虽然会花点时间，但能避免很多大坑。

6.2 并行后速度反而变慢了

并行度不是越高越好，这个问题我在多个项目里反复印证过。原因主要有三个方向：

一是网络传输开销。每一块数据都要通过 RFC 传输到目标进程，如果块太小，RFC 调用的次数会非常多，传输开销占比很大。可以尝试把块大小适当调大，比如从 2000 调到 8000，观察耗时变化。

二是进程上下文切换。并行任务过多时，CPU 资源大部分耗在切换上而不是业务处理上。如果你发现 10 个并行任务的累计耗时比 6 个并行任务更久，那就说明并行度太高了。

三是数据库锁竞争。并行任务同时更新同一张表时，锁等待时间会急剧上升。解决办法是减少同时更新的进程数，或者把更新逻辑改成交替批量提交。

6.3 并行任务中调用 BAPI 导致数据不一致

这是最容易踩雷的问题。BAPI 通常会隐式提交或多个 BAPI 之间有内部数据依赖，并行调用时容易导致逻辑顺序被打乱。我的建议是：并行执行层不要直接调 BAPI，而是把 BAPI 参数准备好，在聚合层汇总后，由主进程统一调用 BAPI。这样既保留了并行读取和计算的加速效果，又避免了 BAPI 之间互相干扰。

如果业务场景必须在执行层调 BAPI，那么至少要保证每个数据块之间的 BAPI 互不影响，且单块内的数据量不要跨公司代码或工厂，避免因为 BAPI 内部处理逻辑与公司代码相关参数冲突。

6.4 快速排查速查表

现象	可能原因	检查位置	处理方向
任务排队不执行	空闲对话进程不足	SM50	降低并行度，或错峰执行
系统内存溢出	单块数据量过大或并行度太高	SE37查看调用上下文	调小块数据，调低并行度
执行速度不升反降	网络传输开销或上下文切换多	日志表查看各块耗时	增大块大小、降低并行度
锁等待严重	多个进程竞争同一行记录	数据库监控	按主键分块，或统一更新
部分块长时间无结果	超时机制缺失或系统死锁	SM37	增加超时控制与重试
调用BAPI结果不一致	BAPI有内部状态依赖	日志表比对参数	聚合层统一调用BAPI

7. 再分享一点实际体会

跑并行任务最关键的从来不是把代码写通，而是把它写“稳”。我在生产环境里跑过一次 300 万行的物料分类调整任务，最终采取的策略是每次只让 6 个块并行，单个块 5000 行，总共跑了 11 分钟完成。当时如果盲目把并行度拉到 20，系统可能在第三分钟就内存爆掉，得不偿失。

还有一个小技巧可以分享：并行任务的结果回收不能一次性把所有块的结果都塞进内表等待处理，而是每回来一个块就处理一个块的结果。这样内存占用是“增量”的，而不是“峰值”的，能够有效降低内存压力。这个习惯让我避免了好几次因为结果表过大导致的诡异报错。

最后，无论你的并行任务设计得多完美，一定要先在开发或质量环境用小数据量跑通逻辑，再放大并发度和数据量。并行任务出错很难跟踪，日志表一定不要省，宁可多写几个字段，也不想事后面对一堆不知道从哪里查起的脏数据。