本文介绍使用 guava 的 loadingcache 替代 hashmap，为每个用户对话设置 2 分钟无操作自动过期机制，避免手动轮询或定时任务，在保证上下文记忆的同时显著降低 openai token 消耗。
本文介绍使用 guava 的 loadingcache 替代 hashmap，为每个用户对话设置 2 分钟无操作自动过期机制，避免手动轮询或定时任务，在保证上下文记忆的同时显著降低 openai token 消耗。
在构建状态感知的聊天机器人（如基于 OpenAI GPT-3.5-turbo 的对话服务）时，维持用户会话历史至关重要；但长期累积的 ChatMessage 列表会导致请求 token 数激增，推高成本与延迟。关键挑战在于：仅对单个用户会话实施“空闲超时”清理（如 2 分钟无新消息即重置），而非清空全局缓存或依赖外部调度器。
原代码中直接使用 HashMap<String, List<ChatMessage>> 无法原生支持条目级 TTL（Time-To-Live），需自行维护时间戳、启动后台线程扫描——既易出错又增加复杂度。更优雅、生产就绪的方案是采用 Guava Cache，其 expireAfterWrite 策略恰好匹配“最后一次写入后过期”的语义（注意：此处“写入”指 cache 的 put 或 reload，等效于用户发送新消息）。
✅ 推荐实现：Guava LoadingCache + expireAfterWrite
首先，在 pom.xml 中引入 Guava（建议 ≥ 31.0-jre）：
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>33.2.1-jre</version>
</dependency>然后重构缓存逻辑：
立即学习“Java免费学习笔记（深入）”；
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
private static OpenAiService service;
// 使用 LoadingCache 替代 HashMap，支持自动过期
private static LoadingCache<String, List<ChatMessage>> conversations;
public static void initializeOpenAi() {
service = new OpenAiService(Settings.OPENAI_ACCESS_KEY);
conversations = CacheBuilder.newBuilder()
.maximumSize(10_000) // 可选：防止内存无限增长
.expireAfterWrite(2, TimeUnit.MINUTES) // ⚠️ 核心：2分钟内无新消息即失效
.build(new CacheLoader<String, List<ChatMessage>>() {
@Override
public List<ChatMessage> load(String userId) {
// 每次 cache miss 时创建新会话（含 system message）
List<ChatMessage> newConv = new ArrayList<>();
ChatMessage system = new ChatMessage();
system.setRole("system");
system.setContent("Omnis is a chatbot with sarcasm");
newConv.add(system);
return newConv;
}
});
}
public static String generateChatResponse(User user, String prompt) {
String userId = user.getId();
List<ChatMessage> conversation;
// 自动触发 load() 或返回已缓存且未过期的会话
try {
conversation = conversations.get(userId); // 非 getIfPresent()！确保 lazy 初始化
} catch (ExecutionException e) {
throw new RuntimeException("Failed to load conversation for user: " + userId, e);
}
// 构建用户消息
ChatMessage userPrompt = new ChatMessage();
userPrompt.setRole("user");
userPrompt.setContent(prompt);
conversation.add(userPrompt);
// 构建并发送 ChatCompletion 请求（同原逻辑）
ChatCompletionRequest chatRequest = ChatCompletionRequest.builder()
.model("gpt-3.5-turbo")
.maxTokens(1000)
.temperature(0.9)
.topP(0.3)
.frequencyPenalty(0.9)
.presencePenalty(0.0)
.messages(conversation)
.build();
ChatCompletionResult chatResult;
try {
chatResult = service.createChatCompletion(chatRequest);
} catch (Exception e) {
// 错误处理逻辑保持不变...
return handleError(e);
}
String response = chatResult.getChoices().get(0).getMessage().getContent();
// 添加助手回复到会话（触发下次 expireAfterWrite 计时重置）
ChatMessage assistantPrompt = new ChatMessage();
assistantPrompt.setRole("assistant");
assistantPrompt.setContent(response);
conversation.add(assistantPrompt);
// ✅ 关键：无需显式 put —— Cache 已通过 get() 加载并持有引用
// 下次该用户调用时，若超时则自动重建新会话
return response;
}⚠️ 注意事项与最佳实践
expireAfterWrite vs expireAfterAccess：
此场景应严格使用 expireAfterWrite（写入后过期），因“空闲”定义为自上次用户发消息起无新交互。若误用 expireAfterAccess（访问后过期），则每次 get() 都会刷新计时器，导致永不超时。线程安全：Guava Cache 是线程安全的，conversations.get(userId) 可被多线程并发调用，无需额外同步。
内存管理：.maximumSize(10_000) 建议保留，防止恶意用户 ID 泛滥导致 OOM；实际阈值需根据预期并发用户数调整。
错误恢复：CacheLoader.load() 抛异常将导致 get() 失败，因此需用 try-catch ExecutionException 包裹（如上所示），避免单个用户故障影响全局。
-
替代方案对比：
- Caffeine（推荐用于新项目）：API 更现代，性能略优，用法高度相似（Caffeine.newBuilder().expireAfterWrite(2, MINUTES).build(key -> createNewConversation())）；
- Spring Cache + @Cacheable：适合 Spring 生态，但需配置 ConcurrentMapCacheManager 并自定义 TTL；
- 手动时间戳 + 定时扫描：侵入性强、易漏判、资源浪费，不推荐。
通过此改造，每个用户会话在静默 2 分钟后自动“归零”，新对话从 system 消息开始，Token 消耗回归基线水平，同时代码更简洁、健壮、可维护。
