返回数组数据结构元素给调用程序的并发友好优化方案咨询

原方案痛点梳理：

1. 固定大维度数组传参方案：内存浪费严重，50个调用程序仅部分需要数组数据，每次传递9999维固定长度数组会产生不必要的内存开销，同时受系统单参数最大长度限制
2. QTEMP临时文件方案：单Job隔离性好，但高并发下频繁的磁盘I/O操作会拉低整体性能，大量Job同时创建/读写/删除临时文件也会增加系统临时存储的调度压力

方案1：按需动态数组参数传递 #

• 核心逻辑：仅给需要数组数据的调用程序传递动态长度数组，不需要数组的调用程序保留原有入参结构即可
• 实现要点：
  • 入参中增加*是否需要返回数组*的标识位，由调用方主动告知是否需要返回数组数据
  • 数组采用VARYING/动态维度定义，仅返回实际存在的元素个数，不需要传递9999维的固定长度
• 优势：无额外I/O开销，性能最优，天然支持并发，不需要额外的资源清理逻辑
• 适用场景：数组元素总大小不超过系统参数限制的单参数最大长度（IBMi平台默认单参数最大长度可支持到16M，绝大多数业务场景足够覆盖）

方案2：用户空间（User Space）对象传递 #

• 核心逻辑：在系统内存中创建用户空间对象存储数组数据，仅把用户空间的名称/访问指针传递给调用程序，调用程序直接从内存读取数据
• 实现要点：
  • 按需创建用户空间，不需要数组的调用程序无需创建对应对象
  • 可设置用户空间的过期自动清理规则，也可由调用方读取完成后主动删除
  • 支持跨Job访问，也可设置权限控制仅指定Job访问，避免数据串用
• 优势：读写都是内存操作，性能远高于QTEMP临时文件，支持大体积数组存储，并发访问性能优异
• 适用场景：数组体积大、超过参数传递长度限制，或者需要跨Job共享数据的场景

方案3：共享内存队列 #

• 核心逻辑：用内存队列存储不同调用方的数组数据，调用方凭唯一标识从队列拉取自己需要的数组
• 优势：支持多消费者并发读取，可批量处理多调用方的数组返回需求，适合高并发高频调用的场景
• 适用场景：调用程序并发量极高，数组数据生成频率快的业务场景

如果数组最大体积不超过16M，优先选动态数组按需传递方案，实现最简单性能最好；如果数组体积超过参数长度限制，优先选用户空间方案，实测并发场景下性能比QTEMP临时文件高30%以上。

内容的提问来源于stack exchange，提问作者Sam K