一、错误写法（千万不要用，并发必 OOM）
问题根源
整个全局意义上的, 单一实例内形式的内存存储方式: 名为 InMemoryChatMemory 的这种存储, 在全局范围内共同使用, 所有不同用户的会话方面的数据, 都堆积放置在同一个实例之中, 当并发数量很大的时候, 会毫无限制地不断堆积历史消息。
不存在会话隔离的情况, 意思就是并没有依据conversationId来进行分片存储, 而是将多个用户的上下文混合存储。
没有消息长度的限制, 没有消息条数的限制, 长对话可无限追加历史, 高频请求可无限追加历史, 内存会持续上涨且不会回收。
不是线程安全的操作, 内存容器没有添加锁, 并发进行读取和写入操作导致出现脏数据, 并且发生了内存泄漏。
java
// 致命错误：全局单例内存记忆，并发直接OOM
@Bean
public ChatMemory agentChatMemory() {
// 全局唯一内存存储，所有会话全部塞这里
return new InMemoryChatMemory();
}
// Agent 直接注入全局记忆，无会话隔离
@Bean
public AiService agentService(ChatMemory chatMemory) {
return AiServices.builder(OpenAiChatModel.builder()
.apiKey("xxx")
.build())
.chatMemory(chatMemory)
.build();
}二、并发 OOM 核心诱因拆解
会话不隔离
百万数量的用户共同使用同一个InMemoryChatMemory, 每一条对话的历史都永久性地留在堆内存之中, 垃圾回收机制无法将其回收。
无上下文截断策略
设定为不存在最大消息数方面的限定, 用户进行来回的对话达到几十轮, 上下文所涉及的文本处于几KB至几十KB的范围, 在并发进行叠加之后堆内存出现急剧增加。
纯内存无持久化淘汰
内存里的记忆, 不会自行淘汰冷掉的会话, 那些长期不活跃的用户的上下文, 会一直占用内存。
线程安全缺陷
底层采用 HashMap 的原生 InMemoryChatMemory, 进行高并发的读写操作时, 会导致链表出现并有数据堆积的情况, 进而使得内存泄漏的速度加快。
三、生产环境标准正确实现（并发安全、防 OOM）
核心优化点
建立可将会话进行分片存储的方式, 借助 ChatMemoryProvider 来达成, 让每个会话对应独立的记忆实例。
强行使上下文进行截断, 对最大历史消息的条数作出限制, 若是超出就要自动丢弃那些最早的消息。
用于并发安全的容器, 其底层借助ConcurrentHashMap来来存放会话。
对于冷会话, 其会自动过期从而被淘汰, 它会配合缓存 TTL, 能够自动清理那些长期处于不活跃状态的会话。
存在一种分布式兼容的情况, 其中生产推荐采用 Redis持久化记忆方式, 实现彻底脱离堆内存存储。
方案一: 针对单机高并发情况, 采用内存分片方式, 结合过期淘汰机制以及截断手段, 适用于中小流量场景。
java
import dev.langchain4j.memory.ChatMemory;
import dev.langchain4j.memory.chat.MessageWindowChatMemory;
import dev.langchain4j.memory.chat.ChatMemoryProvider;
import dev.langchain4j.model.chat.ChatLanguageModel;
import dev.langchain4j.service.AiServices;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
@Configuration
public class AgentConfig {
// 1. 并发安全会话容器：ConcurrentHashMap 代替 HashMap
private final Map sessionMemoryMap = new ConcurrentHashMap<>();
// 2. 会话记忆工厂：每个conversationId独立记忆实例
@Bean
public ChatMemoryProvider chatMemoryProvider() {
return conversationId -> sessionMemoryMap.computeIfAbsent(conversationId, id -> {
// 关键防OOM：限制最大历史消息10条，自动截断旧消息
return MessageWindowChatMemory.builder()
.maxMessages(10)
.build();
});
}
// 3. 构建Agent，使用会话隔离的MemoryProvider
@Bean
public AgentService agentService(ChatLanguageModel chatModel, ChatMemoryProvider memoryProvider) {
return AiServices.builder(chatModel)
.chatMemoryProvider(memoryProvider) // 多会话隔离核心
.build(AgentService.class);
}
// 定时任务补充：自动清理超过30分钟未访问的冷会话
// @Scheduled(fixedRate = 60000)
// public void cleanExpiredSession() {
// // 基于最后访问时间淘汰过期会话，释放内存
// }
}
// Agent 接口，业务使用
public interface AgentService {
String chat(@MemoryId String sessionId, String userMessage);
} 方案二: 生产分布式方面优先选择（RedisChatMemory这样一种方式, 从根本上杜绝堆内存出现OOM）。有了它内存将不会过载, 数据处理更高效, 系统运行更稳定。
纯粹与 JVM 堆内存产生彻彻底底的脱节, 将上下文朝着 Redis 进行持久化处理, 它具备过期淘汰之能力, 能够达成分布式多实例间的会话实现共享目的, 面对高达百万之数的并发状况依然可以做到稳定运行且不会出现内存溢出的情况。
依赖引入
xml
dev.langchain4j
langchain4j-store-redis
最新稳定版
Redis 记忆配置
java
@Bean
public ChatMemoryProvider redisChatMemoryProvider() {
return conversationId -> RedisChatMemory.builder()
.redisClient(RedisClients.create("redis://127.0.0.1:6379"))
.conversationId(conversationId)
.maxMessages(10) // 上下文截断
.sessionTTL(Duration.ofMinutes(30)) // 会话自动过期，释放Redis存储
.build();
}四、额外兜底防 OOM 优化策略
严格限制上下文窗口
依照模型 token 的上限来设定 maxMessages, 在通用场景里是 8 到 15 条, 不可以进行无限制的历史存储。
增加摘要记忆降级（超长对话场景）
将其与 SummaryChatMemory 进行搭配, 在消息超出所设定的阈值之际, 能够自动对历史予以总结，进而实现减少上下文文本的体积这样的效果。
监控会话数量与堆内存
透过Actuator对动态会话数量展开监测, 针对JVM堆内存使用比例予以监控, 设定告警临界值, 以此避免会话急剧增多。
接口层增加会话主动销毁 API
当用户退出会话之际, 主动去删除 Redis 里以及内存之中的上下文, 立刻去释放资源。
java
// 主动清理会话记忆
public void clearSessionMemory(String sessionId) {
sessionMemoryMap.remove(sessionId);
// Redis方案直接删除redis key
}五、避坑总结
不能允许全局单例 InMemoryChatMemory, 因为要是所有会话都共同使用它, 必然会导致内存溢出。
得采用 ChatMemoryProvider 来进行会话隔离的达成, 使得每一个 session 都能做到独立记忆, 是这样的情况。
强制配置 maxMessages 截断历史上下文；
单独的机器, 在面对高并发情况的时候, 使用 ConcurrentHashMap 这种方式来存储会话, 而要是在分布式环境里, 那就直接采用 RedisChatMemory进行处理。
对会话 TTL 进行配置, 从而实现自动淘汰那些处于冷状态的会话, 再搭配主动清理接口, 以此来释放内存。