在 Java 9 之前，javac 编译器机械地将每个字符串连接表达式转换为一系列 StringBuilder 分配和 append 调用，最后以 toString() 调用结束。这种方法在每个连接点生成了冗长的单态字节码，使实现策略不可逆转地绑定到编译时决定。这个静态翻译的根本问题在于，它使得方法大小超过了 HotSpot 的内联阈值，并阻止了 JVM 选择更优的运行时策略，比如融合数组复制或向量化操作，因为逻辑冻结在字节码流中，而不是存在于可优化的运行时库中。Java 9 (JEP 280) 引入了基于 invokedynamic 的连接，编译器发出一个引用 StringConcatFactory 的 invokedynamic 指令；这个工厂返回一个 ConstantCallSite，在初始链接后是不可变的，向 JVM 发出信号，表明目标 MethodHandle 永远不会改变，并可以作为直接的、去虚拟化的调用处理，以允许激进的内联和逃逸分析。
一个高频交易平台需要每秒生成数百万个 FIX 协议消息，利用广泛的字符串连接来生成标签-值对。分析显示在 Java 8 上，关键路径中的 StringBuilder 分配消耗了总堆的 18%，触发频繁的 GC 暂停，而复杂消息的生成字节码超过了 C2 编译器的 325 字节内联阈值，阻止了关键的循环优化，并导致了不稳定的延迟峰值。
解决方案 1: 手动 ThreadLocal 池化。 这种方法为每个线程缓存 StringBuilder 实例，以消除分配开销。优点：去除了短生命周期对象的 GC 压力，减少了对象变化。缺点：引入了复杂的生命周期管理，需要认真清理以防止 ThreadLocal 映射中的内存泄漏，并用池化样板代码模糊了业务逻辑。
解决方案 2: 堆外 ByteBuffer 构造。 这个策略利用 ByteBuffer.allocateDirect 在受管堆外构建消息。优点：在消息构造期间实现了零 GC 压力，并允许通过 NIO 进行直接套接字写入。缺点：带来了极大的复杂性，牺牲了 String 不可变性保证，引入了手动内存安全风险，并因原始字节操作而使调试复杂。
解决方案 3: 升级到 Java 11 与 invokedynamic 连接。 这涉及迁移运行时以利用 StringConcatFactory 而不更改应用程序代码。优点：将每个连接的字节码占用从 ~200 字节减少到 ~5 字节，并且 ConstantCallSite 的不可变性使 HotSpot 能够直接在交易循环中内联连接逻辑。缺点：需要全面的回归测试，并与遗留字节码操作代理临时不兼容。
选择的解决方案和结果。 解决方案 3 在金丝雀部署后被选中，显示分配速率降低了 35%，消除了 GC 引起的延迟峰值。系统现在维持着是之前两倍的吞吐量，并且 p99 延迟低于毫秒，因为 JIT 编译器将连接视为内在操作，彻底消除了方法调用开销。
为什么 StringConcatFactory 使用 ConstantCallSite 而不是 MutableCallSite，如果允许可变性，哪个优化会丧失？
引导机制返回一个 ConstantCallSite，因为连接策略纯粹由静态参数类型和调用点的常量配方决定，初始链接后无需动态重新定位。如果使用 MutableCallSite，JVM 将被迫在每次调用时插入内存屏障或虚拟调度检查，以处理潜在的目标变更，这将阻止 JIT 应用内联和常量传播，并重新引入 invokedynamic 设计用于消除的确切调用开销。
makeConcatWithConstants 引导方法在处理字符串字面量方面与 makeConcat 有什么不同，这种区别对调用点性能有什么影响？
makeConcatWithConstants 方法接受一个“配方”字符串，其中字面片段使用标记嵌入，允许引导将常量吸收到生成的 MethodHandle 中，而不是作为动态栈参数传递。这减少了调用点的动态参数数量，降低了栈流量和寄存器压力，而 makeConcat 将所有操作数视为动态的。基于配方的方法使 JVM 能够在链接期间执行部分常量折叠，可能将常量前缀预计算到生成的代码中。
在什么特定条件下，JVM 可以完全消除字符串连接的 invokedynamic 调用开销，将其视为无操作或纯常量？
如果连接表达式的所有操作数都是编译时常量表达式，比如字面量字符串或 static final 常量，javac 可能会在编译时完全执行常量折叠，将表达式替换为常量池中的单个 String 字面量，完全消除 invokedynamic 指令。如果即使有一个操作数是动态的，indy 调用依然存在；不过，JIT 仍然可能在优化过程中通过复杂的逃逸分析证明输入的不可变性，尽管这与编译时折叠不同。