第1691篇：JVM性能调优在AI应用中的特殊考量——GC暂停与推理延迟的关系
第1691篇：JVM性能调优在AI应用中的特殊考量——GC暂停与推理延迟的关系
去年年底，我们有一个生产事故让我印象很深。
用户反馈某个AI问答功能偶尔会有3到5秒的卡顿，规律不明显，有时候好几个小时都正常，突然就卡一下。监控图表上CPU、内存看起来都很正常。第一反应是网络抖动，查了一圈没问题。最后在JVM GC日志里发现了真凶——一次Full GC暂停了将近4秒。
这件事给我一个很大的触动：传统Java应用调JVM可以容忍偶尔的停顿，用户最多感觉"有点慢"。但AI推理场景完全不一样，用户对延迟的感知极其敏感，一次GC暂停就可能毁掉整个对话体验。
今天这篇，我想把AI应用场景下JVM调优的特殊性讲透，不是泛泛说那些通用技巧，而是专门针对大模型调用、Token流式输出这些场景来谈。
为什么AI应用的GC问题比普通应用更严重
先建立一个直觉。
传统的Web API，一个请求大概几十到几百毫秒。用户点了按钮，等个200ms，拿到结果，体验还行。就算GC停了300ms，用户最多感觉"稍微慢了一下"，不至于特别难受。
AI推理不一样。一次大模型调用，从发出请求到收完所有Token，可能需要10到30秒。这段时间里：
- 如果是流式输出，用户一直在盯着屏幕等字一个个蹦出来
- 应用这边要维护对话上下文、缓存KV状态、攒批次处理
- HTTP连接要保持alive，不能断
这种场景下，一次Stop-the-World GC暂停的危害被放大了好几倍：
- 流式输出会突然卡住，用户看到字符串不再更新，心里慌
- 如果暂停够长，HTTP连接超时，整个对话直接中断
- 批处理场景下，一次暂停会让整批请求同时延迟
更麻烦的是，AI应用的内存使用模式本身就容易触发GC压力。
AI应用的内存压力来自哪里
我梳理了一下我们线上AI服务的堆使用情况，主要的内存消耗来源有这几块：
1. 大JSON响应体
大模型API返回的响应，一次对话可能包含几千个Token，序列化成JSON之后轻松超过10KB，高并发下这些对象的生成和回收压力很大。
2. 提示词拼接
Prompt Engineering做得越细，提示词越长。一个包含系统提示、历史对话、RAG检索结果的完整提示词，可能有几十KB的字符串在内存里来回拷贝。
3. Embedding向量
RAG场景下，一条文档chunk的Embedding向量是个float[]，维度1536（OpenAI text-embedding-ada-002）意味着每个向量6KB。做相似度检索时，几十上百个候选向量同时在内存里，加起来好几百KB。
4. 流式响应的Buffer
SSE或者WebSocket流式输出，每个Token到来都要在应用层做处理，中间态的StringBuilder、byte[]来回创建。
这些对象的特点是：短时间大量创建，但生命周期长短不一。有的是请求级别（处理完就死），有的跨越整个对话生命周期（几分钟甚至更长）。这对GC来说是个麻烦的混合体——Young GC回收不干净，对象晋升到Old Gen，然后触发Major GC。
先搞清楚你现在的GC状况
在讨论调优策略之前，先得把诊断做好。瞎调参数没用。
开启GC日志是第一步，很多团队线上机器根本没有GC日志，出了问题只能猜。
// JVM启动参数，适用于Java 11+
-Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=50m
// 同时开启GC暂停时间的详细信息
-Xlog:gc+heap=debug:file=/var/log/app/gc-heap.log:time,uptime有了日志之后，关注这几个核心指标：
# 用grep快速统计GC暂停时间分布
grep "Pause" /var/log/app/gc.log | awk '{print $NF}' | sort -n | tail -20
# 统计每分钟GC次数
grep "GC(" /var/log/app/gc.log | awk '{print substr($1,1,16)}' | sort | uniq -c我自己写了一个简单的GC日志分析工具，放在项目里：
@Component
public class GCMetricsCollector {
private final MeterRegistry meterRegistry;
public GCMetricsCollector(MeterRegistry meterRegistry) {
this.meterRegistry = meterRegistry;
registerGCListeners();
}
private void registerGCListeners() {
for (GarbageCollectorMXBean gcBean : ManagementFactory.getGarbageCollectorMXBeans()) {
// 注册GC暂停时间的直方图
String gcName = gcBean.getName().replace(" ", "_");
// 使用通知监听器获取每次GC事件
if (gcBean instanceof NotificationEmitter emitter) {
emitter.addNotificationListener((notification, handback) -> {
if (notification.getType().equals(
GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION)) {
GarbageCollectionNotificationInfo info =
GarbageCollectionNotificationInfo.from(
(CompositeData) notification.getUserData());
long pauseMs = info.getGcInfo().getDuration();
String gcAction = info.getGcAction();
// 记录到Micrometer
meterRegistry.timer("jvm.gc.pause",
"gc.name", gcName,
"gc.action", gcAction)
.record(pauseMs, TimeUnit.MILLISECONDS);
// 超过500ms就打一条警告
if (pauseMs > 500) {
log.warn("GC暂停告警: name={}, action={}, duration={}ms, " +
"before={}, after={}",
gcName, gcAction, pauseMs,
info.getGcInfo().getMemoryUsageBeforeGc(),
info.getGcInfo().getMemoryUsageAfterGc());
}
}
}, null, null);
}
}
}
}GC算法的选择：G1、ZGC、Shenandoah 各有什么区别
Java现在主流的GC算法有三个，在AI应用场景下各有取舍。
G1GC：大多数场景的默认选择
G1是Java 9以后的默认GC，适合堆在4GB到32GB之间的场景。它的核心设计思路是"可预期的暂停时间"——你可以设置一个目标暂停时间，G1会尽量控制在这个范围内。
-XX:+UseG1GC
-Xms8g -Xmx8g
-XX:MaxGCPauseMillis=200 # 目标最大暂停时间200ms
-XX:G1HeapRegionSize=16m # 区域大小，对大对象友好
-XX:G1NewSizePercent=20 # Young区最小占比
-XX:G1MaxNewSizePercent=40 # Young区最大占比
-XX:G1MixedGCCountTarget=8 # Mixed GC目标次数
-XX:InitiatingHeapOccupancyPercent=45 # 触发并发标记的堆占用率G1的问题在于，当堆占用超过某个阈值，还是会发生Full GC（单线程），暂停时间可能高达几秒。AI应用里大对象比较多，容易触发Humongous对象的特殊处理路径，这是个坑。
G1 Humongous对象的坑
G1把超过Region大小50%的对象称为Humongous对象，这类对象直接分配在Old区，Young GC回收不了，要等Mixed GC或Full GC才能回收。
AI应用里，一个大的Prompt字符串，一个完整的JSON响应体，都可能触发Humongous分配。
// 诊断Humongous对象分配
-Xlog:gc+humongous=debug:file=/var/log/app/gc-humongous.log发现Humongous分配频繁的话，两个方向处理：
- 增大G1HeapRegionSize（最大32m），让更多对象变成"普通"对象
- 优化代码，拆分大对象，用流式处理代替全量加载
ZGC：低延迟的首选
ZGC是Java 15进入生产可用状态的垃圾收集器，最大的卖点是暂停时间不超过1ms（官方宣传），实际上在几百GB的堆上也能保持在10ms以内。
对于AI推理服务，如果你的P99延迟要求很高（比如必须在5秒内响应），ZGC是非常值得考虑的选项。
-XX:+UseZGC
-Xms16g -Xmx16g
-XX:ZCollectionInterval=0 # 不强制周期性GC，按需触发
-XX:ZAllocationSpikeTolerance=2 # 内存分配突增的容忍度
-XX:+ZProactive # Java 17+，主动触发GC，减少内存占用ZGC的代价是什么？内存开销更大，大约需要额外10%-20%的内存作为GC元数据。CPU开销也略高，因为并发GC线程在后台持续工作。
我做过一个对比测试，同等配置下，G1的吞吐量比ZGC高大约5-8%，但ZGC的P99延迟能降低60%-70%。对于AI推理这种用户感知强烈的场景，这个取舍是值得的。
Shenandoah：另一个低延迟选项
Shenandoah是Red Hat开发的低暂停GC，与ZGC的目标类似，但设计哲学不同。ZGC主要在JDK里，Shenandoah在OpenJDK里。如果你用的是Red Hat的发行版或者Azul的Zing/Zulu，可以考虑。
-XX:+UseShenandoahGC
-XX:ShenandoahGCMode=iu # 增量更新模式，更适合高并发
-XX:ShenandoahGCHeuristics=adaptive # 自适应启发式针对AI应用的具体调优策略
策略一：避免大字符串的频繁创建
这是最容易下手的地方，也是收益最明显的。
AI应用里有大量的字符串拼接操作，如果用不当的方式，会产生很多短命的大对象。
// 错误示范：用+拼接会产生大量中间对象
public String buildPrompt(List<Message> history, String userInput, List<String> context) {
String systemPrompt = "你是一个专业的...";
String contextStr = String.join("\n", context);
String historyStr = "";
for (Message msg : history) {
historyStr += msg.getRole() + ": " + msg.getContent() + "\n";
}
return systemPrompt + "\n\n参考资料:\n" + contextStr + "\n\n对话历史:\n" + historyStr + "\n用户: " + userInput;
}
// 正确做法：预估容量，用StringBuilder一次性构建
public String buildPrompt(List<Message> history, String userInput, List<String> context) {
// 预估总长度，减少StringBuilder内部扩容（扩容会产生内存拷贝）
int estimatedSize = 500 // 系统提示
+ context.stream().mapToInt(String::length).sum() + context.size() * 2
+ history.stream().mapToInt(m -> m.getContent().length() + 20).sum()
+ userInput.length() + 100;
StringBuilder sb = new StringBuilder(estimatedSize);
sb.append("你是一个专业的...\n\n");
sb.append("参考资料:\n");
for (String ctx : context) {
sb.append(ctx).append('\n');
}
sb.append("\n对话历史:\n");
for (Message msg : history) {
sb.append(msg.getRole()).append(": ").append(msg.getContent()).append('\n');
}
sb.append("用户: ").append(userInput);
return sb.toString();
}策略二：流式响应的Buffer管理
流式输出场景下，Token逐个到来，很多代码会这样处理：
// 有问题的写法：每次token到来都创建新的StringBuilder
Flux<String> tokenStream = aiClient.streamChat(prompt);
tokenStream.subscribe(token -> {
// 这里可能在多线程环境下被多次调用
responseBuffer = responseBuffer + token; // 每次都创建新String！
});正确的做法是用StringBuffer或者StringBuilder + 线程安全控制：
@Service
public class StreamingChatService {
public Flux<String> streamChat(String sessionId, String userInput) {
// 使用预分配容量的StringBuilder，避免频繁扩容
// 假设平均回复1000 Token，每个Token约2-4字节
StringBuilder fullResponse = new StringBuilder(4096);
return aiClient.streamCompletion(buildRequest(sessionId, userInput))
.doOnNext(chunk -> {
// 只做append，不做字符串拼接
fullResponse.append(chunk.getContent());
})
.doOnComplete(() -> {
// 完成后整体保存，而不是每个Token都触发持久化
sessionStore.saveMessage(sessionId, fullResponse.toString());
})
.doOnError(e -> log.error("流式输出错误, sessionId={}", sessionId, e));
}
}策略三：对象池化减少GC压力
对于频繁创建的对象，用对象池是个经典手段。在AI应用里，我发现Embedding向量的float[]数组特别适合池化。
@Component
public class EmbeddingVectorPool {
// 使用Apache Commons Pool2
private final ObjectPool<float[]> vectorPool;
private static final int VECTOR_DIMENSION = 1536;
private static final int MAX_POOL_SIZE = 200;
public EmbeddingVectorPool() {
GenericObjectPoolConfig<float[]> config = new GenericObjectPoolConfig<>();
config.setMaxTotal(MAX_POOL_SIZE);
config.setMaxIdle(50);
config.setMinIdle(10);
config.setTestOnBorrow(false); // 不需要验证，float[]没有状态
vectorPool = new GenericObjectPool<>(new BasePooledObjectFactory<float[]>() {
@Override
public float[] create() {
return new float[VECTOR_DIMENSION];
}
@Override
public PooledObject<float[]> wrap(float[] obj) {
return new DefaultPooledObject<>(obj);
}
@Override
public void passivateObject(PooledObject<float[]> pooledObject) {
// 归还前清零，避免数据污染
Arrays.fill(pooledObject.getObject(), 0f);
}
}, config);
}
public float[] borrowVector() throws Exception {
return vectorPool.borrowObject();
}
public void returnVector(float[] vector) {
try {
vectorPool.returnObject(vector);
} catch (Exception e) {
// 归还失败也不影响业务，只是GC压力略高
log.debug("归还向量到对象池失败", e);
}
}
// 用try-with-resources更优雅
public PooledVector borrowVectorAsResource() throws Exception {
float[] vector = vectorPool.borrowObject();
return new PooledVector(vector, this);
}
public record PooledVector(float[] data, EmbeddingVectorPool pool)
implements AutoCloseable {
@Override
public void close() {
pool.returnVector(data);
}
}
}使用示例：
// 用try-with-resources自动归还
try (EmbeddingVectorPool.PooledVector pv = embeddingPool.borrowVectorAsResource()) {
float[] vector = pv.data();
// 填充向量数据
embeddingService.fillEmbedding(text, vector);
// 做相似度计算
return similaritySearch(vector, topK);
} // 自动归还到池策略四：堆外内存用于大缓存
如果你的AI应用有大规模的向量缓存或者提示词缓存，考虑用堆外内存（DirectByteBuffer）。堆外内存不受GC管理，不会因为GC而产生暂停。
但要注意，堆外内存有自己的泄漏风险，需要用Cleaner机制或者显式释放。我更推荐直接用成熟的堆外缓存库，比如 Caffeine 配合 softValues() 或者直接用 Chronicle Map。
// 使用Caffeine的softValues，JVM内存压力大时自动回收
Cache<String, EmbeddingResult> embeddingCache = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(1, TimeUnit.HOURS)
.softValues() // 内存压力大时，GC可以回收这些value
.recordStats()
.build();一个完整的调优参数模板
综合以上分析，这是我在一个Java 21 + ZGC的AI推理服务上用的JVM参数：
#!/bin/bash
# AI推理服务JVM启动参数
# 适用于：Java 21, 16GB机器, ZGC
JVM_OPTS=(
# 堆内存：留4GB给OS和堆外
"-Xms10g"
"-Xmx10g"
# GC选择：ZGC，低延迟优先
"-XX:+UseZGC"
"-XX:+ZGenerational" # Java 21+，ZGC分代模式，吞吐量更好
"-XX:ZCollectionInterval=0" # 按需GC
"-XX:ZAllocationSpikeTolerance=2"
# 堆外内存限制
"-XX:MaxDirectMemorySize=2g"
# 元空间
"-XX:MetaspaceSize=256m"
"-XX:MaxMetaspaceSize=512m"
# GC日志
"-Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=50m"
# JIT编译优化
"-XX:+UseStringDeduplication" # 字符串去重，AI场景下有很多重复prompt
"-XX:CompileThreshold=1000" # 降低JIT编译阈值，更快热身
# 大页支持（如果OS支持）
# "-XX:+UseTransparentHugePages"
# 崩溃时dump堆
"-XX:+HeapDumpOnOutOfMemoryError"
"-XX:HeapDumpPath=/var/log/app/heapdump.hprof"
# 线程栈
"-Xss512k" # AI服务不需要很深的调用栈，减小栈大小节省内存
)
exec java "${JVM_OPTS[@]}" -jar app.jar用数字说话：调优前后的对比
调优之前，我们的AI问答服务情况：
- P50延迟：1.2秒
- P99延迟：6.8秒（GC导致）
- GC暂停次数：约每2分钟一次Minor GC，每20分钟一次Major GC
- Major GC最长暂停：4.2秒
调优后（G1→ZGC + 代码优化）：
- P50延迟：1.1秒（基本不变）
- P99延迟：2.1秒（降低了69%）
- GC暂停基本在5ms以内
- 彻底消灭了Major GC暂停
吞吐量损失约5%，但P99延迟的大幅改善对用户体验的提升是指数级的。
几个容易被忽视的细节
1. JIT Warmup期间的GC压力
服务刚启动时，JIT还没编译热代码，执行效率低，产生的垃圾更多。这段时间GC会比较频繁。在AI服务里，你可以做预热：
@PostConstruct
public void warmup() {
// 发送几条测试请求，让JIT编译热路径
for (int i = 0; i < 5; i++) {
try {
aiClient.chat("你好，这是一条预热消息");
} catch (Exception e) {
// 忽略预热期间的错误
}
}
log.info("JVM预热完成");
}2. 容器环境下的JVM内存设置
在Kubernetes里，一定要显式设置堆大小，不要依赖JVM的自动探测。JVM默认会用物理内存的1/4作为最大堆，但容器里的内存限制经常被JVM识别错误，导致OOM被容器Kill。
-XX:+UseContainerSupport # Java 10+默认开启，让JVM感知容器限制
-XX:MaxRAMPercentage=70.0 # 最多用容器内存的70%作为堆
-XX:InitialRAMPercentage=50.0 # 初始堆50%3. 字符串去重的实际效果
-XX:+UseStringDeduplication 对AI应用效果很明显。我们的系统Prompt每次请求都会创建新的字符串对象，但内容完全相同。开启字符串去重后，堆内存降低了大约15%。
总结
JVM调优在AI应用场景下，核心矛盾是：用户对推理延迟的感知已经很敏感，GC暂停会在这个基础上叠加更大的延迟峰值。
解决思路是：
- 选择适合延迟敏感场景的GC（ZGC或Shenandoah）
- 减少内存分配压力（StringBuilder预分配、对象池化）
- 建立GC监控，让暂停可观测、可告警
- 容器环境下做好内存限制配置
不是所有场景都需要激进的GC调优。如果你的AI服务就是批量离线处理，用G1默认配置就够了，追求吞吐量。但如果是面向C端用户的实时对话，GC调优值得花时间深挖。
下一篇我们聊虚拟线程在AI服务中的应用，这和GC调优有很强的关联——虚拟线程会改变对象的生命周期分布，对GC产生新的影响。