Skunk项目PostgreSQL内存泄漏问题分析与解决方案

问题背景

在使用Skunk（一个Scala语言的PostgreSQL数据库访问库）时，开发人员发现PostgreSQL数据库内存持续增长直至耗尽。该问题出现在处理Kafka无限事件流的场景中，系统通过批量查询（每1000条记录一组）与数据库交互，使用包含IN子句的参数化查询语句。

问题现象

当系统运行数日后，PostgreSQL服务内存持续增长直至崩溃。关键特征包括：

1. 使用prepareCacheSize = 1024配置
2. 约25个基础查询模板
3. 实际生成的预处理语句数量远超缓存容量（约25×1000）
4. 缓存溢出时，Skunk仅从本地缓存丢弃预处理语句，但未在PostgreSQL服务端执行DEALLOCATE操作

技术分析

预处理语句生命周期问题

Skunk当前实现存在两个关键缺陷：

1. 仅关闭Portal未关闭Statement：Skunk协议层在执行完成后仅发送Close('P')命令关闭Portal（执行环境），但未发送Close('S')命令关闭Statement（预处理语句）。这导致PostgreSQL服务端持续保留预处理语句。

2. 缓存清理不彻底：当缓存溢出时，Skunk仅从本地缓存移除条目，未同步清理服务端的预处理语句。Protocol.cleanup方法仅在会话真正关闭时才会被调用，执行清理操作。

IN子句的特殊问题

参数化IN子句会导致预处理语句爆炸式增长：

-- 不同参数数量会产生不同预处理语句
SELECT * WHERE id IN ($1);
SELECT * WHERE id IN ($1,$2);
SELECT * WHERE id IN ($1,$2,$3);

每种子句长度都会创建独立的预处理语句，这在批量查询场景下尤为严重。

解决方案

临时解决方案

使用PostgreSQL数组类型替代IN子句：

// 原问题代码
sql"SELECT ... WHERE id IN (${SomeCodecs.id.list(ids.size)})"

// 改进方案
sql"SELECT ... WHERE id = ANY(${intKeyArrayCodec[Product.Id]})"

这种改造将动态长度的IN子句转换为固定形式的数组查询，只需一个预处理语句。

根本解决方案

Skunk需要改进预处理语句管理机制：

1. 完善关闭机制：在执行完成后应同时关闭Portal和Statement
2. 缓存溢出处理：当缓存条目被淘汰时，应同步清理服务端资源
3. 主动清理接口：为Session暴露清理接口，允许应用主动释放资源

性能考量

PostgreSQL内部会将IN子句重写为数组查询，两种形式在查询计划层面完全等效：

-- IN子句实际执行计划
Bitmap Heap Scan on stream
  Recheck Cond: (id = ANY ('{1,2,3}'::bigint[]))

-- 直接数组查询执行计划
Bitmap Heap Scan on stream  
  Recheck Cond: (id = ANY ('{1,2,3}'::integer[]))

使用数组形式不会带来性能损失，同时能显著减少预处理语句数量。

最佳实践建议

1. 对于动态查询条件，优先考虑使用数组形式而非IN子句
2. 监控PostgreSQL的pg_prepared_statements视图
3. 合理设置prepareCacheSize，避免频繁缓存淘汰
4. 对于长期运行的连接，考虑定期重建以释放积累的预处理语句

该问题的修复将包含在Skunk的未来版本中，开发者可关注项目更新以获取官方解决方案。