05.11 优化边界：从少复制到池化、批量与可维护性
返回第五卷 · 对象前置：05.06 · GC 前置：05.07 · 并发组合前置：05.08 · 性能证据前置：05.10
05.11 优化边界：从少复制到池化、批量与可维护性
DeepTutor 初稿经技术与教学审阅后的静态课程。群规模、对象大小、批量和优化结果均为纸上候选；没有运行 Go、基准、IM 服务或站点。本章不声称 OpenIM 逐目标复制、使用特定池或批量接口，也不把数值推导当进程 RSS 或实际吞吐。
一、优化前先列出不能改变的 IM 合同
05.10 已要求同样的 10000 目标负载才谈收益。这里固定虚构 c-g 群消息：教学基线假设为每个目标独立复制 1 KiB 正文数据，10000 目标产生 10000 KiB≈9.77 MiB 纯数据。这可能提示复制成本，但不能从这张账直接说 CPU、P95 或 GC 一定由复制主导；需要 05.10 的 profile/trace 与同负载证据。
在改设计前，写明不能被速度优化偷换的合同：发送者及群成员权限不能泄露给别的目标；c-g 序号和每目标结果身份可复核；取消、超时与慢设备的已接纳、未接纳、失败、未知仍可区分；应用内排队不冒充数据库持久、TCP 接收或设备展示。若候选让消息内容串改、误发越权目标或丢失失败状态，即使纸上字节数变小也不成立。
| 第一遍 | 第二遍 | 交付物 |
|---|---|---|
| 基线与不可变合同、少复制、批量 | sync.Pool 所有权、局部性、unsafe/无锁门槛与回退 | 四候选对照、对象所有权图、同负载证据表 |
本章比较候选方案，不实现实际服务。05.09 的并发/故障验证和 05.10 的工具选择是每次候选评审的必要前置，不能先选“最快技巧”再补正确性定义。
二、少复制：共享不可变正文，目标身份仍要独立
如果 1 KiB 正文对所有目标完全相同，教学候选可保存一份不可变正文，每目标只保留一份 32 字节的独立目标元数据（目标 ID、状态/索引等只是纸上预算）。纯数据账为 1 KiB + 10000×32 B = 1 KiB + 312.5 KiB = 313.5 KiB。与基线约 9.77 MiB 比，逻辑数据量大幅减少，但真实 Go 对象头、切片、队列、TLS/网络封套和编码缓冲未计；不能把 313.5 KiB 宣称为 HeapAlloc 或 RSS。
| 策略 | 纸上纯数据 | 必须另外处理 |
|---|---|---|
| 每目标独立 1 KiB 副本 | 约 9.77 MiB | 分配、复用与排队 |
| 共享不可变 1 KiB + 每目标 32 B | 313.5 KiB | 目标权限/设备封套、引用生命周期、并发只读 |
共享只适合真的相同且不再修改的部分。 群成员、设备、撤回可见性、加密上下文、发送结果等若因目标而异，必须分别计算和授权；不能把一个完整可变“消息对象”无条件复用给所有目标。若一名工作者还在写某共享 []byte、另一名工作者同时读它，会有数据竞争或内容串改。即便把切片改成容量受限视图，05.06 已说明它可能继续保留整块大底层数组；“零复制”还要核对对象存活时长。
三、sync.Pool：借还临时对象，不是一个可靠容量仓库
Go 官方把 sync.Pool 定义为可供并发使用的临时对象缓存。放进去的项可被运行时随时移走而不通知，Get 也可能忽略之前 Put 的项并返回新对象或 nil（依是否设置 New）。因此 Pool 不提供“这 100 个缓冲永远保留”“Get 一定取回刚放的那个”或有界容量的业务合同。它可用于减少某些重复分配，不能存放需要持久追踪的消息或唯一状态。
用虚构的编码 scratch 缓冲画所有权：
Pool.Get → 当前工作者独占借用 → 重置/编码 → 确认所有异步消费者已不再引用
→ 按数据边界清理 → Pool.Put → 原工作者不再读写最危险的变式是把缓冲切片交给慢设备的异步发送队列，随后立刻 Put 回池。另一工作者取得同一底层数组并写下一条消息，旧目标可能收到被覆盖的内容；并发读写还可能触发数据竞争。Reset 常只重置逻辑长度，未必清零旧敏感字节；跨用户复用时须按权限与数据保密边界清理实际可见部分。池里若留着偶发巨大缓冲，又可能提高长期保留量；应设可接受容量或不归还过大项，并用 alloc_space/inuse_space/RSS 验证。
先有借用结束的明确时刻，才考虑 Pool；没有所有权证明，减少分配并不是合格优化。Pool 的命中率、对象保留和收益也不能从 API 名称推断，需在固定负载中测量。
四、批量和局部性：减少固定开销会改变等待与失败粒度
另一候选是把目标任务提交到同一个后台批处理接口。若该接口允许每批 100 项，10000 个目标会形成 10000/100=100 批；相比逐项调用，可能减少每次调用的固定开销。但要凑批、保留一批数据、处理部分成功/部分失败，并按目标 ID 回填结果。批次失败不能随手把 100 个目标全标成功；批量等待也可能拉高低负载时的尾延迟。必须设置最大条数、最大字节和最大等待时间三个界限。
这绝不表示 10000 个不同设备 socket 可以用“一次 write”送完：各 FD、流控、TLS 和确认点不同。这里批量的是同一后台接口的目标任务，最终对设备的写入仍有各自的部分写与失败状态。若后端根本没有批量语义，纸上 100 批不对应任何可实现操作。
局部性也需按访问模式讨论：连续切片扫描可比指针追逐更容易利用缓存，但若业务主要是按 ID 精确查找，换成切片也可能增加扫描或插入成本。02.01–02.05 已建立算法与内存局部性的前置；此处只有“可能影响 CPU”的机制假设，不靠容器名称断言真实服务变快。任何布局变更还要确认指针稳定性、可见性、更新并发和 GC 扫描成本。
五、unsafe 与无锁：复杂度也要写进预算
unsafe.Pointer 可绕过 Go 类型系统，涉及布局、对齐、别名和 GC 指针规则；官方文档明确要求极慎使用，go vet 没报问题也不是代码有效的证明。为省一个拷贝就改用 unsafe，若没有清楚的输入边界、版本/架构测试和持续维护者，往往把可见分配换成难审阅的正确性风险。
“无锁”也不能只看名字。一个 atomic.CompareAndSwap 只在目标位置上做条件替换；若会话状态还涉及成员权限、消息序号、队列和数据库，它不能把这些字段/副作用一起提交。CAS 循环在竞争下还可能大量重试、增加 CPU 并影响公平性；ABA、内存回收及状态版本也需要专门推导。05.04 已给单字段 atomic 与多字段业务不变量的边界；没有证明锁本身是已测热点前，先试缩短临界区或调整所有权。
| 候选 | 先要求什么证据 | 新增维护责任 |
|---|---|---|
| 少复制/共享正文 | 分配或拷贝确是热点 | 不可变性、目标差异和生命周期 |
sync.Pool | 短命分配有成本且对象可安全借还 | 清理、异步所有权和大缓冲保留 |
| 同后台批量 | 固定调用开销可观且后端支持批量 | 部分结果、批大小/等待与重试 |
| unsafe/无锁 | 简单方案仍有实测瓶颈 | 类型/内存不变量、平台和版本验证 |
六、同负载对照与回退：收益不能只看一个 P95
设评审对象始终是10000 目标、每秒 20 条相同类型群消息、约 5% 慢设备的纸上负载；旧方案 P95 300 ms 只是 05.10 的教学基线。候选方案的结果都标“待学习者实测”，不先编出成功数字。每次只改一个主要机制，保持 Go 版本、机器、消息大小、权限数据与观察时间窗相同；采样工具开销也应记录或隔离。
| 验收 | 旧方案 | 候选 | 不合格/回退信号 |
|---|---|---|---|
| 权限、目标身份、seq 与结果状态 | 已定义的教学合同 | 必须相同 | 越权、串改、乱序或未知被误报成功 |
| P95/P99 与吞吐 | 300 ms P95（纸上） | 待测 | 同负载尾延迟恶化或吞吐下降 |
CPU、alloc_space | 待测 | 待测 | 分配降了却 CPU/锁争用大幅增加 |
inuse_space、RSS、队列长度 | 待测 | 待测 | 池或批次长期保留更多内存、接近容量 |
| 错误、取消和慢设备处理 | 需负例证据 | 需重验 | 短写丢数据、取消不退出、部分失败无法定位 |
“优化前后相同负载”不意味着一次测量足够：还要有相近样本量、重复窗口和波动范围。若共享正文减少分配，却使一份缓冲被异步消费者修改；若池化降低 GC，却把 P99 拉高；若批量减少后台调用，却让部分目标失败不可追踪，结论都应拒绝或回退。性能收益、正确性和维护成本必须同时成立。
七、四候选的失败变式：先能反驳自己的想法
| 变更 | 纸上最小反例 | 应追加的检查 |
|---|---|---|
| 共享正文 | 某目标修改原 []byte 后，其他目标看到被污染内容 | 写入后不可变或独立复制、并发读写规则 |
| 池化缓冲 | Put 后异步发送者仍握有切片，下一借用者覆盖 | 借还时点、最后引用与 race/内容断言 |
| 批量 100 | 其中 1 个目标失败，却只返回“批成功” | 每目标结果 ID、失败分支与重试身份 |
| 连续布局 | 为了扫描快换结构，按 ID 查询退化 | 读写比例、规模、访问模式与同负载对照 |
| unsafe/无锁 | 指针在 GC/架构变化下不满足前提，或 CAS 在争用下重试过多 | 内存模型、版本/架构边界、维护责任 |
如果 05.10 的 CPU/heap/mutex/block/trace 证据没有显示复制、分配、锁或批量调用是问题核心，先回到慢设备、数据库、网络或队列等待假设，不必为“技术先进”加入池、unsafe 或 lock-free。优化应该让可解释的瓶颈更小，并保留失败时可回退的路径。
八、交付优化评审与分层练习
学习者交付：重算 10000×1 KiB≈9.77 MiB 与 1 KiB+10000×32 B=313.5 KiB 的纯数据账；画出池借用到最后异步消费者退出的所有权；把 100 个批次各自的目标 ID/部分结果列成状态表；为 unsafe/无锁说明哪项热点证据无法由简单方案解决。最后留下同 10000 目标负载的待测字段与回退门槛，不能报告本章不存在的运行收益。
分层练习：先答，再展开反馈
1. 10000 目标各复制 1 KiB，纯数据约多少 MiB？
10000 KiB≈9.77 MiB，未计其他内存和协议开销。
2. 每目标 32 B 元数据共多少 KiB？
320000 B=312.5 KiB。
3. 再加一份共享 1 KiB 正文，总纯数据是多少？
313.5 KiB；不是 HeapAlloc 或 RSS。
4. 可把每目标权限与设备封套也无条件共享吗？
不能。与目标身份/可见性相关的数据必须分别校验和保存。
5. 共享可变 `[]byte` 让两个 worker 一读一写会怎样？
可能数据竞争与内容串改；共享部分应不可变或另外同步。
6. `sync.Pool.Put` 后还可继续使用对象吗？
不应。所有权已归还，其他调用者可能取得并修改它。
7. `Pool.Get` 保证取回刚才放的对象吗？
不保证。运行时可丢弃池项，Get 也可按 API 规则返回别的值。
8. `sync.Pool` 能当稳定的容量为 100 的缓存吗？
不能。它不提供固定保留数量或持久业务状态。
9. `Reset` 缓冲逻辑长度就保证旧用户字节被清零吗？
不保证。按敏感数据的实际可见范围清理并验证所有权。
10. 异步写入还在用缓冲时能 Put 回池吗？
不能，须等最后使用者结束或改用独立副本。
11. 批大小 100、目标 10000，纸上需要多少批？
100 批，前提是同一个后台接口支持这种批量操作。
12. 10000 个不同 socket 能由一次普通 write 全部发送吗？
不能。每个连接有自己的 FD、流控与结果边界。
13. 一批 100 项中有 1 项失败，可以只返回“批成功”吗？
不应。须能把目标身份和部分失败逐项对应。
14. 凑批可能增加哪类时延？
等待批次形成的排队时延，尤其低负载或慢目标时。
15. 连续切片扫描一定比 map 点查快吗？
不能一概而论。访问模式、规模、更新与局部性都要同负载测量。
16. `unsafe.Pointer` 让 go vet 安静就证明有效吗？
不能。官方文档明确说无警告不是正确性的保证。
17. CAS 一个标志能同时提交成员表、消息和队列吗？
不能。CAS 只管理目标原子位置，跨对象/持久副作用另有协议。
18. GOMAXPROCS 或无锁改写可替代未证明的锁热点吗？
不能先假定有效。应先找出真实瓶颈和更简单的保护范围改法。
19. 旧方案 P95=300 ms、候选“待测”，能报告改善比例吗？
不能。没有候选实际结果，不能编造收益。
20. 分配下降但队列、RSS 和 P99 同时上升，就可宣布优化成功吗？
不能。可能把短命分配换成了长期积压或等待。
21. 一次改变共享、池化和批量三处，有何解释困难？
无法把收益或退化可靠归因于哪项变化，应逐项对照。
22. 本章纸上 313.5 KiB 能证明真实 OpenIM 内存吗？
不能。它只在虚构目标大小与共享策略前提下成立。
来源与下一步
- Go
sync.Pool官方文档与Go GC 指南：临时对象复用、可丢弃池项及分配/存活取舍。 - Go Slices 使用与内部：切片别名和底层数组保留。
- Go
unsafe与sync/atomic：绕过类型边界和单位置无锁原语的约束。 - Go 诊断指南：同口径 profile/trace 与采样扰动。
按学习路线，下一章05.12 并发服务复盘将把慢设备、大群积压、取消失效和退出失败放进一份并发服务复盘。离开本章前，应能为任何“优化”同时交代不变的业务合同、预计资源账、真实热点证据、失败反例和回退条件。