日志告警中应使用预估容量初始化的stringbuilder，链式append避免临时string，基本类型直接append，空值用objects.tostring处理，单线程内可复用实例，优先使用日志框架参数化而非手动拼接。
在日志告警场景中，用 StringBuilder 拼接内容的核心目标是：避免字符串不可变带来的频繁对象创建，同时兼顾可读性与线程安全（通常日志拼接发生在单线程上下文中，无需同步）。
明确初始化容量，减少扩容开销
日志告警内容往往结构固定、长度可预估（比如“[ERROR][2024-06-15 10:23:45] 服务A调用超时，耗时1287ms，实例ip:10.0.1.5”）。直接使用无参构造会默认分配16字符容量，后续反复 append 触发数组扩容（涉及数组复制），影响性能。
建议按典型日志长度预估并初始化容量：
- 简单告警（含时间、级别、短消息）：初始容量设为 128～256
- 带参数详情的告警（含堆栈片段、请求ID、多个字段）：设为 512 或更高
- 示例：
StringBuilder sb = new StringBuilder(256);
链式调用 append，避免中间 String 对象
不要把多个字段先转成字符串再拼接，比如：sb.append("[WARN] " + msg + " at " + now) —— 这里 + 运算符会在编译期或运行期隐式创建临时 String，抵消 StringBuilder 的优势。
应拆解为连续 append：
sb.append("[WARN]").append(' ').append(msg).append(" at ").append(now);- 基本类型（
int、long、boolean）直接append，不调用String.valueOf() - 空值检查后 append，避免拼出 “null” 字符串；可用
Objects.toString(obj, "")简化处理
复用 StringBuilder 实例（谨慎线程安全）
在单次请求/单个告警生成逻辑内，可复用同一个 StringBuilder 实例（调用 setLength(0) 清空，比新建更轻量）。但注意：
- 不能跨线程共享同一实例（
StringBuilder非线程安全） - 若在日志工具类中封装，推荐方法局部变量方式创建，或使用
ThreadLocal<stringbuilder></stringbuilder>缓存（适用于高频日志场景） - 示例缓存用法：
private static final ThreadLocal<stringbuilder> TL_SB = ThreadLocal.withInitial(() -> new StringBuilder(256));</stringbuilder>
避免 toString() 过早调用和冗余操作
toString() 会创建新 String 对象，且内部复制整个字符数组。在日志框架（如 Log4j、SLF4J）支持参数化日志时，优先交由框架处理格式化，而非手动拼好再传入。
例如，推荐写法：
logger.warn("Service {} timeout, cost {}ms, ip: {}", serviceName, costMs, ip);- 而非：
logger.warn(sb.toString());（除非必须动态控制拼接逻辑，如条件字段） - 若必须手动拼（如组装告警消息发送到监控系统），只在最终一步调用
toString()
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
