使用JDA开发Discord机器人时是否应保持JDBC长连接？

你提到的两种实现方式都不适合当前Discord机器人的业务场景，最优方案是使用成熟的JDBC连接池统一管理连接。

单例常驻单连接方案的缺陷 #

• JDBC原生连接不具备线程安全能力，JDA处理用户指令是多线程调度模型，峰值时段多个指令同时触发数据库操作时，共用单个连接会出现请求阻塞、结果集错乱、事务嵌套异常，直接导致指令执行失败。
• 单连接没有冗余容错能力，一旦出现网络波动、数据库主动回收空闲连接，重连窗口期内所有数据库操作都会直接报错，峰值时段会出现大面积指令无响应。
• 单连接吞吐量存在硬上限，所有数据库操作必须排队执行，请求量上涨时响应延迟会直线升高，完全扛不住峰值并发。

每次操作新建/销毁连接方案的缺陷 #

• JDBC建立物理连接需要完成TCP三次握手、数据库权限校验、会话初始化全流程，单次建连耗时通常在几十到数百毫秒，峰值时段大量建连操作会直接拖慢机器人响应速度，甚至触发数据库端连接数限流。
• 高频建连、销毁连接会产生大量处于TIME_WAIT状态的TCP连接，很容易耗尽机器人所在服务器的端口、文件描述符资源，稳定性极差。
• 没有内置流控能力，瞬时请求峰值下会直接打满数据库的最大连接数，导致数据库拒绝所有新连接请求，连带影响其他依赖同个数据库的服务。

推荐落地方式 #

直接选用轻量高性能的JDBC连接池（比如HikariCP）管理连接，不需要自己手写连接管理、重连逻辑，只需要配置几个核心参数即可：

• 根据数据库性能设置合理的最大连接数，Discord机器人场景通常设置10-20就足以覆盖绝大多数峰值流量，不要盲目调大连接数反而增加数据库负担
• 开启连接池内置的空闲连接检测、无效连接剔除能力，连接池会自动维护可用连接，不需要手动实现超时重连逻辑
• 业务代码层面，每次执行数据库操作前从连接池借用连接，操作完成后立即归还连接即可，代码写法和手动新建/关闭连接的逻辑几乎一致，改造成本极低

注意：所有数据库操作必须设置合理的执行超时时间，避免慢SQL长时间占用连接导致连接池耗尽。

内容的提问来源于stack exchange，提问作者DM Malkawi