高性能聊天室广播消息组装需预估容量、复用StringBuilder实例、链式append调用、前置用户过滤。例如设初始容量12600，用ThreadLocal或对象池复用，避免String.format，过滤离线用户后再拼接。
在高性能聊天室后端，用 StringBuilder 组装批量广播消息时，核心是避免字符串拼接开销、减少对象创建、控制内存预分配，并保证线程安全（或规避共享风险）。
预估容量，避免扩容
每次 append 触发内部数组扩容会复制旧内容，影响吞吐。广播消息通常有固定结构（如“[用户A]：你好”），可提前估算单条长度和总条数：
- 假设用户名平均 10 字符 + 冒号 + 空格 + 消息平均 50 字符 + 换行符（
\n），单条约 63 字符 - 一次广播 200 条，则初始容量设为
200 * 63 ≈ 12600 - 构造时直接指定：
new StringBuilder(12600)
复用 StringBuilder 实例（ThreadLocal 或池化）
高频广播下频繁 new StringBuilder 会增加 GC 压力。推荐两种轻量复用方式：
- 用
ThreadLocal<StringBuilder>：每个线程独享实例，避免锁竞争；初始化时设置合理容量 - 简单对象池（如用
ConcurrentLinkedQueue<StringBuilder>）：广播前poll()，用完setLength(0)清空后offer()回池；注意不要保留引用导致内存泄漏
批量 append 而非格式化字符串
避免使用 String.format 或 + 拼接，它们隐式创建多个中间 String 对象：
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确：
sb.append('[').append(userName).append("]：").append(content).append('\n') - ❌ 低效：
sb.append(String.format("[%s]：%s\n", userName, content)) - 若需转义（如防 XSS），对
content单独处理后再append，不打断链式调用
写入前确认是否需要广播
不是所有消息都需全量广播（如系统通知、私聊、已离线用户）。应在组装前过滤目标用户列表，再构建文本：
- 先收集在线且订阅该频道的用户 ID 列表
- 遍历该列表，只对有效接收者拼接消息
- 若最终为空（如全员离线），直接跳过
StringBuilder构建，省去无意义操作
不复杂但容易忽略细节：容量预估、实例复用、纯 append 链式调用、前置过滤——这四点叠加，能让万级并发下的广播文本组装保持稳定低延迟。
