选择仓颉的理由与目标

仓颉自带“全并发标记整理 GC”（fully concurrent, compacting），以极低暂停、低碎片为目标：同步平均耗时通常在数十微秒量级；配合 region-based 的内存整理与 bumping-pointer 分配，既减少碎片又提高分配速度。这些设计决定了我们的调优重点：不是去“压短 STW”，而是把触发时机、并行度与内存水位调到适配你的负载。(仓颉语言文档)

关键调优开关怎么“拨”

仓颉运行时通过一组环境变量暴露调参界面。理解它们的物理含义，等于抓住了性能的方向盘（括号内为默认或范围要点）：

1. cjHeapSize：最大堆（物理内存<1 GB 默认 64 MB，否则 256 MB；可到物理内存上限）。内存富余的服务端可以适度增大，降低回收频率；移动端慎重，避免系统侧压力。(仓颉语言文档)
2. cjHeapUtilization（0,1]，默认 0.8：影响 GC 后“堆水线”的参考值。越小→水线越高→GC 更少，吞吐向；越大→更勤快 GC，延迟向。(仓颉语言文档)
3. cjHeapGrowth，默认 0.15：水线增长率（1+cjHeapGrowth）。增长率↑ 可拉高下一次水线，抑制频繁回收。(仓颉语言文档)
4. cjGCThreshold：绝对水线（超过就 GC）。适合临时“硬闸门”控制，和利用率/增长率共同决定触发。(仓颉语言文档)
5. cjGCInterval（默认 150 ms）/ cjBackupGCInterval（默认 240 s）：两次 GC 的最小间隔 & 兜底间隔。Interval↑ 能消抖，但可能放大尾延迟；Backup 保障“长期不触发”的场景。(仓颉语言文档)
6. cjGCThreads：GC 线程因子，计算公式：(可并发线程数 / cjGCThreads) − 1。CPU 多核、堆大、对象图复杂时，可适度减小该值来增加 GC 线程数，提高标记/整理并行度。(仓颉语言文档)
7. cjProcessorNum：仓颉线程最大并发数（默认=CPU 核数）。与 GC 线程竞争 CPU 时要统筹考虑。(仓颉语言文档)
8. cjRegionSize（默认 64 KB）：thread-local region buffer 大小。小 region 有利于精细回收、降峰值；大 region 降低分配/切换开销，适合批量分配场景。(仓颉语言文档)
9. cjGarbageThreshold（默认 0.5）/ cjExemptionThreshold（默认 0.8）：前者决定“候选回收”的死亡比例阈值；后者是“活对象水线”，超过则不回收该 region，用以降低碎片与移动开销。二者共同决定“回不回、回多少”。(仓颉语言文档)
10. cjAlloctionRate / cjAlloctionWaitTime：限速与等待（默认 10240 MB/s 与 1000 ns）。只有在极端“突发分配雪崩”时才考虑，用于人为节流。(仓颉语言文档)

设计背景补充：全并发 GC 依赖安全点与内存屏障实现应用线程与 GC 的细粒度同步，并采用指针标记与**延迟修复（lazy update）**等策略降低访存与整理成本；堆以 region 切分，允许 from/to 重叠以抑制峰值内存。理解这些有助于你解释“为什么某些参数生效/不生效”。(仓颉语言文档)

两个典型负载的“处方集”

A. 120 Hz 移动端 UI（极致流畅）
目标：掉帧少、输入响应稳。思路是提高回收积极性、控制抖动。
建议起点：

• cjHeapUtilization≈0.85～0.9（更勤快）+ 适度降低 cjHeapGrowth（如 0.1），让水线增长温和；
• cjGCInterval 维持 120～180 ms，观察是否与 UI 帧节律形成“拍频”；
• cjRegionSize 维持默认或略降，提升细粒度整理；
• cjGarbageThreshold 提高到 0.6～0.7，优先回收“脏” region；
• 保持 cjGCThreads 默认，除非监控到 GC CPU 饱和。
  这样做的逻辑是：更频繁但更短、更可预测的并发回收，配合仓颉的微秒级同步，能把抖动控制在可感知阈下。(仓颉语言文档)

B. 服务端高并发（吞吐与尾延迟平衡）
目标：压低 p99 延迟，同时不牺牲吞吐。
建议起点：

• cjHeapSize 适度放大（例如可用内存的 30%～50%），并把 cjHeapUtilization 降到 0.7～0.8、cjHeapGrowth 提高到 0.2～0.3，延后回收以换吞吐；
• 若标记/整理耗时偏长，降低 cjGCThreads 取值（从 8→4 等）以增加 GC 线程数量；
• cjGCInterval 放宽到 200～300 ms，cjBackupGCInterval 维持默认；
• 对象生命周期短、爆发分配多的链路，可增大 cjRegionSize（128 KB～256 KB）。
  最后用负载回放验证尾延迟是否受“回收波峰”影响，再微调。(仓颉语言文档)

怎么“量化”与“验收”

1. 指标面板：记录堆占用、GC 触发频率/持续时间、回收比率、region 碎片度、分配速率与CPU 使用。
2. 剖析工具：结合仓颉提供的性能分析工具（cjprof 等）与火焰图/系统 perf，对比不同参数组合下的分配热点、屏障开销与GC 并行阶段耗时，定位真正的瓶颈路径与内存形态。(仓颉语言文档)
3. A/B 与回放：生产前用一致的工作集做 A/B；移动端用滑动/动画/解析等确定性脚本回放；服务端用压测回放真实流量 burst。
4. 止损线：设定 p99 延迟与峰值 RSS 的红线，跑超立即回滚参数，而不是继续“加码”。

一些实战坑点（经验谈）

• 只调 HeapSize 往往治标不治本：水线（Utilization/Growth）与阈值（GCThreshold/Interval）是触发逻辑核心，必须联动。(仓颉语言文档)
• 盲目加 GC 线程 可能与业务线程争核，反而抬高尾延迟。先看 CPU 饱和度，再决定是否“给 GC 加班”。(仓颉语言文档)
• RegionSize 过大 会让小对象 workload 回收粒度变粗，易形成“半满半空”的碎片印象，吞吐虽高但尾延迟放大。(仓颉语言文档)
• 忽略屏障成本：高写密度结构（如频繁指针更新的队列/池）会放大屏障路径，调参前先从数据结构设计入手（不可变/值类型/批处理更新）。(仓颉语言文档)