06 有界 Channel 与并发容器容量试用安装包下载 | SMS | 在线演示项目地址https://github.com/openskeye/go-vss背景高并发服务中无界队列会在故障或下游变慢时把内存耗尽小队列则频繁阻塞生产者。并发 Map 若频繁扩容也会带来 CPU 与 GC 压力。VSS 在ServiceContext初始化时为 channel 与xmap指定了统一的容量策略。项目中的做法1. 有界 channel多数为 100例如SipSendCatalog、SipSendVideoLiveInvite、WSProc各通道、SipLog等均为make(chan T, 100)。含义背压当SendLogic处理不过来时写入方会阻塞在 send或可选用selectdefault丢弃——当前以阻塞为主依赖上游超时。边界可预期最坏情况下队列中待处理消息条数有上限便于估算内存每条消息指针 负载。满则阻塞生产者HTTP/WS/定时器chan T, cap100消费者SendLogic2.xmap/set初始容量1000 量级如SipCatalogLoopMap、AckRequestMap、PubStreamExistsState、InviteRequestState等使用1000作为预分配 hint具体以service_context.go为准。减少 rehash / 扩容设备与流规模在千级时命中预设桶大小可降低分配次数。xmap不是硬性上限xmap仍可增长若单机万路以上应结合监控观察Len()与内存。长生命周期键高频短消息控制突发排队少扩容buffer 100hint 1000延迟稳定CPU/GC 更稳要点调大 channel信令尖峰仍丢包时可先调大缓冲换时间但若持续满载应加机器或优化单条处理耗时。调大 map hint在已知设备数规模时把 hint 调到1.2× 预期设备数可减少扩容过大则浪费初始内存。泄漏排查AckRequestMap、SipCatalogLoopMap等若未 RemoveMap 调涨——配合 SSE状态中的计数做告警。相关代码路径core/app/sev/vss/internal/svc/service_context.go
