JDBC 3.0 规范谈到了连接（和准备好的语句）池。
我们有几个独立的 Java 程序（即我们没有使用应用程序服务器），它们一直在使用 DBCP 来提供连接池。我们应该继续使用 DBCP，还是可以利用 JDBC 提供的池化并摆脱 DBCP？
我们正在使用 MySQL (Connector/J)，最终将添加 SQL Server 支持 (jTDS)；我们不太可能支持任何其他数据库。
编辑：请参阅下面关于我尝试消除连接池库的评论。似乎 DBCP 仍然相关（请注意，一些评论者推荐 C3P0 而不是 DBCP）。
在其他发帖人的鼓励下，我尝试去掉DBCP，直接使用MySQL JDBC驱动（Connector/J 5.0.4）。我无法这样做。
看起来，虽然驱动程序确实为池提供了基础，但它并没有提供最重要的东西：一个实际的池（源代码为此派上了用场）。这部分由应用服务器提供。
我再次查看了 JDBC 3.0 文档（我有一份标有“第 11 章连接池”的打印副本，不确定它的确切来源），我可以看到 MySQL 驱动程序遵循 JDBC 文档。
当我查看 DBCP 时，这个决定开始变得有意义。良好的游泳池管理提供了许多选择。例如，您何时清除未使用的连接？你清除了哪些连接？池中的最大连接数是否有硬性或软性限制？在将连接提供给呼叫者之前，您是否应该测试连接的“活跃性”？等等
总结：如果你在做一个独立的 Java 应用程序，你需要使用一个连接池库。连接池库仍然相关。
DBCP 有严重的缺陷。我认为它不适合生产应用程序，尤其是当有这么多驱动程序在其DataSource本机中支持池时。
就我而言，压垮骆驼的最后一根稻草是当我发现整个池在对数据库进行新连接尝试的整个过程中都被锁定时。因此，如果您的数据库发生了导致连接缓慢或超时的问题，则其他线程在尝试将连接返回到池时会被阻止——即使它们是使用数据库完成的。
池旨在提高性能，而不是降低性能。DBCP 是幼稚的、复杂的和过时的。
我更喜欢使用 dbcp 或 c3p0，因为它们是供应商中立的。我发现，至少在使用 mysql 或 oracle 时，每当我尝试使用非标准 sql 的 jdbc 客户端做某事时，我都必须引入对供应商类的编译时依赖。例如，请参见此处的一个非常烦人的示例。
我不确定 mysql，但 oracle 使用它们特定的非标准类进行连接池。
人们仍然使用 DBCP，我认为它甚至是 Hibernate 的默认设置。
DBCP 不能满足您当前的需求吗？
我不太相信替换基础设施，除非已经存在无法填补的性能或功能差距，即使周围有更新或更好的替代方案。