PreparedStatement 本身不导致内存泄漏，但未显式 close、缓存配置不当或 SQL 模板不稳会引发句柄堆积、堆内存增长及连接资源耗尽；须规范生命周期、合理配置 cachePrepStmts/prepStmtCacheSize/prepStmtCacheSqlLimit，并保持 SQL 结构稳定。
Java 中 PreparedStatement 本身不会直接导致内存泄漏，但若使用不当，会引发 JDBC 驱动层或连接池层面的资源滞留，表现为 PreparedStatement 实例未释放、服务端预编译句柄堆积、客户端缓存膨胀，最终拖垮堆内存或耗尽数据库连接资源。关键不是“防 PreparedStatement 泄漏”，而是规范其生命周期与缓存行为。
确保每次使用后显式 close()
PreparedStatement 是资源对象，必须在使用完毕后调用 ps.close() —— 这一步不可省略，也不能依赖 try-with-resources 自动关闭（因部分老驱动或特殊场景下 close() 逻辑不完整）：
- 即使使用了 try-with-resources，也要确认驱动版本支持（MySQL Connector/J ≥ 8.0.23 后较稳定）
- 若 PreparedStatement 被缓存复用（如封装为 service 成员变量），需在业务结束时主动 close，而非仅靠连接关闭触发
- 未 close 的 PreparedStatement 在
useServerPrepStmts=true时，会持续占用 MySQL 的Prepared_statement句柄，累积达上限（默认 16382）将报错 “Too many prepared statements”
合理配置 JDBC 预编译缓存参数
客户端缓存（由 JDBC 驱动维护）若失控，会大量驻留 SQL 模板和参数元信息，造成堆内存缓慢增长：
- 启用缓存：
cachePrepStmts=true（默认 false，不启用则每次 prepare 都走全量解析，性能差且无缓存泄漏风险，但非最优） - 限制数量：
prepStmtCacheSize=250（推荐值；设为 0 相当于禁用缓存；超过 500 易引发 JVM 堆压力） - 限制长度：
prepStmtCacheSqlLimit=2048（防止动态拼接的长 SQL，如含 500 个 ? 的 IN 查询，挤占缓存槽位）
保持 SQL 模板结构稳定
驱动按完整 SQL 字符串哈希寻址缓存项。模板一变，就生成新缓存条目，旧项被踢出，命中率归零，等效于缓存“假性溢出”：
立即学习“Java免费学习笔记（深入）”；
- 禁止拼接表名、列名、ORDER BY 字段、ASC/DESC 等结构性内容，例如
"SELECT * FROM " + tableName + " WHERE id = ?" - IN 子句统一用固定占位符（如最多 100 个
?, ?, ...），配合白名单校验参数数量，避免每种 IN 长度都生成一条缓存 - 同一业务逻辑中，参数设置顺序与类型保持一致（如始终用
setString(1, x)，不混用setObject(1, x, Types.VARCHAR)）
配合连接池正确管理复用逻辑
PreparedStatement 生命周期绑定到 Connection，而连接池复用 Connection，因此复用策略直接影响资源驻留时长：
- HikariCP：不提供
poolPreparedStatements开关，完全依赖 JDBC URL 参数（如cachePrepStmts）生效 - Druid：需显式调用
setPoolPreparedStatements(true)并设置maxOpenPreparedStatements（建议 ≤ prepStmtCacheSize） - 避免每次查询都调用
conn.prepareStatement(sql)；高频 SQL 可封装为 ThreadLocal或复用已有实例，但务必保证 close 时机可控
