2026-09-03 一卡通源端每批 2000 人与内存边界变更记录
变更结论
一卡通源端人员拉取由每批 1000 人调整为每批 2000 人；向业务端服务器上传仍固定每批最多 1000 条。一卡通单批读取超时调整为 60 秒，连接超时仍为 8 秒。
当前架构下不建议将源端单批数量设置为 3000 人及以上，除非目标设备完成全量峰值内存验证。60 秒读取超时只约束单个 SOAP 请求，不限制整轮同步耗时，也不会降低内存峰值。
参数边界
| 环节 | 当前值 | 定义位置 | 说明 |
|---|
| 一卡通源端拉取 | 2000 人/批 | CustomerFullFetchService.SOURCE_PAGE_SIZE | 本次调整项 |
| 业务端上传 | 1000 条/批 | SyncPersonsRequest.MAX_ITEMS | 接口固定上限，不修改 |
| 一卡通连接超时 | 8 秒 | CONNECT_TIMEOUT_MS | 不修改 |
| 一卡通读取超时 | 60 秒 | READ_TIMEOUT_MS | 单个 SOAP 请求 |
- 26,089 人的源端分页为 13 × 2000 + 89，共 14 次请求。
- 业务端分页仍为 26 × 1000 + 89，共 27 次请求。
内存风险依据
- 一次请求 26,089 人曾在约 192 MB Java 堆上因约 75 MB 字符串分配发生 OOM。
- 1000 人 SOAP 响应最大约 146 万字符；线性估算 2000 人约 292 万字符，3000 人约 438 万字符。
- 3000 人的 UTF-16 XML 字符串本身约 8.76 MB，尚未包含字节缓冲、DOM、字段对象和已累计人员列表。
- 当前实现整包读取 XML，并在校验和人员提取阶段执行两次 DOM 解析。
- 3000 人单批瞬时新增内存保守估算约 45～90 MB；GC 不及时可能更高，此数值并非目标设备实测。
- 从 2000 提升到 3000 只减少 5 次源端请求，却让单页相关瞬时内存增加约 50%。
决策：默认值采用 2000；3000 人及以上必须重新评审并完成目标设备真机验证。
代码与测试调整
- 源端分页保持
SOURCE_PAGE_SIZE = 2000，代码注释固化内存边界。
- 一卡通读取超时保持 60 秒，并明确其只作用于单个 SOAP 请求。
- 2601 人测试调整为 2000 + 601；26,089 人调整为 13 × 2000 + 89，共 14 页。
- 跨页重复校验边界调整到第 2001 人。
- 业务端每批 1000 条的实现和测试均未修改。
验证结果
- Corretto 8（
1.8.0_482）运行 CustomerFullFetchServiceTest：5 个测试通过，0 failure、0 error、0 skipped。
- 分页、游标、进度、超量响应和跨页重复校验已有代码级覆盖。
- 2000 人单批尚未完成目标设备 26,089 人全量峰值内存验证，不能表述为已证明不会 OOM。
真机验收建议
- 连续完成至少 3 次 26,089 人全量同步。
- 确认
sourcePageSize=2000、源端共 14 批且全量核数一致。
- 记录每批响应字符数、耗时和 Java Heap 峰值。
- 若接近 192 MB 堆上限或出现频繁 GC、卡顿、OOM，立即退回 1000 人/批。
Git 状态
源码分支 shorten_sync_time；未暂存、提交、推送、合并或切换分支；记录不包含生产凭据或人员数据。